全部产品
Search
文档中心

容器服务 Kubernetes 版 ACK:通过ack-ram-authenticator完成ACK托管集群API Server的Webhook认证

更新时间:Oct 09, 2024

通过ack-ram-authenticator组件,ACK托管集群基于阿里云RAM,通过Webhook机制为API Server的访问请求提供更安全的身份验证;同时,在SSO角色对接场景下,支持更安全地审计不同用户在扮演相同角色时对集群API Server的访问请求。本文介绍基于ack-ram-authenticator组件的ACK托管集群API Server的Webhook认证方式和使用方法。

前提条件

已创建ACK托管集群,且集群为1.24.6-aliyun.1及以上版本。具体操作, 请参见创建ACK托管集群

注意事项

  • 安装和卸载ack-ram-authenticator组件均会重启集群控制面API Server,导致与API Server的长连接断连。请在业务低峰期进行组件的安装和卸载。

  • 开启Webhook认证后,不会影响DescribeClusterUserKubeconfig接口返回的KubeConfig对集群API Server的正常访问。

  • 已新增支持ACK Serverless集群

认证方式介绍

ack-ram-authenticator组件是面向ACK托管集群的认证插件,基于Kubernetes原生Webhook Token认证方式,实现通过RAM完成集群API Server的请求认证。同时,该组件通过CRD形式提供RAM身份和RBAC权限的映射关系,帮您更灵活地配置RBAC鉴权。

对于阿里云SSO角色对接使用ACK托管集群的场景, ack-ram-authenticator组件可以帮助您在请求API Server时,下发请求者身份对应的Session名称,从而更安全地审计不同用户在扮演相同角色后对集群API Server的访问请求。

使用ack-ram-authenticator组件后,集群的Webhook认证流程如下图所示。

123..png

  1. 当使用kubectl等工具发起对API Server的认证请求时,首先通过KubeConfig中的exec命令插件执行机制,执行ack-ram-tool客户端工具生成签名后的STS请求URL。

  2. 发送Webhook认证请求到ACK托管集群API Server,通过Webhook认证配置路由到ack-ram-authenticator组件。

  3. 基于接收到的Token URL请求对阿里云RAM GetCallerIdentity接口进行认证。若认证成功,在ack-ram-authenticator组件中会寻找接口返回的RAM身份和用户在指定RAMIdentityMapping的CR中配置的身份映射。

  4. API Server中对映射后的用户和用户组身份进行原生RBAC鉴权,并返回鉴权结果。

认证方式的优势

与ACK集群默认提供的x509证书认证模式相比,使用ack-ram-authenticator Webhook认证方式有以下优点。

  • 适配企业通过云SSO场景,提供灵活可控的数据面RBAC授权。

  • 在角色SSO对接场景下,API Server审计日志中包含企业IDP中的身份信息,有效支持对扮演同一角色的不同IDP用户的行为审计。

  • 当企业员工离职需删除RAM用户或RAM角色时,可自动清理其在集群中的RBAC权限。

步骤一:安装ack-ram-authenticator组件

开启RAM Webhook认证需要安装ack-ram-authenticator服务端认证插件,用于和集群API Server进行认证交互。您可以通过以下方式安装ack-ram-authenticator组件。

  1. 登录容器服务管理控制台,在左侧导航栏选择集群

  2. 集群列表页面,单击目标集群名称,然后在左侧导航栏,选择运维管理 > 组件管理

  3. 组件管理页面,单击安全页签,找到ack-ram-authenticator组件,单击卡片右下角的安装,然后单击确定

步骤二:安装ack-ram-tool客户端

通过ack-ram-tool客户端可以更方便地在本地自动生成指定集群的KubeConfig访问凭据。

  1. 根据指定环境的架构类型,下载ack-ram-tool客户端

  2. 执行以下命令,授予客户端程序的执行权限。

    chmod +x ./ack-ram-tool
  3. 执行以下命令,将ack-ram-tool文件拷贝至系统PATH指定目录。

     mkdir -p $HOME/bin && cp ./ack-ram-tool $HOME/bin/ack-ram-tool && export PATH=$HOME/bin:$PATH
  4. (可选)执行以下命令,持久化$HOME/bin中的PATH配置。

    echo 'export PATH=$HOME/bin:$PATH' >> ~/.bash_profile
    
  5. 执行以下命令,查看是否能够返回客户端组件对应的版本,以验证ack-ram-tool客户端组件是否安装成功。

    ack-ram-tool version

步骤三:配置阿里云凭据

阿里云RAM用户和SSO用户可通过以下方式配置获取云资源的访问凭据。

说明

如果当前环境中存在访问凭据相关的环境变量,ack-ram-tool将优先使用环境变量中配置的访问凭据。您可以通过在执行ack-ram-tool命令时增加参数--ignore-env-credentials的方式忽略这些环境变量。关于ack-ram-tool支持的凭据相关环境变量,请参见Credentials

