美文网首页云计算
kubernetes 安全控制认证与授权

kubernetes 安全控制认证与授权

作者: 梅_梅 | 来源:发表于2018-07-02 14:53 被阅读5次

    1. 概述

    Kubernetes 对于访问 API 来说提供了两个步骤的安全措施:认证和授权。认证解决用户是谁的问题,授权解决用户能做什么的问题。通过合理的权限管理,能够保证系统的安全可靠。

    Kubernetes集群的所有操作基本上都是通过kube-apiserver这个组件进行的,它提供HTTP RESTful形式的API供集群内外客户端调用。需要注意的是:认证授权过程只存在HTTPS形式的API中。也就是说,如果客户端使用HTTP连接到kube-apiserver,那么是不会进行认证授权的。所以说,可以这么设置,在集群内部组件间通信使用HTTP,集群外部就使用HTTPS,这样既增加了安全性,也不至于太复杂。

    下图是 API 访问要经过的三个步骤,前面两个是认证和授权,第三个是 Admission Control,它也能在一定程度上提高安全性,不过更多是资源管理方面的作用。

    整体结构.png

    2. 整体结构

    安全控制认证与授权功能主要由AuthN和AuthZ功能完成。AuthN负责用户身份的认证,AuthZ负责根据用户身份对其行为做权限控制。

    2.1 AuthN 系统

    2.1.1 简介

    Kubernetes 的 AuthN 系统主要完成了以下工作:
    根据配置验证用户凭证,通常是 Bearer Token 或者 Basic Auth Password。
    解析用户信息,包括 Username,Groups,Uid 等。这些信息将用于之后的 Authz 系统授权。

    2.1.2 认证模式

    一般有以下几种用户身份认证模式:

    • X509 Client Certs —— Client Certs 模式
      通过传入 --client-ca-file 到 Apiserver 开启。其中证书的 /CN (common name)表示用户名,/O (organization)表示 Groups。
      Client Cert 模式通常用于某些受信任的组件访问 Apiserver,如 Kubernetes 各个组件访问 Apiserver。

    • Static Token File —— 静态 Token 文件模式
      通过传入 --token-auth-file 到 Apiserver 开启。以下是其中一条记录的模版。HTTP 请求在 Header 中传入 Authorization: Bearer Token 来认证。


      image.png
    • Static Password File —— 静态 Password 文件模式
      通过传入 --basic-auth-file 到 Apiserver 开启。以下是其中一条记录的模版。HTTP 请求在 Header 中传入 Authorization:Basicbase64(user:password)来认证。


      image.png
    • Service Account Tokens
      Service Account Token 主要是用来给 Pod 提供访问 Apiserver 的权限。当 Pod 通过 Service Account 访问 Apiserver 时,用户名为 system:serviceaccount: (NAMESPACE):(SERVICEACCOUNT),并且属于system: serviceaccounts和system: serviceaccounts:(NAMESPACE) 这两个 Group。当一个 Pod 使用 InClusterConfig 创建 Client 访问 Apiserver 时,Client 会自动载入 Service Account 的 Token。

    • OIDC Token
      OIDC 是除了 WebHook 外 Kubernetes 提供的唯一一个动态的 AuthN 方案。相比较于上面几种方案的小打小闹,OIDC 提供了标准的 AuthN 流程,真正能够作为 Kubernetes 系统用户认证的企业级解决方案。

    2.1.3 OpenID Connect Tokens 认证

    OpenID Connect 是一些由OAuth2提供商支持的OAuth2,特别是Azure Active Directory,Salesforce和Google。OAuth2的协议的主要扩展是增加一个额外字段,返回了一个叫ID token的access token。这个token是被服务器签名的JSON Web Token (JWT) ,具有众所周知的字段,比如用户的email。

    为了识别用户,验证使用来自OAuth2 token响应的id_token (而不是 access_token)作为bearer token。token如何包含在请求中可以参考下图:


    认证流程

    使用OpenID认证,API Server需要配置

    • --oidc-issuer-url,如https://accounts.google.com
    • --oidc-client-id,如kubernetes
    • --oidc-username-claim,如sub
    • --oidc-groups-claim,如groups
    • --oidc-ca-file,如/etc/kubernetes/ssl/kc-ca.pem

    2.1.4 Webhook Token 认证

    Webhook Token 认证方式可以让用户使用自己的认证方式,用户只需要按照约定的请求格式和应答格式提供 HTTPS 服务,当用户把 Bearer Token 放到请求的头部,kubernetes 会把 token 发送给事先配置的地址进行认证,如果认证结果成功,则认为请求用户合法。 这种方式下有三个参数可以配置:

    • –authentication-token-webhook-config-file :kubeconfig 文件说明如果访问认证服务器
    • –authentication-token-webhook-cache-ttl :认证结果要缓存多久,默认是两分钟
    • --runtime-config=authentication.k8s.io/v1beta1=true。

    Webhook 的配置文件具体如下:


    webhook请求端配置.png

    Webhook Service 需要实现 TokenReview 的接口:


    webhook服务端配置.png

    2.1.5 认证代理

    API Server需要配置

    --requestheader-username-headers=X-Remote-User
    --requestheader-group-headers=X-Remote-Group
    --requestheader-extra-headers-prefix=X-Remote-Extra-
    # 为了防止头部欺骗,证书是必选项
    --requestheader-client-ca-file
    # 设置允许的CN列表。可选。
    --requestheader-allowed-names
    

    2.1.6 Keystone Password 认证

    Keystone 是 openstack 提供的认证和授权组件,这个方法对于已经使用 openstack 来搭建 Iaas 平台的公司比较适用,直接使用 keystone 可以保证 Iaas 和 Caas 平台保持一致的用户体系。

    需要API Server在启动时指定--experimental-keystone-url=<AuthURL>,而https时还需要设置--experimental-keystone-ca-file=SOMEFILE。

    2.1.7 匿名请求

    如果请求没有通过以上任何方式的认证,正常情况下应该是直接返回 401 错误。但是 kubernetes 还提供另外一种选择,给没有通过认证的请求一个特殊的用户名 system:anonymous 和组名 system:unauthenticated 。

    这样的话,可以跟下面要讲的授权结合起来,为匿名请求设置一些特殊的权限,比如只能读取当前 namespace 的 pod 信息,方便用户访问。

    如果使用AlwaysAllow以外的认证模式,则匿名请求默认开启,但可用--anonymous-auth=false禁止匿名请求。

    2.2 AuthZ

    2.2.1 简介

    Kubernetes 的 AuthZ 系统主要完成了以下几件事情:
    解析 HTTP 请求,获取请求的各种属性
    根据属性和 AuthN 获取的用户信息,依次匹配 AuthZ 规则,如果成功则通过,如果全部失败则返回禁止访问。
    不同于 AuthN 方案,AuthZ 方案在 Kubernetes 中和其 API 风格有相当大的关联。由于严格遵循 RESTful 标准定义 API,Kubernetes 在提取 HTTP 请求属性和定义 AuthZ 规则等方面有了极大的便利。
    下面是 Kubernetes 提供的两种 AuthZ 方案 —— ABAC 和 RBAC。

    2.2.2 ABAC

    ABAC 全称 Attribute Based Access Control(基于属性的访问控制)。通过 --authorization-mode=ABAC 开启,并且通过 --authorization-policy-file 指定策略文件。
    以下是 ABAC 的一条记录的例子:


    image.png

    可以发现 ABAC 定义的字段基本上就是来自于上述的 Attributes 接口能够获取的信息。另外值得一提的是 Kubernetes 中的 ABAC 没有动态方案,修改策略文件后必须重启 Apiserver。

    2.2.3 RBAC

    RBAC 全称 Role Based Access Control(基于角色的访问控制), 通过 --authorization-mode=RBAC 开启。

    目前和 RBAC 相关的 Resource 有以下 4 种:

    Role
    RoleBinding
    ClusterRole
    ClusterRoleBinding
    
    image.png

    Role 和 RoleBinding 是 NameSpace 下的资源,而 ClusterRole 和 ClusterRoleBinding 是系统级的资源。1.8 后 RBAC 所属的资源已经从 v1beta1 升级到 v1。

    2.2.3.1 Role

    Role 的例子如下:


    image.png

    2.2.3.2 ClusterRole

    ClusterRole 的例子如下:


    image.png

    ClusterRole 可以用来定义全局的 Resource。当使用 ClusterRoleBinding 绑定时,表示能访问所有 NameSpace 下的资源(如上述的 secrets),当使用 RoleBinding 绑定时,表示只能访问 RoleBinding 所属的 NameSpace 下的资源。

    2.2.3.3 RoleBinding

    RoleBinding 的例子如下:


    image.png

    RoleBinding 负责绑定 Subjects 和某一个 Role 或者 ClusterRole。

    2.2.3.4 ClusterRoleBinding

    ClusterRoleBinding 的例子如下:


    image.png

    ClusterRoleBinding 能够绑定 Subjects 和 ClusterRole。

    2.2.3.5 Subjects

    Subjects 分为以下 3 种类型,Subjects 来自于 AuthN 的结果。

    User
    Group
    ServiceAccount
    

    2.2.4 Authz 的Webhook配置

    AuthZ 系统也可以通过 Webhook 实现。不过比起 AuthN,AuthZ 系统通常没有必要使用 Webhook。
    通过传入

    --authorization-webhook-config-file 
    

    开启,另外还要添加

    --runtime-config=authorization.k8s.io/v1beta1=true。
    

    Webhook 的配置文件如下:


    image.png

    Webhook Service 需要实现 SubjectAccessReview 的接口


    image.png

    3. 参考文章

    link1
    link2

    相关文章

      网友评论

        本文标题:kubernetes 安全控制认证与授权

        本文链接:https://www.haomeiwen.com/subject/fdxluftx.html