每个用户的 Kubernetes 秘密

Question

每个使用K8的人都有自己的NAS帐户。如果 Pod 需要写入 NAS，它会从该用户的密钥中访问凭据。我不希望用户能够看到其他人的秘密。我仍然希望用户能够为自己创建和使用秘密。如何才能做到这一点？

应该只有少量的用户定义的命名空间。 https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/ 因此，每个用户拥有一个命名空间似乎不是一个好的解决方案。即使我确实以这种方式实现，管理员也需要为每个用户设置一个 ClusterRole，以仅允许他们访问自己的命名空间。

也许秘密管理器有这个功能？

Answer 1

为了实现允许每个用户在 Kubernetes (K8s) 中创建和使用自己的机密来访问 NAS，同时防止他们看到其他用户的机密并且无需为每个用户创建命名空间的目标，您可以使用以下组合基于角色的访问控制 (RBAC) 和秘密管理工具。

方法1

对于每个用户，在共享命名空间中创建一个 Role 和 RoleBinding 。此角色应具有仅允许用户读取、创建和管理自己的机密的权限。您可以通过将角色定义中的

resourceNames

字段设置为允许用户访问的特定机密名称来完成此操作。

角色定义示例：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: shared-namespace
  name: user-specific-role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["user1-secret"]
  verbs: ["get", "list", "create", "update", "patch", "delete"]

使用 RoleBindings，将每个用户与其特定角色相关联。这确保他们只能与其角色允许的秘密进行交互。

角色绑定示例：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: user-specific-rolebinding
  namespace: shared-namespace
subjects:
- kind: User
  name: user1
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: user-specific-role
  apiGroup: rbac.authorization.k8s.io

方法2：

使用秘密管理工具，例如Azure Key Vault

创建您的 KV

转到secrets-> 手动生成您自己的信用或导入证书-> 进行相应选择。这里我使用的是手动方法。输入秘密的唯一名称。例如，使用类似

nas-credential-username

的命名约定，其中

username

是凭证所属用户的名称。输入 NAS 凭据。这可以是令牌、密码或 NAS 访问所需的任何其他形式的凭据。根据需要设置激活日期、到期日期和其他属性。重复为每个用户添加机密的过程，确保每个机密都有一个可以轻松与相应用户关联的唯一名称。

添加所有机密后，检查它们以确保它们配置正确。您可以单击密钥保管库中的每个机密以查看其详细信息。默认情况下，只有 Key Vault 管理员才有访问权限。稍后，您可以为需要在访问配置中检索这些机密的每个用户或应用程序设置特定的访问策略。 当需要使用这些机密时（例如，在 Kubernetes Pod 或任何应用程序中），您将需要向 Azure 进行身份验证才能检索机密值。具体步骤取决于应用程序的架构及其运行环境。要使用用于 Secrets Store CSI 驱动程序功能的 Azure Key Vault 提供程序升级现有 AKS 集群，您可以按照以下方法

az aks enable-addons --addons azure-keyvault-secrets-provider --name <yourclustername> --resource-group <yourRG>

您可以通过列出 kube-system 命名空间中具有

secrets-store-csi-driver

和

secrets-store-provider-azure

标签的所有 pod 来验证这一点，如下所示

kubectl get pods -n kube-system -l 'app in (secrets-store-csi-driver,secrets-store-provider-azure)'

然后转到您各自的 VMSS 并启用托管身份。

创建您的 SecretProvider 类

最后，您可以利用 CSI 并引用上面创建的 Secret Provider 类来安装卷。

两种方法各有利弊。 Kubernetes RBAC 是原生的，不需要额外的工具，但随着用户数量的增长，管理起来可能会很复杂。专用的秘密管理工具提供更多功能和可扩展性，但会增加基础设施的复杂性和潜在成本。

参考文档-

MS Doc-创建密钥库

MS Doc-从 Keyvault 设置和检索机密

MS Doc- 使用 Azure Key Vault 提供程序升级现有 AKS 集群以获取 Secrets。

从 Azure Kubernetes 服务中的 Azure Key Vault 访问机密的步骤

MS Doc-创建服务主体

类似的SO线程