Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug 1942725: explicitly allow apiserver pods to write to their root FS #437

Merged
merged 1 commit into from
Apr 15, 2021

Conversation

stlaz
Copy link
Contributor

@stlaz stlaz commented Mar 29, 2021

/assign @sttts

@openshift-ci-robot openshift-ci-robot added bugzilla/severity-high Referenced Bugzilla bug's severity is high for the branch this PR is targeting. bugzilla/invalid-bug Indicates that a referenced Bugzilla bug is invalid for the branch this PR is targeting. labels Mar 29, 2021
@openshift-ci-robot
Copy link

@stlaz: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

Bug 1942725: explicitly allow apiserver pods to write to their root FS

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@sttts
Copy link
Contributor

sttts commented Mar 29, 2021

/lgtm
/approve

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Mar 29, 2021
@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: stlaz, sttts

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 29, 2021
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

2 similar comments
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-bot
Copy link
Contributor

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

@openshift-ci-robot
Copy link

@openshift-bot: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-bot
Copy link
Contributor

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

@openshift-ci-robot
Copy link

@openshift-bot: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-bot
Copy link
Contributor

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

@openshift-ci-robot
Copy link

@openshift-bot: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-bot
Copy link
Contributor

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

@openshift-ci-robot
Copy link

@openshift-bot: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-bot
Copy link
Contributor

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

@openshift-ci-robot
Copy link

@openshift-bot: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-bot
Copy link
Contributor

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

@openshift-ci-robot
Copy link

@openshift-bot: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-bot
Copy link
Contributor

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

@openshift-ci-robot
Copy link

@openshift-bot: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-bot
Copy link
Contributor

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

@openshift-ci-robot
Copy link

@openshift-bot: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci-robot
Copy link

@openshift-bot: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-bot
Copy link
Contributor

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

@openshift-ci-robot
Copy link

@openshift-bot: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-bot
Copy link
Contributor

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

@openshift-ci-robot
Copy link

@openshift-bot: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-bot
Copy link
Contributor

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

@openshift-ci-robot
Copy link

@openshift-bot: This pull request references Bugzilla bug 1942725, which is invalid:

  • expected the bug to target the "4.8.0" release, but it targets "---" instead

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

/bugzilla refresh

Recalculating validity in case the underlying Bugzilla bug has changed.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@stlaz
Copy link
Contributor Author

stlaz commented Apr 14, 2021

/bugzilla refresh

@openshift-ci-robot openshift-ci-robot added bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. and removed bugzilla/invalid-bug Indicates that a referenced Bugzilla bug is invalid for the branch this PR is targeting. labels Apr 14, 2021
@openshift-ci-robot
Copy link

@stlaz: This pull request references Bugzilla bug 1942725, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.8.0) matches configured target release for branch (4.8.0)
  • bug is in the state NEW, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

Requesting review from QA contact:
/cc @xingxingxia

In response to this:

/bugzilla refresh

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

1 similar comment
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-merge-robot openshift-merge-robot merged commit d34feb3 into openshift:master Apr 15, 2021
@openshift-ci-robot
Copy link

@stlaz: All pull requests linked via external trackers have merged:

Bugzilla bug 1942725 has been moved to the MODIFIED state.

In response to this:

Bug 1942725: explicitly allow apiserver pods to write to their root FS

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@stlaz
Copy link
Contributor Author

stlaz commented Apr 30, 2021

/cherry-pick release-4.7
/cherry-pick release-4.6

@openshift-cherrypick-robot

@stlaz: new pull request created: #449

In response to this:

/cherry-pick release-4.7
/cherry-pick release-4.6

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@stlaz
Copy link
Contributor Author

stlaz commented Apr 30, 2021

/cherry-pick release-4.6

@openshift-cherrypick-robot

@stlaz: new pull request created: #450

In response to this:

/cherry-pick release-4.6

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

wking added a commit to wking/cluster-version-operator that referenced this pull request Jul 29, 2022
This blocks us from being associated with SecurityContextConstraints
that set 'readOnlyRootFilesystem: true', because from [1]:

> The set of SCCs that admission uses to authorize a pod are
> determined by the user identity and groups that the user belongs
> to.  Additionally, if the pod specifies a service account, the set of
> allowable SCCs includes any constraints accessible to the service
> account.
>
> Admission uses the following approach to create the final security
> context for the pod:
>
> 1. Retrieve all SCCs available for use.
> 2. Generate field values for security context settings that were not
>    specified on the request.
> 3. Validate the final settings against the available constraints.

If we leave readOnlyRootFilesystem implicit, we may get associated
with a SCC that sed 'readOnlyRootFilesystem: true', and the version-*
actions will fail like [2]:

  $ oc -n openshift-cluster-version get pods
  NAME                                        READY   STATUS    RESTARTS   AGE
  cluster-version-operator-6b5c8ff5c8-4bmxx   1/1     Running   0          33m
  version-4.10.20-smvt9-6vqwc                 0/1     Error     0          10s
  $ oc -n openshift-cluster-version logs version-4.10.20-smvt9-6vqwc
  oc logs version-4.10.20-smvt9-6vqwc
  mv: cannot remove '/manifests/0000_00_cluster-version-operator_00_namespace.yaml': Read-only file system
  mv: cannot remove '/manifests/0000_00_cluster-version-operator_01_adminack_configmap.yaml': Read-only file system
  ...

For a similar change in another repository, see [3].

[1]: https://docs.openshift.com/container-platform/4.10/authentication/managing-security-context-constraints.html#admission_configuring-internal-oauth
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=2110590#c0
[3]: openshift/cluster-openshift-apiserver-operator#437
wking added a commit to wking/cluster-version-operator that referenced this pull request Jul 29, 2022
This blocks us from being associated with SecurityContextConstraints
that set 'readOnlyRootFilesystem: true', because from [1]:

> The set of SCCs that admission uses to authorize a pod are
> determined by the user identity and groups that the user belongs
> to.  Additionally, if the pod specifies a service account, the set of
> allowable SCCs includes any constraints accessible to the service
> account.
>
> Admission uses the following approach to create the final security
> context for the pod:
>
> 1. Retrieve all SCCs available for use.
> 2. Generate field values for security context settings that were not
>    specified on the request.
> 3. Validate the final settings against the available constraints.

If we leave readOnlyRootFilesystem implicit, we may get associated
with a SCC that sed 'readOnlyRootFilesystem: true', and the version-*
actions will fail like [2]:

  $ oc -n openshift-cluster-version get pods
  NAME                                        READY   STATUS    RESTARTS   AGE
  cluster-version-operator-6b5c8ff5c8-4bmxx   1/1     Running   0          33m
  version-4.10.20-smvt9-6vqwc                 0/1     Error     0          10s
  $ oc -n openshift-cluster-version logs version-4.10.20-smvt9-6vqwc
  oc logs version-4.10.20-smvt9-6vqwc
  mv: cannot remove '/manifests/0000_00_cluster-version-operator_00_namespace.yaml': Read-only file system
  mv: cannot remove '/manifests/0000_00_cluster-version-operator_01_adminack_configmap.yaml': Read-only file system
  ...

For a similar change in another repository, see [3].

