Kubernetes API 访问控制一:认证概述

2019-06-10 0 By admin

使用kubectl、客户端库方式对API Service的访问,Kubernetes的普通账户和服务帐户都可以实现授权访问REST API。
API的请求会经过多个阶段的访问控制才会被接受处理,其中包含认证、授权以及准入控制(Admission Control)等。

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

一、认证说明

开启TLS时,所有的请求首先需要认证。
1、Kubernetes支持多种认证机制,并支持同时开启多个认证插件(只要有一个认证通过即可)。
2、如果认证成功,则用户的username会传入授权模块做进一步授权验证;对于认证失败的请求则返回HTTP 401。
3、当TLS建立时,HTTP请求会进行身份认证步骤;集群管理器将API-Server配置为运行一个或多个认证器模块。
4、认证模块包含客户端证书,密码、Plain Tokens、Bootstrap Tokens、JWT Tokens(used for service accounts)。
5、我们可以指定多个认证模块,每个认证模块都会按顺序进行,直到其中一个成功。

二、Kubernetes 账户

所有Kubernetes集群有两类用户:由Kubernetes管理的Service Accounts (服务账户)和(Users Accounts) 普通账户。
1、Service Accounts是由Kubernetes API管理的帐户。它们被绑定到特定的命名空间,并由API-Server自动创建或通过API调用手动创建。Service Accounts与存储为Secrets的一组证书相关联,这些凭据被挂载到pod中,以便集群进程与Kubernetes API通信。
2、普通账户是假定被外部或独立服务管理的,由管理员分配keys,用户像使用Keystone或google账号一样,被存储在包含usernames和passwords的list的文件里。需要注意:在Kubernetes中不能通过API调用将普通用户添加到集群中。

三、验证策略

Kubernetes用户可以使用client certificates、bearer tokens、authenticating proxy、HTTP basic auth等认证插件来验证API请求。
比如HTTPS请求到达API Server,插件会尝试将以下属性与请求关联:

  1. UserName:普通用户的字符串。比如“kube-admin”或“xxxx@kubernetes.org.cn”。
  2. UID:普通用户的字符串,比UserName更具有唯一性。
  3. Groups:一组字符串,将常用的user分组的组合字符串。
  4. Extra fields:将一些有用的字符串信息映射成的列表。

所有values值对于认证系统都是不透明的,只有当授权解释后才有意义。
可以同时启用多个认证方法。最少使用两种:

  1. 为Service Accounts使用service account tokens方法。
  2. 使用另外一种用户认证方法。

system:authenticated组被包括在所有已认证用户的组列表中。

认证方式一、X509 客户证书

使用API Server启动时配置–client-ca-file = SOMEFILE选项来启用客户端证书认证。
引用的文件必须包含,提交给API Server的客户端证书的证书颁发机构。如果客户端提交的证书通过,通用名称(common name)将被用作请求的用户名。

例如,使用openssl命令管理工具生成证书签名请求:
openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"
将为“jbeda”用户名创建一个CSR,所属组为”app1”和“app2”的签名请求。

认证方式二、Static Token File

启动静态Token文件需要API-Server启动时配置--token-auth-file=SOMEFILE选项;目前,tokens状态可以持续存在,需要重新启用 API-Server服务,token last才会重启。
token文件是至少包含3列的csv格式文件: token, user name, user uid,第四列为可选group 名项。注意:如果有多个group名,列必须用””双引号包含其中,例如
token,user,uid,"group1,group2,group3"

认证方式三、Putting a Bearer Token in a Request

当http客户端使用 bearer token 认证时,API-Server需要一个值为Bearer THETOKEN的授权头。bearer token必须可以放在HTTP请求头中且值不需要转码和引用的一个字符串。例如:bearer token :31ada4fd-adec-460c-809a-9e56ceb75269,会在HTTP header中按下面的方式呈现:
Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

认证方式四、Bootstrap Tokens

功能目前为Alpha级别
1、Kubernetes包括一个dynamically-managed的Bearer token类型,称为Bootstrap Token。
2、这些token作为Secret存储在kube-system namespace中,可以动态管理和创建。Controller Manager包含一个TokenCleaner Controller,如果到期时可以删除Bootstrap Tokens Controller。
3、Tokens的形式是[a-z0-9]{6}.[a-z0-9]{16}。第一个组件是Token ID,第二个组件是Token Secret。可以在HTTP header中指定Token,如下所示:
Authorization: Bearer 781292.db7bc3a58fc5f07e
4、如何使用Kubeadm来管理Token,以及想了解更多BootstrapToken文档,请参考Bootstrap Token

认证方式五、Static Password File

Basic Authentication是通过在API Server启动是配置-Basic-authfile=file选项实现,Basic认证凭证一直有效,并且如果没有重新启动API Server,密码将无法更改。
Basic Authentication文件csv也是格式文件,且必须包含:password, user, uid。在Kubernetes 1.6+版本中,可以指定一个可选的第四列,使用逗号来分隔group名,如果有多个组,必须使用双引号(“)。参考以下示例:
password,user,uid,"group1,group2,group3"
当从http客户端使用Basic Authentication时,API Server需要在请求头加入Basic BASE64ENCODED(USER:PASSWORD)。

其他认证方式

1、OpenID Connect Tokens:由一些云提供商支持的OAuth2认证机制,特别是Azure Active Directory,Salesforce和Google。OAuth2协议的主要扩展是增加一个额外字段,返回ID Token的access token。这个token被服务器签名的JSON Web Token (JWT) ,常见的字段如user’s email。
2、Webhook Token Authentication:Webhook authentication is a hook for verifying bearer tokens。
3、Keystone Password:Keystone认证通过–experimental-keystone-url= 在启动期间将选项传递给API服务器来启用。