使用 IAM 保护对资源的访问

Kubernetes 用户和服务账号需要拥有管理 Config Connector 资源的权限。借助 Config Connector，您可以使用 Kubernetes 基于角色的访问控制 (RBAC) 的身份来管理项目的控制平面。您还可以参考 Identity and Access Management (IAM) 政策。

资源参考文档中列出了可以引用 IAMPolicy 和 IAMPolicyMember 的资源。这些资源具有“可以由 IAMPolicy/IAMPolicyMember 引用”属性。

本主题介绍了如何使用 Identity and Access Management 保护对 Google Cloud 资源的访问。

准备工作

在集群上安装 Config Connector。

使用 RBAC 保护控制平面访问

在本例中，您将创建一个服务账号并向其授予管理 PubSubTopic 的权限。该服务账号无法管理其他类型的 Config Connector 资源。

  1. 创建一个名为 pubsub-topic-service-account.yaml 的文件，其中包含以下内容：

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: pubsub-topic-service-account
  namespace: default

    应用该文件来创建 pubsub-topic-service-account 服务账号：

    kubectl apply -f pubsub-topic-service-account.yaml --namespace CC_NAMESPACE

    将 CC_NAMESPACE 替换为 Config Connector 从其管理资源的命名空间。

  2. 通过验证以下命令的输出是否包含 no，来确认 pubsub-topic-service-account 无法创建 PubSubTopic 资源：

    kubectl auth can-i get pubsubtopics --as=system:serviceaccount:default:pubsub-topic-service-account

  3. 接下来，创建一个允许创建 Pub/Sub 主题的 ClusterRole。

    ClusterRole 只能管理在 rules.apiGroups 和 rules.resources 中指定了值的资源。如需查找 apiGroups 和 resources 的值，请参阅您的资源的参考文档。

    创建一个名为 pubsub-topic-editor-role.yaml 的文件，其中包含以下内容：

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: pubsub-topic-editor
rules:
- apiGroups:
  - pubsub.cnrm.cloud.google.com
  resources:
  - pubsubtopics
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete

    应用 pubsub-topic-editor.yaml 来创建 ClusterRole：

    kubectl apply -f pubsub-topic-editor-role.yaml --namespace CC_NAMESPACE

    将 CC_NAMESPACE 替换为 Config Connector 从其管理资源的命名空间。

  4. 接下来，在 ClusterRole 和您的服务账号之间创建一个 RoleBinding。创建一个名为 pubsub-topic-editor-rolebinding.yaml 的文件，其中包含以下内容：

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pubsub-topic-editor-rolebinding.
subjects:
- kind: ServiceAccount
  name: pubsub-topic-service-account
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: pubsub-topic-editor

  5. 将 pubsub-topic-editor-rolebinding.yaml 应用到您的集群。

    kubectl apply -f pubsub-topic-editor-rolebinding.yaml --namespace CC_NAMESPACE

    将 CC_NAMESPACE 替换为 Config Connector 从其管理资源的命名空间。

  6. 通过确认以下命令的输出为 yes，来确认允许 pubsub-topic-service-account 创建 PubSubTopic 资源：

    kubectl auth can-i get pubsubtopics \
  --as=system:serviceaccount:default:pubsub-topic-service-account

清理

使用 kubectl delete 移除服务账号、IAM 角色和角色绑定。

kubectl delete -f pubsub-topic-editor-rolebinding.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-editor-role.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-service-account.yaml --namespace CC_NAMESPACE

将 CC_NAMESPACE 替换为 Config Connector 从其管理资源的命名空间。

使用 IAM 政策保护数据平面

在本例中，您将使用先前授予的权限来创建 PubSubTopic，并使用 IAMPolicyMember 资源限制对它的访问。

  1. 创建一个名为 pubsub-topic-sample.yaml 的文件，其中包含以下内容：

    apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  name: pubsubtopic-sample

    使用 kubectl 应用 pubsub-topic-sample.yaml：

    kubectl apply -f pubsub-topic-sample.yaml --namespace CC_NAMESPACE

    将 CC_NAMESPACE 替换为 Config Connector 从其管理资源的命名空间。

  2. 创建一个名为 iampolicymember.yaml 的文件，其中包含以下内容，并将 EMAIL_ADDRESS 替换为您的 Google Cloud 账号的电子邮件地址：

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: iampolicymember-sample
spec:
  resourceRef:
    apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
    kind: PubSubTopic
    name: pubsubtopic-sample
  role: roles/pubsub.admin
  member: "user:EMAIL_ADDRESS"

  3. 应用 iampolicymember.yaml。

    kubectl apply -f iampolicymember.yaml  --namespace CC_NAMESPACE

    将 CC_NAMESPACE 替换为 Config Connector 从其管理资源的命名空间。

  4. 运行以下命令，并在输出中查找您的电子邮件地址，确认该政策已应用于 Google Cloud ，请将 PROJECT_ID 替换为您的项目 ID：

    gcloud beta pubsub topics get-iam-policy projects/PROJECT_ID/topics/pubsubtopic-sample

现在可以使用 IAMPolicyMember 保护对 Pub/Sub 主题的访问。

清理

使用 kubectl delete 从 Google Cloud 项目中移除 Pub/Sub 主题和 IAMPolicyMember。

kubectl delete -f iampolicymember.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-sample.yaml --namespace CC_NAMESPACE

多租户隔离的安全最佳实践

为帮助防止未经授权的提权并强制执行租户隔离，请遵循以下最佳实践：

  • 强制执行命名空间模式：在多租户环境中避免使用集群模式。在集群模式下，所有命名空间共享一个 IAM 服务账号。任何可以在任何命名空间中创建 Config Connector 资源的用户都可以使用该服务账号的完整 IAM 权限。

  • 限制 IAM 资源的 RBAC：使用 Kubernetes 基于角色的访问权限控制 (RBAC) 限制 IAMPolicy、IAMPartialPolicy 和 IAMPolicyMember 资源的创建和修改权限。如果开发者对这些资源具有广泛的写入权限，则可以更改 Google Cloud IAM 绑定。

  • 限定 Workload Identity Federation for GKE 的 IAM 绑定范围：严格为特定命名空间中的指定 Kubernetes ServiceAccount 配置这些绑定。在命名空间模式下，仅将每个 IAM 服务账号绑定到其命名空间的 Config Connector Kubernetes ServiceAccount：

    gcloud iam service-accounts add-iam-policy-binding \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member="serviceAccount:PROJECT_ID.svc.id.goog[cnrm-system/cnrm-controller-manager-CC_NAMESPACE]" \
    --role="roles/iam.workloadIdentityUser"

    替换以下内容：

    • GSA_NAME：Config Connector 用于命名空间的 IAM 服务账号的名称。
    • PROJECT_ID：包含集群和 IAM 服务账号的项目的 ID。
    • CC_NAMESPACE：Config Connector 管理资源的命名空间。

    请勿向主账号集（例如 cnrm-system 命名空间中的所有 Pod）授予 roles/iam.workloadIdentityUser 角色。在命名空间模式下，所有命名空间的 Config Connector 控制器都在 cnrm-system 中运行，因此这种类型的绑定允许每个命名空间的控制器模拟 IAM 服务账号。

后续步骤

使用密钥将信息安全地传递给 Google Cloud 资源。