Also likely relevant, 4.10 both grew pod-security.kubernetes.io/*
annotations [4] and cleared the openshift.io/run-level annotation [5].

$ git --no-pager log --oneline -3 origin/release-4.10 -- install/0000_00_cluster-version-operator_00_namespace.yaml
539e944 (origin/pr/623) Fix run-level label to empty string.
f58dd1c (origin/pr/686) install: Add description annotations to manifests
6e5e23e (origin/pr/668) podsecurity: enforce privileged for openshift-cluster-version namespace

None of those were in 4.9:

$ git --no-pager log --oneline -1 origin/release-4.9 -- install/0000_00_cluster-version-operator_00_namespace.yaml
7009736 (origin/pr/543) Add management workload annotations

And all of them landed in 4.10 via master (so they're in 4.10 before
it GAed, and in 4.11 and later too):

$ git --no-pager log --oneline -4 origin/master -- install/0000_00_cluster-version-operator_00_namespace.yaml
539e944 (origin/pr/623) Fix run-level label to empty string.

[1]: https://docs.openshift.com/container-platform/4.10/authentication/managing-security-context-constraints.html#admission_configuring-internal-oauth
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=2110590#c0
[3]: openshift/cluster-openshift-apiserver-operator#437
[4]: openshift#668
[5]: openshift#623
wking added a commit to wking/cluster-version-operator that referenced this pull request Jul 29, 2022
This blocks us from being associated with SecurityContextConstraints
that set 'readOnlyRootFilesystem: true', because from [1]:

> The set of SCCs that admission uses to authorize a pod are
> determined by the user identity and groups that the user belongs
> to.  Additionally, if the pod specifies a service account, the set of
> allowable SCCs includes any constraints accessible to the service
> account.
>
> Admission uses the following approach to create the final security
> context for the pod:
>
> 1. Retrieve all SCCs available for use.
> 2. Generate field values for security context settings that were not
>    specified on the request.
> 3. Validate the final settings against the available constraints.

If we leave readOnlyRootFilesystem implicit, we may get associated
with a SCC that set 'readOnlyRootFilesystem: true', and the version-*
actions will fail like [2]:

  $ oc -n openshift-cluster-version get pods
  NAME                                        READY   STATUS    RESTARTS   AGE
  cluster-version-operator-6b5c8ff5c8-4bmxx   1/1     Running   0          33m
  version-4.10.20-smvt9-6vqwc                 0/1     Error     0          10s
  $ oc -n openshift-cluster-version logs version-4.10.20-smvt9-6vqwc
  oc logs version-4.10.20-smvt9-6vqwc
  mv: cannot remove '/manifests/0000_00_cluster-version-operator_00_namespace.yaml': Read-only file system
  mv: cannot remove '/manifests/0000_00_cluster-version-operator_01_adminack_configmap.yaml': Read-only file system
  ...

For a similar change in another repository, see [3].

Also likely relevant, 4.10 both grew pod-security.kubernetes.io/*
annotations [4] and cleared the openshift.io/run-level annotation [5].

$ git --no-pager log --oneline -3 origin/release-4.10 -- install/0000_00_cluster-version-operator_00_namespace.yaml
539e944 (origin/pr/623) Fix run-level label to empty string.
f58dd1c (origin/pr/686) install: Add description annotations to manifests
6e5e23e (origin/pr/668) podsecurity: enforce privileged for openshift-cluster-version namespace

None of those were in 4.9:

$ git --no-pager log --oneline -1 origin/release-4.9 -- install/0000_00_cluster-version-operator_00_namespace.yaml
7009736 (origin/pr/543) Add management workload annotations

And all of them landed in 4.10 via master (so they're in 4.10 before
it GAed, and in 4.11 and later too):

$ git --no-pager log --oneline -4 origin/master -- install/0000_00_cluster-version-operator_00_namespace.yaml
539e944 (origin/pr/623) Fix run-level label to empty string.

[1]: https://docs.openshift.com/container-platform/4.10/authentication/managing-security-context-constraints.html#admission_configuring-internal-oauth
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=2110590#c0
[3]: openshift/cluster-openshift-apiserver-operator#437
[4]: openshift#668
[5]: openshift#623
wking added a commit to wking/cluster-version-operator that referenced this pull request Jul 29, 2022
This blocks us from being associated with SecurityContextConstraints
that set 'readOnlyRootFilesystem: true', because from [1]:

> The set of SCCs that admission uses to authorize a pod are
> determined by the user identity and groups that the user belongs
> to.  Additionally, if the pod specifies a service account, the set of
> allowable SCCs includes any constraints accessible to the service
> account.
>
> Admission uses the following approach to create the final security
> context for the pod:
>
> 1. Retrieve all SCCs available for use.
> 2. Generate field values for security context settings that were not
>    specified on the request.
> 3. Validate the final settings against the available constraints.

If we leave readOnlyRootFilesystem implicit, we may get associated
with a SCC that set 'readOnlyRootFilesystem: true', and the version-*
actions will fail like [2]:

  $ oc -n openshift-cluster-version get pods
  NAME                                        READY   STATUS    RESTARTS   AGE
  cluster-version-operator-6b5c8ff5c8-4bmxx   1/1     Running   0          33m
  version-4.10.20-smvt9-6vqwc                 0/1     Error     0          10s
  $ oc -n openshift-cluster-version logs version-4.10.20-smvt9-6vqwc
  oc logs version-4.10.20-smvt9-6vqwc
  mv: cannot remove '/manifests/0000_00_cluster-version-operator_00_namespace.yaml': Read-only file system
  mv: cannot remove '/manifests/0000_00_cluster-version-operator_01_adminack_configmap.yaml': Read-only file system
  ...

For a similar change in another repository, see [3].

Also likely relevant, 4.10 both grew pod-security.kubernetes.io/*
annotations [4] and cleared the openshift.io/run-level annotation [5].

$ git --no-pager log --oneline -3 origin/release-4.10 -- install/0000_00_cluster-version-operator_00_namespace.yaml
539e944 (origin/pr/623) Fix run-level label to empty string.
f58dd1c (origin/pr/686) install: Add description annotations to manifests
6e5e23e (origin/pr/668) podsecurity: enforce privileged for openshift-cluster-version namespace

None of those were in 4.9:

$ git --no-pager log --oneline -1 origin/release-4.9 -- install/0000_00_cluster-version-operator_00_namespace.yaml
7009736 (origin/pr/543) Add management workload annotations

And all of them landed in 4.10 via master (so they're in 4.10 before
it GAed, and in 4.11 and later too):

$ git --no-pager log --oneline -4 origin/master -- install/0000_00_cluster-version-operator_00_namespace.yaml
539e944 (origin/pr/623) Fix run-level label to empty string.

[1]: https://docs.openshift.com/container-platform/4.10/authentication/managing-security-context-constraints.html#admission_configuring-internal-oauth
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=2110590#c0
[3]: openshift/cluster-openshift-apiserver-operator#437
[4]: openshift#668
[5]: openshift#623
openshift-cherrypick-robot pushed a commit to openshift-cherrypick-robot/cluster-version-operator that referenced this pull request Aug 2, 2022
This blocks us from being associated with SecurityContextConstraints
that set 'readOnlyRootFilesystem: true', because from [1]:

> The set of SCCs that admission uses to authorize a pod are
> determined by the user identity and groups that the user belongs
> to.  Additionally, if the pod specifies a service account, the set of
> allowable SCCs includes any constraints accessible to the service
> account.
>
> Admission uses the following approach to create the final security
> context for the pod:
>
> 1. Retrieve all SCCs available for use.
> 2. Generate field values for security context settings that were not
>    specified on the request.
> 3. Validate the final settings against the available constraints.

If we leave readOnlyRootFilesystem implicit, we may get associated
with a SCC that set 'readOnlyRootFilesystem: true', and the version-*
actions will fail like [2]:

  $ oc -n openshift-cluster-version get pods
  NAME                                        READY   STATUS    RESTARTS   AGE
  cluster-version-operator-6b5c8ff5c8-4bmxx   1/1     Running   0          33m
  version-4.10.20-smvt9-6vqwc                 0/1     Error     0          10s
  $ oc -n openshift-cluster-version logs version-4.10.20-smvt9-6vqwc
  oc logs version-4.10.20-smvt9-6vqwc
  mv: cannot remove '/manifests/0000_00_cluster-version-operator_00_namespace.yaml': Read-only file system
  mv: cannot remove '/manifests/0000_00_cluster-version-operator_01_adminack_configmap.yaml': Read-only file system
  ...

For a similar change in another repository, see [3].

Also likely relevant, 4.10 both grew pod-security.kubernetes.io/*
annotations [4] and cleared the openshift.io/run-level annotation [5].

$ git --no-pager log --oneline -3 origin/release-4.10 -- install/0000_00_cluster-version-operator_00_namespace.yaml
539e944 (origin/pr/623) Fix run-level label to empty string.
f58dd1c (origin/pr/686) install: Add description annotations to manifests
6e5e23e (origin/pr/668) podsecurity: enforce privileged for openshift-cluster-version namespace

None of those were in 4.9:

$ git --no-pager log --oneline -1 origin/release-4.9 -- install/0000_00_cluster-version-operator_00_namespace.yaml
7009736 (origin/pr/543) Add management workload annotations

And all of them landed in 4.10 via master (so they're in 4.10 before
it GAed, and in 4.11 and later too):

$ git --no-pager log --oneline -4 origin/master -- install/0000_00_cluster-version-operator_00_namespace.yaml
539e944 (origin/pr/623) Fix run-level label to empty string.

[1]: https://docs.openshift.com/container-platform/4.10/authentication/managing-security-context-constraints.html#admission_configuring-internal-oauth
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=2110590#c0
[3]: openshift/cluster-openshift-apiserver-operator#437
[4]: openshift#668
[5]: openshift#623
openshift-cherrypick-robot pushed a commit to openshift-cherrypick-robot/cluster-version-operator that referenced this pull request Aug 18, 2022
This blocks us from being associated with SecurityContextConstraints
that set 'readOnlyRootFilesystem: true', because from [1]:

> The set of SCCs that admission uses to authorize a pod are
> determined by the user identity and groups that the user belongs
> to.  Additionally, if the pod specifies a service account, the set of
> allowable SCCs includes any constraints accessible to the service
> account.
>
> Admission uses the following approach to create the final security
> context for the pod:
>
> 1. Retrieve all SCCs available for use.
> 2. Generate field values for security context settings that were not
>    specified on the request.
> 3. Validate the final settings against the available constraints.

If we leave readOnlyRootFilesystem implicit, we may get associated
with a SCC that set 'readOnlyRootFilesystem: true', and the version-*
actions will fail like [2]:

  $ oc -n openshift-cluster-version get pods
  NAME                                        READY   STATUS    RESTARTS   AGE
  cluster-version-operator-6b5c8ff5c8-4bmxx   1/1     Running   0          33m
  version-4.10.20-smvt9-6vqwc                 0/1     Error     0          10s
  $ oc -n openshift-cluster-version logs version-4.10.20-smvt9-6vqwc
  oc logs version-4.10.20-smvt9-6vqwc
  mv: cannot remove '/manifests/0000_00_cluster-version-operator_00_namespace.yaml': Read-only file system
  mv: cannot remove '/manifests/0000_00_cluster-version-operator_01_adminack_configmap.yaml': Read-only file system
  ...

For a similar change in another repository, see [3].

Also likely relevant, 4.10 both grew pod-security.kubernetes.io/*
annotations [4] and cleared the openshift.io/run-level annotation [5].

$ git --no-pager log --oneline -3 origin/release-4.10 -- install/0000_00_cluster-version-operator_00_namespace.yaml
539e944 (origin/pr/623) Fix run-level label to empty string.
f58dd1c (origin/pr/686) install: Add description annotations to manifests
6e5e23e (origin/pr/668) podsecurity: enforce privileged for openshift-cluster-version namespace

None of those were in 4.9:

$ git --no-pager log --oneline -1 origin/release-4.9 -- install/0000_00_cluster-version-operator_00_namespace.yaml
7009736 (origin/pr/543) Add management workload annotations

And all of them landed in 4.10 via master (so they're in 4.10 before
it GAed, and in 4.11 and later too):

$ git --no-pager log --oneline -4 origin/master -- install/0000_00_cluster-version-operator_00_namespace.yaml
539e944 (origin/pr/623) Fix run-level label to empty string.

[1]: https://docs.openshift.com/container-platform/4.10/authentication/managing-security-context-constraints.html#admission_configuring-internal-oauth
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=2110590#c0
[3]: openshift/cluster-openshift-apiserver-operator#437
[4]: openshift#668
[5]: openshift#623
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. bugzilla/severity-high Referenced Bugzilla bug's severity is high for the branch this PR is targeting. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants