Kubernetes Prow Robot
GitHub
commit
385fd4b381
|
|
@ -13,52 +13,65 @@ weight: 30
|
|||
{{< feature-state for_k8s_version="v1.18" state="stable" >}}
|
||||
|
||||
<!--
|
||||
This page shows how to configure [Group Managed Service Accounts](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (GMSA) for Pods and containers that will run on Windows nodes. Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers.
|
||||
This page shows how to configure
|
||||
[Group Managed Service Accounts](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview) (GMSA)
|
||||
for Pods and containers that will run on Windows nodes. Group Managed Service Accounts
|
||||
are a specific type of Active Directory account that provides automatic password management,
|
||||
simplified service principal name (SPN) management, and the ability to delegate the management
|
||||
to other administrators across multiple servers.
|
||||
-->
|
||||
本页展示如何为将运行在 Windows 节点上的 Pod 和容器配置
|
||||
[组管理的服务账号（Group Managed Service Accounts，GMSA）](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview)。
|
||||
组管理的服务账号是活动目录（Active Directory）的一种特殊类型，提供自动化的
|
||||
密码管理、简化的服务主体名称（Service Principal Name，SPN）管理以及跨多个
|
||||
服务器将管理操作委派给其他管理员等能力。
|
||||
[组管理的服务账号（Group Managed Service Accounts，GMSA）](https://docs.microsoft.com/zh-cn/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview)。
|
||||
组管理的服务账号是活动目录（Active Directory）的一种特殊类型，
|
||||
提供自动化的密码管理、简化的服务主体名称（Service Principal Name，SPN）
|
||||
管理以及跨多个服务器将管理操作委派给其他管理员等能力。
|
||||
|
||||
<!--
|
||||
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.
|
||||
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.
|
||||
-->
|
||||
在 Kubernetes 环境中，GMSA 凭据规约配置为 Kubernetes 集群范围的自定义资源
|
||||
（Custom Resources）形式。Windows Pod 以及各 Pod 中的每个容器可以配置为
|
||||
使用 GMSA 来完成基于域（Domain）的操作（例如，Kerberos 身份认证），以便
|
||||
与其他 Windows 服务相交互。
|
||||
（Custom Resources）形式。Windows Pod 以及各 Pod 中的每个容器可以配置为使用 GMSA
|
||||
来完成基于域（Domain）的操作（例如，Kerberos 身份认证），以便与其他 Windows 服务相交互。
|
||||
|
||||
## {{% heading "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. 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.
|
||||
This section covers a set of initial steps required once for each cluster:
|
||||
-->
|
||||
你需要一个 Kubernetes 集群，以及 `kubectl` 命令行工具，且工具必须已配置
|
||||
为能够与你的集群通信。集群预期包含 Windows 工作节点。
|
||||
你需要一个 Kubernetes 集群，以及 `kubectl` 命令行工具，
|
||||
且工具必须已配置为能够与你的集群通信。集群预期包含 Windows 工作节点。
|
||||
本节讨论需要为每个集群执行一次的初始操作。
|
||||
|
||||
<!--
|
||||
### Install the GMSACredentialSpec CRD
|
||||
|
||||
A [CustomResourceDefinition](/docs/tasks/extend-kubernetes/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`
|
||||
A [CustomResourceDefinition](/docs/tasks/extend-kubernetes/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`
|
||||
-->
|
||||
### 安装 GMSACredentialSpec CRD
|
||||
|
||||
你需要在集群上配置一个用于 GMSA 凭据规约资源的
|
||||
[CustomResourceDefinition](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)(CRD)，
|
||||
以便定义类型为 `GMSACredentialSpec` 的自定义资源。
|
||||
首先下载 GMSA CRD [YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml)
|
||||
并将其保存为 `gmsa-crd.yaml`。接下来执行 `kubectl apply -f gmsa-crd.yaml`
|
||||
安装 CRD。
|
||||
以便定义类型为 `GMSACredentialSpec` 的自定义资源。首先下载 GMSA CRD
|
||||
[YAML](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/gmsa-crd.yml)
|
||||
并将其保存为 `gmsa-crd.yaml`。接下来执行 `kubectl apply -f gmsa-crd.yaml` 安装 CRD。
|
||||
|
||||
<!--
|
||||
### 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:
|
||||
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.
|
||||
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.
|
||||
|
||||
1. A validating webhook ensures all references to GMSAs are authorized to be used by the Pod service account.
|
||||
-->
|
||||
|
|
@ -70,8 +83,8 @@ GMSA 凭据规约引用。
|
|||
1. 一个修改模式（Mutating）的 Webhook，将对 GMSA 的引用（在 Pod 规约中体现为名字）
|
||||
展开为完整凭据规约的 JSON 形式，并保存回 Pod 规约中。
|
||||
|
||||
1. 一个验证模式（Validating）的 Webhook，确保对 GMSA 的所有引用都是已经授权
|
||||
给 Pod 的服务账号使用的。
|
||||
1. 一个验证模式（Validating）的 Webhook，确保对 GMSA 的所有引用都是已经授权给
|
||||
Pod 的服务账号使用的。
|
||||
|
||||
<!--
|
||||
Installing the above webhooks and associated objects require the steps below:
|
||||
|
|
@ -82,7 +95,7 @@ Installing the above webhooks and associated objects require the steps below:
|
|||
|
||||
1. Create a deployment for the core webhook logic.
|
||||
|
||||
1. Create the validating and mutating webhook configurations referring to the deployment.
|
||||
1. Create the validating and mutating webhook configurations referring to the deployment.
|
||||
-->
|
||||
安装以上 Webhook 及其相关联的对象需要执行以下步骤：
|
||||
|
||||
|
|
@ -95,9 +108,14 @@ Installing the above webhooks and associated objects require the steps below:
|
|||
1. 创建引用该 Deployment 的 Validating Webhook 和 Mutating Webhook 配置
|
||||
|
||||
<!--
|
||||
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=server``` option to allow you to review the changes that would be made to your cluster.
|
||||
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=server` 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)
|
||||
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)
|
||||
-->
|
||||
你可以使用[这个脚本](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/admission-webhook/deploy/deploy-gmsa-webhook.sh)
|
||||
来部署和配置上述 GMSA Webhook 及相关联的对象。你还可以在运行脚本时设置 `--dry-run=server`
|
||||
|
|
@ -111,26 +129,37 @@ The [YAML template](https://github.com/kubernetes-sigs/windows-gmsa/blob/master/
|
|||
<!--
|
||||
## 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 in the [Windows GMSA documentation](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 in the [Windows GMSA documentation](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)
|
||||
Before Pods in Kubernetes can be configured to use GMSAs, the desired GMSAs need
|
||||
to be provisioned in Active Directory as described in the
|
||||
[Windows GMSA documentation](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 in the
|
||||
[Windows GMSA documentation](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).
|
||||
-->
|
||||
## 在活动目录中配置 GMSA 和 Windows 节点
|
||||
|
||||
在配置 Kubernetes 中的 Pod 以使用 GMSA 之前，需要按
|
||||
[Windows GMSA 文档](https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Step1)
|
||||
中描述的那样先在活动目录中准备好期望的 GMSA。
|
||||
Windows 工作节点（作为 Kubernetes 集群的一部分）需要被配置到活动目录中，以便
|
||||
访问与期望的 GSMA 相关联的秘密凭据数据。这一操作的描述位于
|
||||
Windows 工作节点（作为 Kubernetes 集群的一部分）需要被配置到活动目录中，以便访问与期望的
|
||||
GSMA 相关联的秘密凭据数据。这一操作的描述位于
|
||||
[Windows GMSA 文档](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 (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).
|
||||
|
||||
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).
|
||||
-->
|
||||
## 创建 GMSA 凭据规约资源
|
||||
|
||||
当（如前所述）安装了 GMSACredentialSpec CRD 之后，你就可以配置包含 GMSA 凭据
|
||||
规约的自定义资源了。GMSA 凭据规约中并不包含秘密或敏感数据。
|
||||
当（如前所述）安装了 GMSACredentialSpec CRD 之后，你就可以配置包含 GMSA
|
||||
凭据规约的自定义资源了。GMSA 凭据规约中并不包含秘密或敏感数据。
|
||||
其中包含的信息主要用于容器运行时，便于后者向 Windows 描述容器所期望的 GMSA。
|
||||
GMSA 凭据规约可以使用
|
||||
[PowerShell 脚本](https://github.com/kubernetes-sigs/windows-gmsa/tree/master/scripts/GenerateCredentialSpecResource.ps1)
|
||||
|
|
@ -139,17 +168,22 @@ GMSA 凭据规约可以使用
|
|||
<!--
|
||||
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`
|
||||
1. Import the CredentialSpec
|
||||
[module](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1`
|
||||
|
||||
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. 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.
|
||||
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.
|
||||
-->
|
||||
下面是手动以 JSON 格式生成 GMSA 凭据规约并对其进行 YAML 转换的步骤：
|
||||
|
||||
1. 导入 CredentialSpec [模块](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1): `ipmo CredentialSpec.psm1`
|
||||
1. 导入 CredentialSpec [模块](https://github.com/MicrosoftDocs/Virtualization-Documentation/blob/live/windows-server-container-tools/ServiceAccounts/CredentialSpec.psm1)：`ipmo CredentialSpec.psm1`
|
||||
|
||||
1. 使用 `New-CredentialSpec` 来创建一个 JSON 格式的凭据规约。
|
||||
要创建名为 `WebApp1` 的 GMSA 凭据规约，调用
|
||||
|
|
@ -168,23 +202,23 @@ The following YAML configuration describes a GMSA credential spec named `gmsa-We
|
|||
apiVersion: windows.k8s.io/v1
|
||||
kind: GMSACredentialSpec
|
||||
metadata:
|
||||
name: gmsa-WebApp1 #This is an arbitrary name but it will be used as a reference
|
||||
name: gmsa-WebApp1 # This is an arbitrary name but it will be used as a reference
|
||||
credspec:
|
||||
ActiveDirectoryConfig:
|
||||
GroupManagedServiceAccounts:
|
||||
- Name: WebApp1 #Username of the GMSA account
|
||||
Scope: CONTOSO #NETBIOS Domain Name
|
||||
- Name: WebApp1 #Username of the GMSA account
|
||||
Scope: contoso.com #DNS Domain Name
|
||||
- Name: WebApp1 # Username of the GMSA account
|
||||
Scope: CONTOSO # NETBIOS Domain Name
|
||||
- Name: WebApp1 # Username of the GMSA account
|
||||
Scope: contoso.com # DNS Domain Name
|
||||
CmsPlugins:
|
||||
- ActiveDirectory
|
||||
DomainJoinConfig:
|
||||
DnsName: contoso.com #DNS Domain Name
|
||||
DnsTreeName: contoso.com #DNS Domain Name Root
|
||||
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a #GUID
|
||||
MachineAccountName: WebApp1 #Username of the GMSA account
|
||||
NetBiosName: CONTOSO #NETBIOS Domain Name
|
||||
Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID of GMSA
|
||||
DnsName: contoso.com # DNS Domain Name
|
||||
DnsTreeName: contoso.com # DNS Domain Name Root
|
||||
Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a # GUID
|
||||
MachineAccountName: WebApp1 # Username of the GMSA account
|
||||
NetBiosName: CONTOSO # NETBIOS Domain Name
|
||||
Sid: S-1-5-21-2126449477-2524075714-3094792973 # SID of GMSA
|
||||
```
|
||||
-->
|
||||
下面的 YAML 配置描述的是一个名为 `gmsa-WebApp1` 的 GMSA 凭据规约：
|
||||
|
|
@ -213,7 +247,8 @@ credspec:
|
|||
```
|
||||
|
||||
<!--
|
||||
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`
|
||||
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`
|
||||
-->
|
||||
上面的凭据规约资源可以保存为 `gmsa-Webapp1-credspec.yaml`，之后使用
|
||||
`kubectl apply -f gmsa-Webapp1-credspec.yml` 应用到集群上。
|
||||
|
|
@ -221,7 +256,11 @@ The above credential spec resource may be saved as `gmsa-Webapp1-credspec.yaml`
|
|||
<!--
|
||||
## 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`
|
||||
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`
|
||||
-->
|
||||
## 配置集群角色以启用对特定 GMSA 凭据规约的 RBAC
|
||||
|
||||
|
|
@ -232,7 +271,7 @@ A cluster role needs to be defined for each GMSA credential spec resource. This
|
|||
|
||||
<!--
|
||||
```yaml
|
||||
#Create the Role to read the credspec
|
||||
# Create the Role to read the credspec
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
|
|
@ -260,14 +299,17 @@ rules:
|
|||
<!--
|
||||
## 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.
|
||||
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.
|
||||
-->
|
||||
## 将角色指派给要使用特定 GMSA 凭据规约的服务账号
|
||||
|
||||
你需要将某个服务账号（Pod 配置所对应的那个）绑定到前文创建的集群角色上。
|
||||
这一绑定操作实际上授予该服务账号使用所指定的 GMSA 凭据规约资源的访问权限。
|
||||
下面显示的是一个绑定到集群角色 `webapp1-role` 上的 default 服务账号，使之
|
||||
能够使用前面所创建的 `gmsa-WebApp1` 凭据规约资源。
|
||||
下面显示的是一个绑定到集群角色 `webapp1-role` 上的 default 服务账号，
|
||||
使之能够使用前面所创建的 `gmsa-WebApp1` 凭据规约资源。
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
|
|
@ -288,12 +330,15 @@ roleRef:
|
|||
<!--
|
||||
## Configure GMSA credential spec reference in Pod spec
|
||||
|
||||
The Pod spec field `securityContext.windowsOptions.gmsaCredentialSpecName` 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`:
|
||||
The Pod spec field `securityContext.windowsOptions.gmsaCredentialSpecName` 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`:
|
||||
-->
|
||||
## 在 Pod 规约中配置 GMSA 凭据规约引用
|
||||
|
||||
Pod 规约字段 `securityContext.windowsOptions.gmsaCredentialSpecName` 可用来
|
||||
设置对指定 GMSA 凭据规约自定义资源的引用。
|
||||
Pod 规约字段 `securityContext.windowsOptions.gmsaCredentialSpecName`
|
||||
可用来设置对指定 GMSA 凭据规约自定义资源的引用。
|
||||
设置此引用将会配置 Pod 中的所有容器使用所给的 GMSA。
|
||||
下面是一个 Pod 规约示例，其中包含了对 `gmsa-WebApp1` 凭据规约的引用：
|
||||
|
||||
|
|
@ -327,11 +372,11 @@ spec:
|
|||
```
|
||||
|
||||
<!--
|
||||
Individual containers in a Pod spec can also specify the desired GMSA credspec using a per-container `securityContext.windowsOptions.gmsaCredentialSpecName` field. For example:
|
||||
Individual containers in a Pod spec can also specify the desired GMSA credspec
|
||||
using a per-container `securityContext.windowsOptions.gmsaCredentialSpecName` field. For example:
|
||||
-->
|
||||
Pod 中的各个容器也可以使用对应容器的 `securityContext.windowsOptions.gmsaCredentialSpecName`
|
||||
字段来设置期望使用的 GMSA 凭据规约。
|
||||
例如：
|
||||
字段来设置期望使用的 GMSA 凭据规约。例如：
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
|
|
@ -363,25 +408,28 @@ spec:
|
|||
```
|
||||
|
||||
<!--
|
||||
As Pod specs with GMSA fields populated (as described above) are applied in a cluster, the following sequence of events take place:
|
||||
As Pod specs with GMSA fields populated (as described above) are applied in a cluster,
|
||||
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.
|
||||
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 ensures 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 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.
|
||||
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.
|
||||
-->
|
||||
当 Pod 规约中填充了 GMSA 相关字段（如上所述），在集群中应用 Pod 规约时会依次
|
||||
发生以下事件：
|
||||
当 Pod 规约中填充了 GMSA 相关字段（如上所述），在集群中应用 Pod 规约时会依次发生以下事件：
|
||||
|
||||
1. Mutating Webhook 解析对 GMSA 凭据规约资源的引用，并将其全部展开，
|
||||
得到 GMSA 凭据规约的实际内容。
|
||||
|
||||
1. Validating Webhook 确保与 Pod 相关联的服务账号有权在所给的 GMSA 凭据规约
|
||||
上执行 `use` 动作。
|
||||
1. Validating Webhook 确保与 Pod 相关联的服务账号有权在所给的 GMSA 凭据规约上执行 `use` 动作。
|
||||
|
||||
1. 容器运行时为每个 Windows 容器配置所指定的 GMSA 凭据规约，这样容器就可以以
|
||||
活动目录中该 GMSA 所代表的身份来执行操作，使用该身份来访问域中的服务。
|
||||
1. 容器运行时为每个 Windows 容器配置所指定的 GMSA 凭据规约，
|
||||
这样容器就可以以活动目录中该 GMSA 所代表的身份来执行操作，使用该身份来访问域中的服务。
|
||||
|
||||
<!--
|
||||
## Authenticating to network shares using hostname or FQDN
|
||||
|
|
@ -389,7 +437,8 @@ As Pod specs with GMSA fields populated (as described above) are applied in a cl
|
|||
## 使用主机名或 FQDN 对网络共享进行身份验证
|
||||
|
||||
<!--
|
||||
If you are experiencing issues connecting to SMB shares from Pods using hostname or FQDN, but are able to access the shares via their IPv4 address then make sure the following registry key is set on the Windows nodes.
|
||||
If you are experiencing issues connecting to SMB shares from Pods using hostname or FQDN,
|
||||
but are able to access the shares via their IPv4 address then make sure the following registry key is set on the Windows nodes.
|
||||
-->
|
||||
如果你在使用主机名或 FQDN 从 Pod 连接到 SMB 共享时遇到问题，但能够通过其 IPv4 地址访问共享，
|
||||
请确保在 Windows 节点上设置了以下注册表项。
|
||||
|
|
@ -400,22 +449,25 @@ reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentN
|
|||
|
||||
<!--
|
||||
Running Pods will then need to be recreated to pick up the behavior changes.
|
||||
More information on how this registry key is used can be found [here](
|
||||
https://github.com/microsoft/hcsshim/blob/885f896c5a8548ca36c88c4b87fd2208c8d16543/internal/uvm/create.go#L74-L83)
|
||||
More information on how this registry key is used can be found
|
||||
[here](https://github.com/microsoft/hcsshim/blob/885f896c5a8548ca36c88c4b87fd2208c8d16543/internal/uvm/create.go#L74-L83)
|
||||
-->
|
||||
然后需要重新创建正在运行的 Pod 以使行为更改生效。
|
||||
有关如何使用此注册表项的更多信息，请参见[此处](https://github.com/microsoft/hcsshim/blob/885f896c5a8548ca36c88c4b87fd2208c8d16543/internal/uvm/create.go#L74-L83)。
|
||||
然后需要重新创建正在运行的 Pod 以使行为更改生效。有关如何使用此注册表项的更多信息，
|
||||
请参见[此处](https://github.com/microsoft/hcsshim/blob/885f896c5a8548ca36c88c4b87fd2208c8d16543/internal/uvm/create.go#L74-L83)。
|
||||
|
||||
<!--
|
||||
## Troubleshooting
|
||||
|
||||
If you are having difficulties getting GMSA to work in your environment, there are a few troubleshooting steps you can take.
|
||||
If you are having difficulties getting GMSA to work in your environment,
|
||||
there are a few troubleshooting steps you can take.
|
||||
-->
|
||||
## 故障排查
|
||||
|
||||
如果在你的环境中配置 GMSA 时遇到了困难，你可以采取若干步骤来排查可能的故障。
|
||||
|
||||
<!--
|
||||
First, make sure the credspec has been passed to the Pod. To do this you will need to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.
|
||||
First, make sure the credspec has been passed to the Pod. To do this you will need
|
||||
to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command.
|
||||
-->
|
||||
首先，确保 credspec 已传递给 Pod。为此，你需要先运行 `exec`
|
||||
进入到你的一个 Pod 中并检查 `nltest.exe /parentdomain` 命令的输出。
|
||||
|
|
@ -439,7 +491,8 @@ Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
|
|||
```
|
||||
|
||||
<!--
|
||||
If your Pod did get the credspec correctly, then next check communication with the domain. First, from inside of your Pod, quickly do an nslookup to find the root of your domain.
|
||||
If your Pod did get the credspec correctly, then next check communication with the domain.
|
||||
First, from inside of your Pod, quickly do an nslookup to find the root of your domain.
|
||||
|
||||
This will tell us 3 things:
|
||||
|
||||
|
|
@ -457,11 +510,12 @@ This will tell us 3 things:
|
|||
1. DNS 是否正常工作
|
||||
|
||||
<!--
|
||||
If the DNS and communication test passes, next you will need to check if the Pod has established secure channel communication with the domain. To do this, again, `exec` into your Pod and run the `nltest.exe /query` command.
|
||||
If the DNS and communication test passes, next you will need to check if the Pod has
|
||||
established secure channel communication with the domain. To do this, again,
|
||||
`exec` into your Pod and run the `nltest.exe /query` command.
|
||||
-->
|
||||
如果 DNS 和通信测试通过，接下来你需要检查是否 Pod 已经与域之间建立了
|
||||
安全通信通道。要执行这一检查，你需要再次通过 `exec` 进入到你的 Pod 中
|
||||
并执行 `nltest.exe /query` 命令。
|
||||
如果 DNS 和通信测试通过，接下来你需要检查是否 Pod 已经与域之间建立了安全通信通道。
|
||||
要执行这一检查，你需要再次通过 `exec` 进入到你的 Pod 中并执行 `nltest.exe /query` 命令。
|
||||
|
||||
```PowerShell
|
||||
nltest.exe /query
|
||||
|
|
@ -477,7 +531,8 @@ I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
|
|||
```
|
||||
|
||||
<!--
|
||||
This tells us that for some reason, the Pod was unable to logon to the domain using the account specified in the credspec. You can try to repair the secure channel by running the following:
|
||||
This tells us that for some reason, the Pod was unable to logon to the domain using
|
||||
the account specified in the credspec. You can try to repair the secure channel by running the following:
|
||||
-->
|
||||
这告诉我们，由于某种原因，Pod 无法使用 credspec 中指定的帐户登录到域。
|
||||
你可以尝试通过运行以下命令来修复安全通道：
|
||||
|
|
@ -491,7 +546,7 @@ If the command is successful you will see and output similar to this:
|
|||
-->
|
||||
如果命令成功，你将看到类似以下内容的输出：
|
||||
|
||||
```
|
||||
```output
|
||||
Flags: 30 HAS_IP HAS_TIMESERV
|
||||
Trusted DC Name \\dc10.domain.example
|
||||
Trusted DC Connection Status Status = 0 0x0 NERR_Success
|
||||
|
|
@ -499,7 +554,9 @@ The command completed successfully
|
|||
```
|
||||
|
||||
<!--
|
||||
If the above corrects the error, you can automate the step by adding the following lifecycle hook to your Pod spec. If it did not correct the error, you will need to examine your credspec again and confirm that it is correct and complete.
|
||||
If the above corrects the error, you can automate the step by adding the following
|
||||
lifecycle hook to your Pod spec. If it did not correct the error, you will need to
|
||||
examine your credspec again and confirm that it is correct and complete.
|
||||
-->
|
||||
如果以上命令修复了错误，你可以通过将以下生命周期回调添加到你的 Pod 规约中来自动执行该步骤。
|
||||
如果这些操作没有修复错误，你将需要再次检查你的 credspec 并确认它是正确和完整的。
|
||||
|
|
@ -514,8 +571,9 @@ If the above corrects the error, you can automate the step by adding the followi
|
|||
```
|
||||
|
||||
<!--
|
||||
If you add the `lifecycle` section show above to your Pod spec, the Pod will execute the commands listed to restart the `netlogon` service until the `nltest.exe /query` command exits without error.
|
||||
If you add the `lifecycle` section show above to your Pod spec, the Pod will execute
|
||||
the commands listed to restart the `netlogon` service until the `nltest.exe /query` command exits without error.
|
||||
-->
|
||||
如果你向你的 Pod 规约中添加如上所示的 `lifecycle` 节，则 Pod 会自动执行所
|
||||
列举的命令来重启 `netlogon` 服务，直到 `nltest.exe /query`
|
||||
如果你向你的 Pod 规约中添加如上所示的 `lifecycle` 节，则 Pod
|
||||
会自动执行所列举的命令来重启 `netlogon` 服务，直到 `nltest.exe /query`
|
||||
命令返回时没有错误信息。
|
||||
|
|
|
|||
Loading…
Reference in New Issue