RAM用户

ack-ram-tool客户端依赖本地配置的阿里云密钥凭据访问RAM进行身份认证。

关于配置资源访问凭证的具体操作,请参见阿里云CLI

SSO用户

对于阿里云云SSO的用户,可以通过使用云SSO服务提供的CLI工具acs-sso完成登录,并获取云资源访问凭据。关于acs-sso更多信息,请参见使用CLI登录云SSO并访问阿里云资源。阿里云CLI工具中支持external模式,可实现通过执行外部命令行工具的方式动态获取资源凭据。通过执行如下命令,在本地完成云SSO登录和凭据的自动化配置。

aliyun configure --mode External --profile sso

Configuring profile 'sso' in 'External' authenticate mode...
Process Command [acs-sso login --profile sso]:
Default Region Id [cn-shanghai]:
Default Output Format [json]: json (Only support json)
Default Language [zh|en] en:
Saving profile[sso] ...Done.


Configure Done!!!
..............888888888888888888888 ........=8888888888888888888D=..............
...........88888888888888888888888 ..........D8888888888888888888888I...........
.........,8888888888888ZI: ...........................=Z88D8888888888D..........
.........+88888888 ..........................................88888888D..........
.........+88888888 .......Welcome to use Alibaba Cloud.......O8888888D..........
.........+88888888 ............. ************* ..............O8888888D..........
.........+88888888 .... Command Line Interface(Reloaded) ....O8888888D..........
.........+88888888...........................................88888888D..........
..........D888888888888DO+. ..........................?ND888888888888D..........
...........O8888888888888888888888...........D8888888888888888888888=...........
............ .:D8888888888888888888.........78888888888888888888O ..............

步骤四:生成KubeConfig

  1. 使用以下命令,生成KubeConfig。关于命令详情,请参见get-kubeconfig

    ack-ram-tool credential-plugin get-kubeconfig --cluster-id $cluster_id --mode ram-authenticator-token
  2. 在本地或指定环境中配置上述命令返回的KubeConfig。更多信息,请参见Kubernetes官方文档

步骤五:配置RAM身份和RBAC权限的映射关系

ack-ram-authenticator组件安装完成后,默认会在集群中安装一个名为RAMIdentityMapping的CRD,该CRD用于配置RAM身份和K8s用户模型映射。集群权限管理员可以参考以下方式配置指定RAM用户或RAM角色与Kubernetes RBAC权限绑定的用户身份。

  1. 使用以下YAML内容,创建配置模板auth.yaml文件。

    cat >auth.yaml <<EOF
    ---
    apiVersion: ramauthenticator.k8s.alibabacloud/v1alpha1
    kind: RAMIdentityMapping
    metadata:
      name: tester
    spec:
      arn: '<ARN>'
      username: tester
      groups:
        - system:users    
    EOF
    • RAMIdentityMapping实例中的spec字段仅支持配置一个RAM ARN和usernamegroups的映射。如需不同的RAM身份映射,则需要创建多个RAMIdentityMapping实例。

    • 需要将 <ARN>替换为指定RAM用户或RAM角色的ARN。不同类型账号的ARN格式说明如下。

      账号类型

      ARN格式

      示例

      阿里云账号(主账号)

      acs:ram::<root_uid>:root

      其中 <root_uid>是阿里云账号的账号 ID。

      acs:ram::123456789012****:root

      RAM用户(子账号)

      acs:ram::<root_uid>:user/<user_name>

      其中 <root_uid>是阿里云账号的账号 ID,<user_name>是RAM用户的用户名。

      acs:ram::123456789012****:user/testuser

      RAM角色

      acs:ram::<root_uid>:role/<role_name>

      其中 <root_uid>是阿里云账号的账号 ID,<role_name>是RAM角色的名称。关于如何查看RAM角色的ARN信息,请参见查看RAM角色

      acs:ram::123456789012****:role/testrole

  2. 执行以下命令,创建RAMIdentityMapping实例。

    kubectl apply -f auth.yaml
  3. 配置目标集群的RBAC权限,根据需求创建自定义的RBAC角色和绑定。

    一个RBAC绑定的创建示例如下。

    cat >binding.yaml <<EOF
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: tester-clusterrolebinding
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cs:ops
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: User
      name: tester
    - apiGroup: rbac.authorization.k8s.io
      kind: User
      name: tester2
    EOF
    
    kubectl apply -f binding.yaml

步骤六:使用KubeConfig发起请求

通过步骤四生成的KubeConfig发起对APIServer的请求,并验证是否能够在权限范围内成功请求API Server

kubectl get ns

预期输出:

NAME              STATUS   AGE
arms-prom         Active   4h48m
default           Active   4h50m
kube-node-lease   Active   4h50m
kube-public       Active   4h50m
kube-system       Active   4h50m