From 7bd07e72d0f49b89a1687ea73b4e41f9b09eb131 Mon Sep 17 00:00:00 2001 From: Deep Debroy Date: Sun, 17 Mar 2019 01:15:21 -0700 Subject: [PATCH 1/9] Clarifications and fixes in GMSA doc Signed-off-by: Deep Debroy --- .../configure-pod-container/configure-gmsa.md | 27 +++++++++++++------ 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md index 844db949c405e..e94b88d39c97a 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md @@ -13,7 +13,7 @@ This page shows how to configure [Group Managed Service Accounts](https://docs.m 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.14, the only container runtime interface that supports GMSA for Windows workloads is Dockershim. Implementation of GMSA through CRI and other runtimes is planned for the future. {{< 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 a API fields. Please take this into consideration when testing or adopting this feature. +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 >}} {{% /capture %}} @@ -21,7 +21,7 @@ Currently this feature is in alpha state. While the overall goals and functional {{% capture body %}} ## Setup and configuration for GMSA -Configuring GMSA credential specs in the cluster and configuring individual pods and containers to be able to use them requires several steps described in details below. +Configuring GMSA credential specs in the cluster and configuring individual pods and containers to be able to use them requires several steps described in detail below. ### Initial configuration of Kubernetes cluster to use GMSA This section covers a set of initial steps required once for each cluster. These include: @@ -33,7 +33,7 @@ This section covers a set of initial steps required once for each cluster. These In the alpha state, the `WindowsGMSA` feature gate needs to be enabled on kubelet on Windows nodes. This is required to pass down the GMSA credential specs from the cluster scoped configurations to the container runtime. See [Feature Gates](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) for an explanation of enabling feature gates. Please make sure `--feature-gates=WindowsGMSA=true` parameter exists in the kubelet.exe command line. #### Install the GMSACredentialSpec CRD -A [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) (CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl#L131-L148) and save it as gmsa-crd.yaml. +A [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) (CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml. Next, install the CRD with `kubectl apply -f gmsa-crd.yaml` #### Install webhooks to validate GMSA users @@ -41,7 +41,7 @@ Two webhooks need to be configured on the Kubernetes cluster to populate and val 1. A mutating webhook that expands references to GMSAs (by name from a pod specification) into the full credential spec in JSON form within the pod spec. 2. A validating webhook ensures all references to GMSAs are authorized to be used by the pod service account. -Installing the above webhooks and associated objects require the steps below: +Installing the above webhooks and associated objects requires the steps below: 1. Create a certificate key pair (that will be used to allow the webhook container to communicate to the cluster) 2. Install a secret with the certificate from above. 3. Create a deployment for the core webhook logic. @@ -51,14 +51,19 @@ A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) used by the script may also be used to deploy the webhooks and associated objects manually (with appropriate substitutions for the parameters) +### Configuration of GMSAs and Windows cluster nodes in Active Directory +Before pods in Kubernetes can be configured to use GMSAs, the following configuration steps are necessary in Active Directory: +1. The desired GMSAs need to be provisioned in Active Directory as described [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1) +2. Windows worker nodes need to be configured in Active Directory to access the secret credentials associated with a GMSA as described [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet) + ### Configuration and usage of GMSAs in pods -This section covers the set of steps necessary for configuring individual GMSA credentials and using them in pods. These include: +This section covers the set of steps necessary for configuring individual GMSA credential specs in Kubernetes and using them in pods. The steps include: 1. Creating GMSA credential spec resources. 2. Creating cluster roles to allow service accounts to use specific GMSA credential spec resources. 3. Binding roles to specific service accounts to allow them to use the desired GMSA credential spec resources. 4. Configuring pods with a service account authorized to use the desired GMSA credential specs. -#### Create GMSA credspec resources +#### Create GMSA credential spec resources With the GMSACredentialSpec CRD installed, custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1). Following are the steps for generating a GMSA credential spec YAML manually in JSON format and then converting it: @@ -126,12 +131,12 @@ subjects: namespace: default roleRef: kind: ClusterRole - name: my-rbac-reader + name: webapp1-role apiGroup: rbac.authorization.k8s.io ``` #### Configure GMSA credential spec reference in pod spec -In the alpha stage of the feature, the annotation `pod.alpha.windows.kubernetes.io/gmsa-credential-spec-name` is used to specify references to desired GMSA credential spec custom resources from pod specs. This configures all containers in the podspec to use the specified GMSA. A sample pod spec with the annotation populated to refer to `gmsa-WebApp1`: +In the alpha stage of the feature, the annotation `pod.alpha.windows.kubernetes.io/gmsa-credential-spec-name` is used to specify references to desired GMSA credential spec custom resources in pod specs. This configures all containers in the pod spec to use the specified GMSA. A sample pod spec with the annotation populated to refer to `gmsa-WebApp1`: ``` apiVersion: apps/v1beta1 @@ -191,4 +196,10 @@ spec: beta.kubernetes.io/os: windows ``` +### Conclusion +As pod specs with GMSA annotations (as described above) are applied in a cluster configured for GMSA, the following sequence of events will take place: +1. The mutating webhook will resolve and expand all references to GMSA credential spec resources to the contents of the GMSA credential spec. +2. The validating webhook will ensure the service account associated with the pod is authorized for the "use" verb on the specified GMSA credential spec. +3. The container runtime will configure each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity. + {{% /capture %}} From 86fa8b2f8b879230497ecf43c751ec7fb97816ee Mon Sep 17 00:00:00 2001 From: Jeremy Wood <36464809+JeremyWx@users.noreply.github.com> Date: Sun, 17 Mar 2019 18:33:01 -0400 Subject: [PATCH 2/9] Update configure-gmsa.md --- .../configure-pod-container/configure-gmsa.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md index e94b88d39c97a..f53599a674448 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md @@ -16,13 +16,13 @@ In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide 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 >}} -{{% /capture %}} - -{{% capture body %}} - ## Setup and configuration for GMSA Configuring GMSA credential specs in the cluster and configuring individual pods and containers to be able to use them requires several steps described in detail below. +{{% /capture %}} + +{{% capture prerequisites %}} + ### Initial configuration of Kubernetes cluster to use GMSA This section covers a set of initial steps required once for each cluster. These include: 1. Enabling the `WindowsGMSA` feature gate on kubelet on the Windows nodes you'll use to run GMSA-dependent workloads. @@ -56,6 +56,10 @@ Before pods in Kubernetes can be configured to use GMSAs, the following configur 1. The desired GMSAs need to be provisioned in Active Directory as described [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1) 2. Windows worker nodes need to be configured in Active Directory to access the secret credentials associated with a GMSA as described [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet) +{{% /capture %}} + +{{% capture steps %}} + ### Configuration and usage of GMSAs in pods This section covers the set of steps necessary for configuring individual GMSA credential specs in Kubernetes and using them in pods. The steps include: 1. Creating GMSA credential spec resources. @@ -196,6 +200,10 @@ spec: beta.kubernetes.io/os: windows ``` +{{% /capture %}} + +{{% capture body %}} + ### Conclusion As pod specs with GMSA annotations (as described above) are applied in a cluster configured for GMSA, the following sequence of events will take place: 1. The mutating webhook will resolve and expand all references to GMSA credential spec resources to the contents of the GMSA credential spec. From 7a539c7282ff83583137728f423eb5832af813af Mon Sep 17 00:00:00 2001 From: Deep Debroy Date: Sun, 17 Mar 2019 21:12:00 -0700 Subject: [PATCH 3/9] Reformat to align headings and pre-reqs better Signed-off-by: Deep Debroy --- .../configure-pod-container/configure-gmsa.md | 32 +++++-------------- 1 file changed, 8 insertions(+), 24 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md index f53599a674448..b3f7144b54ffe 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md @@ -16,27 +16,23 @@ In Kubernetes, GMSA credential specs are configured at a Kubernetes cluster-wide 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 >}} -## Setup and configuration for GMSA -Configuring GMSA credential specs in the cluster and configuring individual pods and containers to be able to use them requires several steps described in detail below. - {{% /capture %}} {{% capture prerequisites %}} -### Initial configuration of Kubernetes cluster to use GMSA -This section covers a set of initial steps required once for each cluster. These include: +You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running windows workloads requiring GMSA credentials will get scheduled. This section covers a set of initial steps required once for each cluster. These include: 1. Enabling the `WindowsGMSA` feature gate on kubelet on the Windows nodes you'll use to run GMSA-dependent workloads. 2. Installing the GMSACredentialSpec Custom Resource Definition (CRD). 3. Installing two GMSA admission webhooks to expand and validate references to GMSA credential spec resources from pod specs. -#### Enable the WindowsGMSA feature gate +### Enable the WindowsGMSA feature gate In the alpha state, the `WindowsGMSA` feature gate needs to be enabled on kubelet on Windows nodes. This is required to pass down the GMSA credential specs from the cluster scoped configurations to the container runtime. See [Feature Gates](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) for an explanation of enabling feature gates. Please make sure `--feature-gates=WindowsGMSA=true` parameter exists in the kubelet.exe command line. -#### Install the GMSACredentialSpec CRD +### Install the GMSACredentialSpec CRD A [CustomResourceDefinition](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) (CRD) for GMSA credential spec resources needs to be configured on the cluster to define the custom resource type `GMSACredentialSpec`. Download the GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml) and save it as gmsa-crd.yaml. Next, install the CRD with `kubectl apply -f gmsa-crd.yaml` -#### Install webhooks to validate GMSA users +### Install webhooks to validate GMSA users Two webhooks need to be configured on the Kubernetes cluster to populate and validate GMSA credential spec references at the pod or container level: 1. A mutating webhook that expands references to GMSAs (by name from a pod specification) into the full credential spec in JSON form within the pod spec. 2. A validating webhook ensures all references to GMSAs are authorized to be used by the pod service account. @@ -60,14 +56,7 @@ Before pods in Kubernetes can be configured to use GMSAs, the following configur {{% capture steps %}} -### Configuration and usage of GMSAs in pods -This section covers the set of steps necessary for configuring individual GMSA credential specs in Kubernetes and using them in pods. The steps include: -1. Creating GMSA credential spec resources. -2. Creating cluster roles to allow service accounts to use specific GMSA credential spec resources. -3. Binding roles to specific service accounts to allow them to use the desired GMSA credential spec resources. -4. Configuring pods with a service account authorized to use the desired GMSA credential specs. - -#### Create GMSA credential spec resources +## Create GMSA credential spec resources With the GMSACredentialSpec CRD installed, custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1). Following are the steps for generating a GMSA credential spec YAML manually in JSON format and then converting it: @@ -104,7 +93,7 @@ credspec: 5. Deploy the credential spec resource: `kubectl apply -f gmsa-Webapp1-credspec.yml` -#### Configure cluster role to enable RBAC on specific GMSA credential specs +## Configure cluster role to enable RBAC on specific GMSA credential specs A cluster role needs to be defined for each GMSA credential spec resource. This authorizes the `use` verb on a specific GMSA resource by a subject which is typically a service account. The following example shows a cluster role that authorizes usage of the `gmsa-WebApp1` credential spec from above. Save the file as gmsa-webapp1-role.yaml and apply using `kubectl apply -f gmsa-webapp1-role.yaml` ``` @@ -120,7 +109,7 @@ rules: resourceNames: ["gmsa-WebApp1"] ``` -#### Assign role to service accounts to use specific GMSA credspecs +## Assign role to service accounts to use specific GMSA credspecs A service account (that pods will be configured with) needs to be bound to the cluster role create above. This authorizes the service account to "use" the desired GMSA credential spec resource. The following shows the default service account being bound to a cluster role `webapp1-role` to use `gmsa-WebApp1` credential spec resource created above. ``` @@ -139,7 +128,7 @@ roleRef: apiGroup: rbac.authorization.k8s.io ``` -#### Configure GMSA credential spec reference in pod spec +## Configure GMSA credential spec reference in pod spec In the alpha stage of the feature, the annotation `pod.alpha.windows.kubernetes.io/gmsa-credential-spec-name` is used to specify references to desired GMSA credential spec custom resources in pod specs. This configures all containers in the pod spec to use the specified GMSA. A sample pod spec with the annotation populated to refer to `gmsa-WebApp1`: ``` @@ -200,11 +189,6 @@ spec: beta.kubernetes.io/os: windows ``` -{{% /capture %}} - -{{% capture body %}} - -### Conclusion As pod specs with GMSA annotations (as described above) are applied in a cluster configured for GMSA, the following sequence of events will take place: 1. The mutating webhook will resolve and expand all references to GMSA credential spec resources to the contents of the GMSA credential spec. 2. The validating webhook will ensure the service account associated with the pod is authorized for the "use" verb on the specified GMSA credential spec. From 7bb1c06aab9b0f78dce8652d59c617038e3cb7d0 Mon Sep 17 00:00:00 2001 From: Deep Debroy Date: Sun, 17 Mar 2019 23:27:05 -0700 Subject: [PATCH 4/9] Reformat to align headings and pre-reqs better Signed-off-by: Deep Debroy --- .../configure-pod-container/configure-gmsa.md | 50 +++++++++++-------- 1 file changed, 29 insertions(+), 21 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md index b3f7144b54ffe..a9758c65f536a 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md @@ -20,10 +20,7 @@ Currently this feature is in alpha state. While the overall goals and functional {{% capture prerequisites %}} -You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running windows workloads requiring GMSA credentials will get scheduled. This section covers a set of initial steps required once for each cluster. These include: -1. Enabling the `WindowsGMSA` feature gate on kubelet on the Windows nodes you'll use to run GMSA-dependent workloads. -2. Installing the GMSACredentialSpec Custom Resource Definition (CRD). -3. Installing two GMSA admission webhooks to expand and validate references to GMSA credential spec resources from pod specs. +You need to have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running windows workloads requiring GMSA credentials will get scheduled. This section covers a set of initial steps required once for each cluster: ### Enable the WindowsGMSA feature gate In the alpha state, the `WindowsGMSA` feature gate needs to be enabled on kubelet on Windows nodes. This is required to pass down the GMSA credential specs from the cluster scoped configurations to the container runtime. See [Feature Gates](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) for an explanation of enabling feature gates. Please make sure `--feature-gates=WindowsGMSA=true` parameter exists in the kubelet.exe command line. @@ -34,36 +31,44 @@ Next, install the CRD with `kubectl apply -f gmsa-crd.yaml` ### Install webhooks to validate GMSA users Two webhooks need to be configured on the Kubernetes cluster to populate and validate GMSA credential spec references at the pod or container level: + 1. A mutating webhook that expands references to GMSAs (by name from a pod specification) into the full credential spec in JSON form within the pod spec. -2. A validating webhook ensures all references to GMSAs are authorized to be used by the pod service account. -Installing the above webhooks and associated objects requires the steps below: +1. A validating webhook ensures all references to GMSAs are authorized to be used by the pod service account. + +Installing the above webhooks and associated objects require the steps below: + 1. Create a certificate key pair (that will be used to allow the webhook container to communicate to the cluster) -2. Install a secret with the certificate from above. -3. Create a deployment for the core webhook logic. -4. Create the validating and mutating webhook configurations referring to the deployment. + +1. Install a secret with the certificate from above. + +1. Create a deployment for the core webhook logic. + +1. Create the validating and mutating webhook configurations referring to the deployment. A [script](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh) can be used to deploy and configure the GMSA webhooks and associated objects mentioned above. The script can be run with a ```--dry-run``` option to allow you to review the changes that would be made to your cluster. The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-webhook.yml.tpl) used by the script may also be used to deploy the webhooks and associated objects manually (with appropriate substitutions for the parameters) -### Configuration of GMSAs and Windows cluster nodes in Active Directory -Before pods in Kubernetes can be configured to use GMSAs, the following configuration steps are necessary in Active Directory: -1. The desired GMSAs need to be provisioned in Active Directory as described [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1) -2. Windows worker nodes need to be configured in Active Directory to access the secret credentials associated with a GMSA as described [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet) - {{% /capture %}} {{% capture steps %}} +## Configure GMSAs and Windows nodes in Active Directory +Before pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need to be provisioned in Active Directory as described [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1). Windows worker nodes (that are part of the Kubernetes cluster) need to be configured in Active Directory to access the secret credentials associated with the desired GMSA as described [here](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#to-add-member-hosts-using-the-set-adserviceaccount-cmdlet) + ## Create GMSA credential spec resources -With the GMSACredentialSpec CRD installed, custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1). +With the GMSACredentialSpec CRD installed (as described earlier), custom resources containing GMSA credential specs can be configured. The GMSA credential spec does not contain secret or sensitive data. It is information that a container runtime can use to describe the desired GMSA of a container to Windows. GMSA credential specs can be generated in YAML format with a utility [PowerShell script](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1). Following are the steps for generating a GMSA credential spec YAML manually in JSON format and then converting it: + 1. Import the CredentialSpec [module](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1` -2. Create a credential spec in JSON format using `New-CredentialSpec`. To create a GMSA credential spec named WebApp1, invoke `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)` -3. Use `Get-CredentialSpec` to show the path of the JSON file. -4. Convert the credspec file from JSON to YAML format and apply the necessary header fields `apiVersion`, `kind`, `metadata` and `credspec` to make it a GMSACredentialSpec custom resource that can be configured in Kubernetes. + +1. Create a credential spec in JSON format using `New-CredentialSpec`. To create a GMSA credential spec named WebApp1, invoke `New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)` + +1. Use `Get-CredentialSpec` to show the path of the JSON file. + +1. Convert the credspec file from JSON to YAML format and apply the necessary header fields `apiVersion`, `kind`, `metadata` and `credspec` to make it a GMSACredentialSpec custom resource that can be configured in Kubernetes. The following YAML configuration describes a GMSA credential spec named `gmsa-WebApp1`: @@ -90,7 +95,7 @@ credspec: Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID of GMSA ``` -5. Deploy the credential spec resource: `kubectl apply -f gmsa-Webapp1-credspec.yml` +1. Deploy the credential spec resource: `kubectl apply -f gmsa-Webapp1-credspec.yml` ## Configure cluster role to enable RBAC on specific GMSA credential specs @@ -190,8 +195,11 @@ spec: ``` As pod specs with GMSA annotations (as described above) are applied in a cluster configured for GMSA, the following sequence of events will take place: + 1. The mutating webhook will resolve and expand all references to GMSA credential spec resources to the contents of the GMSA credential spec. -2. The validating webhook will ensure the service account associated with the pod is authorized for the "use" verb on the specified GMSA credential spec. -3. The container runtime will configure each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity. + +1. The validating webhook will ensure the service account associated with the pod is authorized for the "use" verb on the specified GMSA credential spec. + +1. The container runtime will configure each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity. {{% /capture %}} From 4f8d6bf26f757121d320ee76b44f1cad89ea8b55 Mon Sep 17 00:00:00 2001 From: Deep Debroy Date: Sun, 17 Mar 2019 23:42:56 -0700 Subject: [PATCH 5/9] Reformat to fix bullets Signed-off-by: Deep Debroy --- .../en/docs/tasks/configure-pod-container/configure-gmsa.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md index a9758c65f536a..c0cde5986071d 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md @@ -95,8 +95,7 @@ credspec: Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID of GMSA ``` -1. Deploy the credential spec resource: `kubectl apply -f gmsa-Webapp1-credspec.yml` - +Apply the above credential spec resource using: `kubectl apply -f gmsa-Webapp1-credspec.yml` ## Configure cluster role to enable RBAC on specific GMSA credential specs A cluster role needs to be defined for each GMSA credential spec resource. This authorizes the `use` verb on a specific GMSA resource by a subject which is typically a service account. The following example shows a cluster role that authorizes usage of the `gmsa-WebApp1` credential spec from above. Save the file as gmsa-webapp1-role.yaml and apply using `kubectl apply -f gmsa-webapp1-role.yaml` From 1a2911b1284cdfbe20c302b5f0bb6e0f99e7b4af Mon Sep 17 00:00:00 2001 From: Deep Debroy Date: Sun, 17 Mar 2019 23:47:49 -0700 Subject: [PATCH 6/9] Reword application of sample gmsa Signed-off-by: Deep Debroy --- content/en/docs/tasks/configure-pod-container/configure-gmsa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md index c0cde5986071d..14c1bc377fa6a 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md @@ -95,7 +95,7 @@ credspec: Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID of GMSA ``` -Apply the above credential spec resource using: `kubectl apply -f gmsa-Webapp1-credspec.yml` +The above credential spec resource may be saved as `gmsa-Webapp1-credspec.yaml` and applied to the cluster using: `kubectl apply -f gmsa-Webapp1-credspec.yml` ## Configure cluster role to enable RBAC on specific GMSA credential specs A cluster role needs to be defined for each GMSA credential spec resource. This authorizes the `use` verb on a specific GMSA resource by a subject which is typically a service account. The following example shows a cluster role that authorizes usage of the `gmsa-WebApp1` credential spec from above. Save the file as gmsa-webapp1-role.yaml and apply using `kubectl apply -f gmsa-webapp1-role.yaml` From 8ac0598ed5336885fa019dbc9302fbbe54795327 Mon Sep 17 00:00:00 2001 From: Michael Michael Date: Mon, 18 Mar 2019 10:53:15 -0500 Subject: [PATCH 7/9] Update configure-gmsa.md --- content/en/docs/tasks/configure-pod-container/configure-gmsa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md index 14c1bc377fa6a..d048e0feab66a 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md @@ -20,7 +20,7 @@ Currently this feature is in alpha state. While the overall goals and functional {{% capture prerequisites %}} -You need to have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running windows workloads requiring GMSA credentials will get scheduled. This section covers a set of initial steps required once for each cluster: +You need to have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. The cluster is expected to have Windows worker nodes where pods with containers running Windows workloads requiring GMSA credentials will get scheduled. This section covers a set of initial steps required once for each cluster: ### Enable the WindowsGMSA feature gate In the alpha state, the `WindowsGMSA` feature gate needs to be enabled on kubelet on Windows nodes. This is required to pass down the GMSA credential specs from the cluster scoped configurations to the container runtime. See [Feature Gates](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) for an explanation of enabling feature gates. Please make sure `--feature-gates=WindowsGMSA=true` parameter exists in the kubelet.exe command line. From ebec9336d08bcb24d4c46df93d3d69b90ed2b078 Mon Sep 17 00:00:00 2001 From: Deep Debroy Date: Mon, 18 Mar 2019 09:26:17 -0700 Subject: [PATCH 8/9] Address feedback to use active voice Signed-off-by: Deep Debroy --- .../en/docs/tasks/configure-pod-container/configure-gmsa.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md index d048e0feab66a..97a34a4cf4da5 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md @@ -195,10 +195,10 @@ spec: As pod specs with GMSA annotations (as described above) are applied in a cluster configured for GMSA, the following sequence of events will take place: -1. The mutating webhook will resolve and expand all references to GMSA credential spec resources to the contents of the GMSA credential spec. +1. The mutating webhook resolves and expands all references to GMSA credential spec resources to the contents of the GMSA credential spec. -1. The validating webhook will ensure the service account associated with the pod is authorized for the "use" verb on the specified GMSA credential spec. +1. The validating webhook ensures the service account associated with the pod is authorized for the "use" verb on the specified GMSA credential spec. -1. The container runtime will configure each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity. +1. The container runtime configures each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity. {{% /capture %}} From 4765032262eef9677dab2101e8bd759272fde71c Mon Sep 17 00:00:00 2001 From: Deep Debroy Date: Mon, 18 Mar 2019 09:27:19 -0700 Subject: [PATCH 9/9] Address feedback to use active voice Signed-off-by: Deep Debroy --- content/en/docs/tasks/configure-pod-container/configure-gmsa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md index 97a34a4cf4da5..c6f43f96a8f49 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md @@ -193,7 +193,7 @@ spec: beta.kubernetes.io/os: windows ``` -As pod specs with GMSA annotations (as described above) are applied in a cluster configured for GMSA, the following sequence of events will take place: +As pod specs with GMSA annotations (as described above) are applied in a cluster configured for GMSA, the following sequence of events take place: 1. The mutating webhook resolves and expands all references to GMSA credential spec resources to the contents of the GMSA credential spec.