KEP for Windows security context#972
KEP for Windows security context#972k8s-ci-robot merged 5 commits intokubernetes:masterfrom ddebroy:master
Conversation
Signed-off-by: Deep Debroy <ddebroy@docker.com>
Signed-off-by: Deep Debroy <ddebroy@docker.com>
Signed-off-by: Deep Debroy <ddebroy@docker.com>
Signed-off-by: Deep Debroy <ddebroy@docker.com>
|
/assign @liggitt @PatrickLang @michmike |
|
/cc @wk8 @jsturtevant |
|
@ddebroy: GitHub didn't allow me to request PR reviews from the following users: jsturtevant. 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. |
| ### Test Plan | ||
|
|
||
| Unit tests will be added around `DetermineEffectiveSecurityContext` to ensure for each field in `WindowsSecurityOptions` the values in a container's `SecurityContext.WindowsOptions` can override values of the fields in the pod's `PodSecurityContext.WindowsOptions`. | ||
|
|
There was a problem hiding this comment.
We can also include a E2E test for this that will be labelled [sig-windows] and included in the existing test passes.
| ### Version Skew Strategy | ||
|
|
||
| ## Implementation History | ||
|
|
There was a problem hiding this comment.
kubernetes/kubernetes#73609 was held back from 1.14 since it was too late for API review. This PR will be rebased and adjusted to meet this KEP's proposed API.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ddebroy, PatrickLang 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 |
|
|
||
| ## Summary | ||
|
|
||
| In this KEP, we propose API enhancements in the Kubernetes pod spec to capture Windows OS specific security options from the perspective of Windows workload identity in containers. Initially the enhancements will cover fields pertinent to GMSA credential specs and the username with which to execute the container entry-point. More fields may be added in the future. |
There was a problem hiding this comment.
Do we know of any possible fields that might get added?
There was a problem hiding this comment.
I am not aware of any. Can you think of any we will need?
| In this KEP we propose a new field named `WindowsOptions` in the `PodSecurityContext` struct (associated with a pod spec) and the `SecurityContext` struct (associated with each container in a pod). `WindowsOptions` will be a pointer to a new struct of type `WindowsSecurityOptions`. The `WindowsSecurityOptions` struct will contain Windows OS specific security attributes scoped either at the pod level (applicable to all containers in the pod) or at the individual container level (that can override the pod level specification). Initially, the `WindowsSecurityOptions` struct will have the following fields: | ||
|
|
||
| - GMSACredentialSpecName: A string specifying the name of a GMSA credential spec custom resource | ||
| - GMSACredentialSpec: A string specifying the full credential spec JSON string associated with a GMSA credential spec |
There was a problem hiding this comment.
How big is the json spec? This might be difficult to format properly?
There was a problem hiding this comment.
Good point. In the GMSA KEP we detail how this field is auto populated by a webhook and not something the user needs to populate. Will clarify this.
There was a problem hiding this comment.
Is it needed in the public API then? I am not too familiar, but I know there is an internal model that Kubernetes maintains and that might be the better location for it. It seems confusing to have it on the public API surface if users do not use it.
There was a problem hiding this comment.
Is it needed in the public API then? I am not too familiar, but I know there is an internal model that Kubernetes maintains and that might be the better location for it. It seems confusing to have it on the public API surface if users do not use it.
There's no private API used to communicate between components. The "internal" API types are used as a hub to convert between the various serialized forms, but all serialization (via the REST API or to/from etcd) uses public APIs.
There was a problem hiding this comment.
Additionally, the GMSA KEP (and current implementation) does call for users to be able to pass that info directly, even though the main use case should be to rely on the webhook for this.
|
Comments addressed/clarified in #975 |
This is a KEP to cover the addition of the API enhancements related to GMSA and RunAsUsername to the pod security context and the container security context.
While the GMSA KEP covers the details around the GMSA fields, we did note that the specific API fields are speculative and may change. This KEP is where the structure and field names for the GMSA field as well as the RunAsUserName field will be finalized.