Update GMSA docs for beta in v1.16#16464
Update GMSA docs for beta in v1.16#16464ddebroy wants to merge 2 commits intokubernetes:dev-1.16from ddebroy:gmsa1
Conversation
|
Deploy preview for kubernetes-io-vnext-staging processing. Building with commit 59b50d3 https://app.netlify.com/sites/kubernetes-io-vnext-staging/deploys/5d87d7dac9907900074c19ee |
|
/cc @wk8 |
|
/assign @gochist |
sftim
left a comment
There was a problem hiding this comment.
Thanks for the PR.
Here are a couple of bits of feedback.
| {{< note >}} | ||
| Currently this feature is in alpha state. While the overall goals and functionality will not change, the way in which the GMSA credspec references are specified in pod specs may change from annotations to API fields. Please take this into consideration when testing or adopting this feature. | ||
| {{< /note >}} | ||
| In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as custom resources. Windows pods, as well as individual containers within a pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services. As of v1.16, Dockershim and the Docker runtime supports GMSA for Windows workloads end-2-end. Support for GMSA through CRI has been implemented but implementation of GMSA support in other runtimes like ContainerD is under investigation. |
There was a problem hiding this comment.
“end-2-end”? I think I'd stop that sentence at “workloads”.
There was a problem hiding this comment.
Although the investigation (mentioned in the last sentence) is current, I feel it still comes under avoid statements about the future.
I recommend rewording that last sentence, to (eg):
You can use GMSA with runtimes that implement {{< glossary_tooltip term_id="cri" text="CRI" >}}.There was a problem hiding this comment.
For now, I removed the CRI/containerd reference. Once that whole stack is functional (CRI + containerd/other runtimes on Windows with GMSA support), we can update things here. Right now (in the context of v1.16) I think this will create confusion for end-users.
Signed-off-by: Deep Debroy <ddebroy@docker.com>
|
New changes are detected. LGTM label has been removed. |
Signed-off-by: Deep Debroy <ddebroy@docker.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: wk8 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Please rebase to master. |
|
/unassign |
| {{< note >}} | ||
| Currently this feature is in alpha state. While the overall goals and functionality will not change, the way in which the GMSA credspec references are specified in pod specs may change from annotations to API fields. Please take this into consideration when testing or adopting this feature. | ||
| {{< /note >}} | ||
| In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide scope as custom resources. Windows pods, as well as individual containers within a pod, can be configured to use a GMSA for domain based functions (e.g. Kerberos authentication) when interacting with other Windows services. As of v1.16, Dockershim and the Docker runtime supports GMSA for Windows workloads. |
There was a problem hiding this comment.
supports -> support
Dockershim and the Docker runtime support GMSA ...
|
Thanks for the review. Will update and submit the PR against master then. |
|
Submitted against master as #16579 with comments addressed from above. |
Update to docs to reflect Beta state of GMSA feature in v1.16