API Changes for RunAsGroup#52077
Conversation
|
Adding do-not-merge/release-note-label-needed because the release note process has not been followed. |
|
/unassign |
There was a problem hiding this comment.
Can you please separate this into controller changes, api changes, generated code? I'm having a hard time finding all the parts that changed while reviewing.
The test failures that you noted are due to the roundtrip fuzzer receiving a nil value when it injects something in.
This can happen for a number of reasons:
- conversion code is not accurate (if manually crafted)
- fuzzer is filling the value with an improperly formatted type (requires changes to the fuzzer)
- new required fields are added without defaults (doesn't seem to be the case here)
- not all supported APIs (v1beta1,v1,etc) have the necessary changes in their types
object.Spec.Template.Spec.Containers[0].SecurityContext.RunAsGroup:
a: (*int64)(0xc4207c10d8)
b: <nil>
pkg/apis/extensions/types.go
Outdated
| const ( | ||
| // container must run as a particular gid. | ||
| RunAsGroupStrategyMustRunAs RunAsGroupStrategy = "MustRunAs" | ||
| // container must run as a non-root uid |
pkg/apis/extensions/types.go
Outdated
| RunAsGroupStrategyMustRunAs RunAsGroupStrategy = "MustRunAs" | ||
| // container must run as a non-root uid | ||
| RunAsGroupStrategyMustRunAsNonRoot RunAsGroupStrategy = "MustRunAsNonRoot" | ||
| // container may make requests for any uid. |
| return autoConvert_extensions_PodSecurityPolicySpec_To_v1beta1_PodSecurityPolicySpec(in, out, s) | ||
| } | ||
|
|
||
| func Convert_v1beta1_PodSecurityPolicySpec_To_extensions_PodSecurityPolicySpec(in *extensionsv1beta1.PodSecurityPolicySpec, out *extensions.PodSecurityPolicySpec, s conversion.Scope) error { |
There was a problem hiding this comment.
why is this added as a manual conversion?
There was a problem hiding this comment.
frankly i dont know how to auto generate it , i ran all hack/updatexxx and didn't see it generated. if you have suggestions let me know
There was a problem hiding this comment.
@krmayankk what is the output from the generator when you tried to generate the conversions?
There was a problem hiding this comment.
if you remove this, what fails? if all the manual conversion is doing is calling the autoConvert_... function, it shouldn't be needed
There was a problem hiding this comment.
It still troubles me that this is a manual conversion. That seems not-right to me.
| allErrs = append(allErrs, field.NotSupported(fldPath.Child("rule"), runAsGroup.Rule, supportedRunAsGroupRules.List())) | ||
| } | ||
|
|
||
| // validate range settings |
There was a problem hiding this comment.
is it valid to specify ranges with RunAsGroupStrategyMustRunAsNonRoot or RunAsGroupStrategyRunAsAny?
There was a problem hiding this comment.
non-root and any do not support ranges for UID at this point cc @pmorie
There was a problem hiding this comment.
@krmayankk sounds like we need to validate that you don't get a range with a policy that doesn't support it.
| RunAsGroup *Int64Value `protobuf:"bytes,4,opt,name=run_as_group,json=runAsGroup" json:"run_as_group,omitempty"` | ||
| // If set, the root filesystem of the sandbox is read-only. | ||
| ReadonlyRootfs bool `protobuf:"varint,4,opt,name=readonly_rootfs,json=readonlyRootfs,proto3" json:"readonly_rootfs,omitempty"` | ||
| ReadonlyRootfs bool `protobuf:"varint,5,opt,name=readonly_rootfs,json=readonlyRootfs,proto3" json:"readonly_rootfs,omitempty"` |
There was a problem hiding this comment.
doesn't changing proto tags here break compatibility?
| // PodSecurityContext, the value specified in SecurityContext takes precedence | ||
| // for that container. | ||
| // +optional | ||
| RunAsGroup *int64 `json:"runAsGroup,omitempty" protobuf:"varint,3,opt,name=runAsGroup"` |
There was a problem hiding this comment.
have to take an available proto tag at the end of the range... reassigning existing numbers breaks the ability to read in previously persisted data
| // May also be set in PodSecurityContext. If set in both SecurityContext and | ||
| // PodSecurityContext, the value specified in SecurityContext takes precedence. | ||
| // +optional | ||
| RunAsGroup *int64 `json:"runAsGroup,omitempty" protobuf:"varint,5,opt,name=runAsGroup"` |
There was a problem hiding this comment.
same here, use a free proto tag from the end, don't reassign existing tags
| // runAsUser is the strategy that will dictate the allowable RunAsUser values that may be set. | ||
| RunAsUser RunAsUserStrategyOptions `json:"runAsUser" protobuf:"bytes,11,opt,name=runAsUser"` | ||
| // runAsGroup is the strategy that will dictate the allowable RunAsGroup values that may be set. | ||
| RunAsGroup RunAsGroupStrategyOptions `json:"runAsGroup" protobuf:"bytes,12,opt,name=runAsGroup"` |
pkg/apis/extensions/types.go
Outdated
| // RunAsUser is the strategy that will dictate the allowable RunAsUser values that may be set. | ||
| RunAsUser RunAsUserStrategyOptions | ||
| // RunAsGroup is the strategy that will dictate the allowable RunAsGroup values that may be set. | ||
| RunAsGroup RunAsGroupStrategyOptions |
There was a problem hiding this comment.
what's the default? (seems like it would have to be RunAsGroupStrategyRunAsAny for compatibility?)
There was a problem hiding this comment.
then that should be populated in SetDefaults_PodSecurityPolicySpec
There was a problem hiding this comment.
same question here, if RunAsGroup is non-nil, do we require RunAsUser to be non-nil? what if RunAsUser is set on the pod security context, and RunAsGroup is set on the container security context?
There was a problem hiding this comment.
same RunAsGroup can be non nil and RunAsUser can be nil
There was a problem hiding this comment.
Is that because the requirement for runasuser to be non-nil is docker specific? If other runtimes could allow that, it's fine to skip validating that here.
There was a problem hiding this comment.
the validation is saying that if RunAsGroup is specified at all, then it should be a valid group id. Not sure i follow your comment. Its not validating whether its specified or not. The first if is validating whether its specified at all, the second if is validating that if its specified its a valid group id
There was a problem hiding this comment.
I was wondering if we wanted to validate that both run as user and run as group were set, because the docker runtime will error if you set group without setting user
There was a problem hiding this comment.
yes other implementations could allow that and the limitation is docker specific. for e.g. rkt allows setting both independently
There was a problem hiding this comment.
There's a validation for it in dockershim - it might be prudent to push that up to the API validation for now.
tallclair
left a comment
There was a problem hiding this comment.
This is really hard to review. I suggest:
- Split the PodSecurityPolicy changes into a separate PR
- Put the generated files into a separate commit.
There was a problem hiding this comment.
Is this actually read anywhere?
There was a problem hiding this comment.
no, this is not implemented, only the RunAsGroup field is. there is a feature gate to disable it
There was a problem hiding this comment.
nit: errors start with lowercase
RunAsGroup is not a string, I think you can just leave it out here.
test/e2e/auth/pod_security_policy.go
Outdated
There was a problem hiding this comment.
Leave this out. It should be optional.
test/e2e/framework/psp_util.go
Outdated
There was a problem hiding this comment.
AFAICT this is never being enforced?
There was a problem hiding this comment.
only the securityContext is being enforced in Container and pod spec. PSP is not being enforced and hence i added the feature gates and disabled them by default. That was the comment from @liggitt which i have been taking care
|
I don't see this making 1.10. If you disagree, please file an extension request. |
|
discussed with @tallclair and @krmayankk. Rather than merge API changes for PSP and runAsNonRootGroup before their implementation, we'd prefer limiting this PR to the single runAsGroup field in PodSecurityContext and SecurityContext, which is implemented all the way through CRI and has backing e2e tests. These fields would still be feature gated and disabled by default, but would allow CRI implementations to integrate/test with this feature in the 1.10 timeframe (and have an e2e test that would exercise their integration). The PSP and runAsNonRoot fields and enforcement would be continued in 1.11, and would be required to be completed before enabling the RunAsGroup feature by default. A 1 day exception to remove the PSP and runAsNonRootGroup fields from this PR requested at https://groups.google.com/forum/#!msg/kubernetes-milestone-burndown/kq4zhEI_c-I/vLVpJlMMBAAJ |
There was a problem hiding this comment.
this doc change is spurious with runAsNonRootGroup removed
There was a problem hiding this comment.
@pmorie is "Defaults to group specified in image metadata if unspecified." accurate? or does it default to gid 0?
There was a problem hiding this comment.
I see this is described more fully in another field: "Defaults to group specified in image metadata if unspecified. If group is not specified in image metadata, the default is GID 0."
is that runtime-specific, or an API guarantee?
There was a problem hiding this comment.
Pretty sure that's runtime specific. I would just say something along the lines of "Uses runtime default if unset".
pkg/apis/extensions/validation/BUILD
Outdated
pkg/apis/extensions/types.go
Outdated
There was a problem hiding this comment.
I don't think this should be an error.
There was a problem hiding this comment.
nit: can you just do
user = fmt.Sprintf("%s:%d", config.User, sc.GetRunAsGroup().Value)?
There was a problem hiding this comment.
nit: prefer "The GID to run the container's init process"
(entrypoint is a docker term)
There was a problem hiding this comment.
this matches RunAsUser doc... I'd leave it for now
There was a problem hiding this comment.
Pretty sure that's runtime specific. I would just say something along the lines of "Uses runtime default if unset".
pkg/apis/core/types.go
Outdated
There was a problem hiding this comment.
this should match the other RunAsGroup doc, not say the default is GID 0
|
moving back into the milestone per granted exception |
|
/status approved-for-milestone |
|
@tallclair: GitHub didn't allow me to request PR reviews from the following users: CRI, changes, for. Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs. DetailsIn 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. |
|
fyi, I pushed an update to the branch restoring the $ git diff krmayankk/runas --numstat
5982 0 hack/gen-swagger-doc/example-output/definitions.html
$ git push --force-with-lease krmayankk HEAD:runas
To github.com:krmayankk/kubernetes.git
+ 1d5c33287c...7e31ffa0c9 HEAD -> runas (forced update)API and test changes LGTM |
|
@tallclair has approval on
|
tallclair
left a comment
There was a problem hiding this comment.
Noticed one more issue with the validation. Everything else LGTM.
Please ping me on slack once you've fixed the validation.
There was a problem hiding this comment.
The error handling here should match the error handling in the pod version - loop over the error messages.
|
/lgtm |
1 similar comment
|
/lgtm |
|
/assign @smarterclayton |
|
/approve Based on sig approval |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: krmayankk, liggitt, pmorie, smarterclayton, tallclair The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/test all [submit-queue is verifying that this PR is safe to merge] |
|
Automatic merge from submit-queue (batch tested with PRs 52077, 60456, 60591). If you want to cherry-pick this change to another branch, please follow the instructions here. |
First set of api changes for feature kubernetes/community#756