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 1806438: Remove explicit securityContext and add granular securitycontextconstraints "use" permissions in machine-api-controllers clusterRole #502
Conversation
@enxebre: This pull request references Bugzilla bug 1806438, which is valid. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
In response to this:
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. |
@enxebre: This pull request references Bugzilla bug 1806438, which is valid. 3 validation(s) were run on this bug
In response to this:
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. |
2 similar comments
@enxebre: This pull request references Bugzilla bug 1806438, which is valid. 3 validation(s) were run on this bug
In response to this:
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. |
@enxebre: This pull request references Bugzilla bug 1806438, which is valid. 3 validation(s) were run on this bug
In response to this:
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. |
/retest |
/cherrypick release-4.4 |
@enxebre: once the present PR merges, I will cherry-pick it on top of release-4.4 in a new PR and assign it to you. In response to this:
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. |
@enxebre: This pull request references Bugzilla bug 1806438, which is valid. 3 validation(s) were run on this bug
In response to this:
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. |
1 similar comment
@enxebre: This pull request references Bugzilla bug 1806438, which is valid. 3 validation(s) were run on this bug
In response to this:
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
@enxebre As per comment in openshift/cluster-autoscaler-operator#133 the baremetal pod deployment uses hostNetwork, hostPort, and privileged |
@markmc good catch, I believe adding the specifics SCC to the clusterRole used by the machine-api-controllers should be enough as per openshift/cluster-ingress-operator@1409f54
cc @Miciah @smarterclayton can you confirm? /hold |
Yes, although ONLY the component that needs those should have a reference to the SCC via a unique service account. |
Agreed, currently our granularity let us give this to the pod which run the multiple machine controllers. In near future we might consider breaking this pod down into multiple components. /hold cancel |
…raints use permissions in machine-api-controllers clusterRole Without the runlabel openshift#496, we’ll run as a high user by default, no need to say run me as non root. Otherwise when removing the runlevel completely for the openshift-machine-api namespace openshift/cluster-autoscaler-operator#133 the kube controller manager complains with 'Error creating: pods "machine-api-operator-75c887884f-" is forbidden: unable to validate against any security context constraint: [spec.containers[0].securityContext.securityContext.runAsUser: Invalid value: 65534: must be in the ranges: [1000340000, 1000349999] spec.containers[1].securityContext.securityContext.runAsUser: Invalid value: 65534: must be in the ranges: [1000340000, 1000349999]]' https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-autoscaler-operator/133/pull-ci-openshift-cluster-autoscaler-operator-master-e2e-aws/496/artifacts/e2e-aws/pods/openshift-kube-controller-manager_kube-controller-manager-ip-10-0-133-251.us-east-2.compute.internal_kube-controller-manager.log"
/lgtm Would be good to get feedback from @sadasu's testing too |
/approve |
/retest |
1 similar comment
/retest |
/test e2e-gcp |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JoelSpeed, sadasu 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 |
/retest |
verbs: | ||
- use | ||
resourceNames: | ||
- privileged |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why does the operator require privileged SCC to run?
/retest Please review the full test history for this PR and help us cut down flakes. |
/hold
if this was the only problem then just the removal of |
/retest |
/hold cancel |
/retest Please review the full test history for this PR and help us cut down flakes. |
3 similar comments
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
@enxebre: new pull request created: #511 In response to this:
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. |
Without the runlabel #496, we’ll run as a high user by default, no need to say run me as non root.
Otherwise when removing the runlevel completely for the
openshift-machine-api
namespace openshift/cluster-autoscaler-operator#133 the kube controller manager complains withError creating: pods "machine-api-operator-75c887884f-" is forbidden: unable to validate against any security context constraint: [spec.containers[0].securityContext.securityContext.runAsUser: Invalid value: 65534: must be in the ranges: [1000340000, 1000349999] spec.containers[1].securityContext.securityContext.runAsUser: Invalid value: 65534: must be in the ranges: [1000340000, 1000349999]]
https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_cluster-autoscaler-operator/133/pull-ci-openshift-cluster-autoscaler-operator-master-e2e-aws/496/artifacts/e2e-aws/pods/openshift-kube-controller-manager_kube-controller-manager-ip-10-0-133-251.us-east-2.compute.internal_kube-controller-manager.log"Only after this PR makes it to payload then https://github.com/openshift/cluster-autoscaler-operator/pull/133/files should go green as no pods within the
openshift-machine-api
namespace will set an invalid user.