k8s实践(6)--Kubernetes安全：API Server访问控制

桃扇骨 2021-12-17 05:07 1035阅读 0赞

# Kubernetes安全 #

安全永远是一个重大的话题，特别是云计算平台，更需要设计出一套完善的安全方案，以应对复杂的场景。 Kubernetes主要使用Docker作为应用承载环境，Kubernetes首先设计出一套API和敏感信息处理方案，当然也基于Docker提供容器安全控制。以下是Kubernetes的安全设计原则：

1. 保证容器与其运行的宿主机之间有明确的隔离  
2. 限制容器对基础设施或者其它容器造成不良影响的能力  
3. 最小特权原则——限定每个组件只被赋予了执行操作所必需的最小特权，由此确保可能产生的损失达到最小  
4. 允许系统用户明确区别于管理员  
5. 允许赋予管理权限给用户  
6. 允许应用能够从公开数据中提取敏感信息（keys, certs, passwords）

[http://docs.kubernetes.org.cn/27.html][http_docs.kubernetes.org.cn_27.html]

# 一、**Kubernetes API Server访问控制** #

--------------------

Kubernetes API Server通过一个名为kube-apiserver的进程提供服务，该进程运行在Master节点上。在默认情况下，kube-apiserver进程在本机的8080端口（--insecure-port）提供REST服务。我们可以同时启动HTTPS安全端口（--secure=6443）来启动安全机制，加强REST API访问的安全性。

**1、REST调用**

通常我们使用kubectl来与Kubernetes API Server交互，它们之间的接口是REST调用。也可以使用curl命令行工具进行快速验证。

**2、编程的方式调用**

另外是通过编程的方式调用Kubernetes API Server 具体又细分为以下两种场景：

1.     运行在POD里的进程调用Server API. Pod中的进程如何指定API Server的访问地址呢?答案很简单，因为Kubernetes API Server本身也是一个Service,它的名字是“kubernetes”,IP地址是ClusterIP地址池里面的第一个地址。服务端口是HTTPS端口443.

2.       开发基于Kubernetes的管理平台，比如调用Kubernetes API来完成Pod,Service,RC等资源对象的图形化创建和管理界面。可采用社区中相关的Client Library.

正常情况下，为了确保Kubernetes集群的安全，API Server都会对客户端进行身份认证，认证失败则无法调用API。此外，Pod中访问Kubernetes API Server服务的时候，是以Service方式访问服务名为kubernetes的这个服务，而kubernetes服务又只在HTTPS 443上提供服务，那么如何进行身份认证呢？ **答案是 Service Account Token.**

API的请求会经过多个阶段的访问控制才会被接受处理，其中包**含认证、授权以及准入控制（Admission Control）等**。如下图所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70][]

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

Kubernetes集群中所有资源的访问和变更都是通过Kubernetes API Server的REST API来实现的，所以集群安全的关键点在于识别认证客户端身份（Authentication）以及访问权限的授权（Authorization）。

>  *  认证Authentication  
>     支持Client certificate authentication 、Token authentication 、Basic authentication集中方式。
>  *  授权Authorization  
>     在Authentication的基础上，Authorization可以对HTTP请求设置AlwaysDeny、AlwaysAllow、ABAC三种模式模式，其中ABAC可以设置不同用户的访问权限。

# 二、API Server**的** 认证Authentication #

--------------------

当TLS建立时，HTTP请求会进行身份认证步骤，如图中步骤1，集群管理器将apiserver配置为运行一个或多个认证器模块。

认证模块包含客户端证书，密码、Plain Tokens、Bootstrap Tokens、JWT Tokens（used for service accounts）。

我们可以指定多个认证模块，每个认证模块都会按顺序进行，直到其中一个成功。（在GCE上，客户端证书、密码、Plain Tokens和JWT Tokens都会启用。）

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 1][]

API Server认证 Authentication提供管理三种级别的客户端身份认证方式：

1.  最严格的HTTPS证书认证：基于CA根证书签名的双向数字证书认证方式；
2.  HTTP Token认证：通过一个Token来识别合法用户；
3.  HTTP Base认证：通过用户名+密码的方式认证；

## 1、HTTPS证书认证： ##

1.  HTTPS通信双方的务器端向CA机构申请证书，CA机构是可信的第三方机构，它可以是一个公认的权威的企业，也可以是企业自身。企业内部系统一般都使用企业自身的认证系统。CA机构下发根证书、服务端证书及私钥给申请者；
2.  HTTPS通信双方的客户端向CA机构申请证书，CA机构下发根证书、客户端证书及私钥个申请者；
3.  客户端向服务器端发起请求，服务端下发服务端证书给客户端。客户端接收到证书后，通过私钥解密证书，并利用服务器端证书中的公钥认证证书信息比较证书里的消息，例如域名和公钥与服务器刚刚发送的相关消息是否一致，如果一致，则客户端认为这个服务器的合法身份；
4.  客户端发送客户端证书给服务器端，服务端接收到证书后，通过私钥解密证书，获得客户端的证书公钥，并用该公钥认证证书信息，确认客户端是否合法；
5.  客户端通过随机秘钥加密信息，并发送加密后的信息给服务端。服务器端和客户端协商好加密方案后，客户端会产生一个随机的秘钥，客户端通过协商好的加密方案，加密该随机秘钥，并发送该随机秘钥到服务器端。服务器端接收这个秘钥后，双方通信的所有内容都都通过该随机秘钥加密；

CA认证流程图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ndWlzdS5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70][]

上述是双向SSL协议的具体通信过程，这种情况要求服务器和用户双方都有证书。单向认证SSL协议不需要客户拥有CA证书，对应上面的步骤，只需将服务器端验证客户端证书的过程去掉，以及在协商对称密码方案和对称通话秘钥时，服务器端发送给客户端的是没有加过密的（这并不影响SSL过程的安全性）密码方案。

## 2、HTTP Token原理： ##

HTTP Token的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串——Token来表明客户身份的一种方式。在通常情况下，Token是一个复杂的字符串，比如我们用私钥签名一个字符串的数据就可以作为一个Token，此外每个Token对应一个用户名，存储在API Server能访问的一个文件中。当客户端发起API调用请求时，需要在HTTP Header里放入Token，这样一来API Server就能够识别合法用户和非法用户了。

### 3、HTTP Base： ###

常见的客户端账号登录程序，这种认证方式是把“用户名+冒号+密码”用BASE64算法进行编码后的字符串放在HTTP REQUEST中的Header Authorization域里发送给服务端，服务端收到后进行解码，获取用户名及密码，然后进行用户身份的鉴权过程。

现在使用Basic authentication + ABAC model设置API server，  
首先配置Basic authentication,设置用户密码,格式为每行password, user name, user id，  
basic\_auth.csv：

admin_passwd,admin,admin
    test_passwd,test,test

然后配置ABAC访问策略, 设置admin具有任何权限，test用户只能访问pods，  
policy\_file.jsonl:

{"user":"admin"}
    {"user":"test", "resource": "pods", "readonly": true}

> 访问策略配置详情参考：  
> [https://github.com/kubernetes/ ... rithm][https_github.com_kubernetes_ ... rithm]

然后启动API Server：

$kube-apiserver
    ...
    --basic-auth-file=basic_auth.csv \
    --authorization-mode=ABAC --authorization-policy-file=policy_file.jsonl

访问API，可以看到test用户无法访问Pod之外的资源：

$ curl --basic -u admin:admin_passwd https://192.168.3.146:6443/api/v1/pods -k
    [
    ...
    ]
    
    $ curl --basic -u test:test_passwd https://192.168.3.146:6443/api/v1/pods -k
    [
    ...
    ]
    
    $ curl --basic -u test:test_passwd https://192.168.3.146:6443/api/v1/nodes -k
    Forbidden: "/api/v1/nodes"

# #

# 三、API Server授权Authorization #

--------------------

认证之后的请求是[授权模块:][Link 1]如图中步骤2

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 2][]

对合法用户进行授权（Authorization）并且随后在用户访问时进行鉴权，是权限与安全系统的重要一环。授权就是授予不同用户不同访问权限：

**API Server 目前支持以下几种授权策略 (通过 API Server 的启动参数 `--authorization-mode` 设置)**

*  **AlwaysDeny：标识拒绝所有的请求，一般用于测试**
 *  **AlwaysAllow：允许接受所有请求，如果集群不需要授权流程，则可以采用该策略**
 *  **ABAC：**（Attribute-Base Access Control）**基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制，淘汰**
 *  **Webbook：通过调用外部 REST 服务对用户进行授权**
 *  **RBAC：基于角色的访问控制，现行默认规则，常用**

## **ABAC**授权**模式：** ##

为了简化授权的复杂度，对于ABAC模式的授权策略，Kubernetes仅有下面四个基本属性：

1.  用户名（代表一个已经被认证的用户的字符型用户名）
2.  是否是只读请求（REST的GET操作是只读的）
3.  被访问的是哪一类资源，例如Pod资源/api/v1/namespaces/default/pods
4.  被访问对象所属的Namespace

当API Server启用ABAC模式时，需要指定授权文件的路径和名字（--authorization\_policy\_file=SOME\_FILENAME）,授权策略文件里的每一行都是一个Map类型的JOSN对象，被称为访问策略对象，我们可以通过设置“访问策略对象”中的如下属性来确定具体的授权行为：

*  user：字符串类型，来源于Token文件或基本认证文件中的用户名字段的值；
 *  readonly：true时表示该策略允许GET请求通过；
 *  resource：来自于URL的资源，例如“Pod”；
 *  namespace：表明该策略允许访问某个namespace的资源；

eg：

*  \{"user":"alice"\}
 *  \{"user":"kubelet","resource":"Pods","readonly":true\}
 *  \{"user":"kubelet","resource":"events"\}
 *  \{"user":"bob","resource":"Pods","readonly":true,"ns":"myNamespace"\}

## RBAC 授权模式 ##

RBAC 基于角色的访问控制，在 kubernetes1.5 中引入，现行版本成为默认标准。相对其他访问控制方式，拥有以下优势：

*  对集群中的资源和非资源拥有完整的覆盖
 *  整个 RBAC 完全由几个API 对象完成。同其他 API 对象一样，可以用 kubectl 或 API 进行操作。
 *  可以在运行时进行调整，无需重启 API Server。

### RBAC 的 API 资源对象说明 ###

RBAC 引入了 4个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding、4种对象类型均可以通过 kubectl 与 API 操作。

Role：普通角色 | ClusterRole：集群角色

Rolebinding：普通角色绑定 ClusterRoleBinding：集群角色绑定

![在这里插入图片描述][20200624132826141.png]

# 三、准入控制Admission Controllers #

--------------------

在认证和授权之外，Admission Controller也可以对Kubernetes API Server的访问控制，任何请求在访问API Server时需要经过一系列的验证，任何一环拒绝了请求，则会返回错误。  
实际上Admission Controller是作为Kubernetes API Serve的一部分，并以插件代码的形式存在，在API Server启动的时候，可以配置需要哪些Admission Controller，以及它们的顺序，如：

--admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota
    
    Admission Controller支持的插件如下：

>  *  AlwaysAdmit：允许所有请求；
>  *  AlwaysPullmages：在启动容器之前总去下载镜像，相当于在每个容器的配置项imagePullPolicy=Always
>  *  AlwaysDeny：禁止所有请求，一般用于测试；
>  *  DenyExecOnPrivileged：它会拦截所有想在Privileged Container上执行命令的请求，如果你的集群支持Privileged Container，你又希望限制用户在这些Privileged Container上执行命令，强烈推荐你使用它；
>  *  Service Account：这个plug-in将ServiceAccount实现了自动化，默认启用，如果你想使用ServiceAccount对象，那么强烈你推荐使用它；
>  *  SecurityContextDeny：这个插件将使用SecurityContext的Pod中的定义全部失效。SecurityContext在Container中定义了操作系统级别的安全设定（uid，gid，capabilityes，SELinux等）
>  *  ResourceQuota：用于配额管理目的，作用于namespace上，它会观察所有请求，确保在namespace上的配额不会超标。推荐在Admission Control参数列表中这个插件排最后一个；
>  *  LimitRanger：用于配额管理，作用于Pod与Container，确保Pod与Container上的配额不会超标；
>  *  NamespaceExists（已过时）：对所有请求校验namespace是否已存在，如果不存在则拒绝请求，已合并至NamespaceLifecycle。
>  *   NamespaceAutoProvision（已过时）：对所有请求校验namespace，如果不存在则自动创建该namespace，推荐使用NamespaceLifecycle。
>  *  NamespaceLifecycle：如果尝试在一个不存在的namespace中创建资源对象，则该创建请求将被拒绝。当删除一个namespace时，系统将会删除该namespace中所有对象，保存Pod，Service等。

在API Server上设置--admission-control参数，即可定制我们需要的准入控制链，如果启用多种准入控制选项，则建议的设置如下：

*  \--admission-control=NamespaceLifecycle，LimitRanger，SecurityContextDeny，ServiceAccount，ResourceQuota

下面着重介绍三个准入控制器：

### SecurityContextDeny ###

Security Context时运用于容器的操作系统安全设置（uid、gid、capabilities、SELinux role等），Admission Control的SecurityContextDeny插件的作用是，禁止创建设置了Security Context的Pod，例如包含以下配置项的Pod：

*  spec.containers.securityContext.seLinuxOptions
 *  spec.containers.securityContext.runAsUser

### ResourceQuota ###

ResourceQuota不仅能够限制某个Namespace中创建资源的数量，而且能够限制某个namespace中被Pod所请求的资源总量。该准入控制器和资源对象ResourceQuota一起实现了资源的配额管理；

### LimitRanger ###

准入控制器LimitRanger的作用类似于上面的ResourceQuota控制器，这对Namespace资源的每个个体的资源配额。该插件和资源对象LimitRange一起实现资源限制管理。

# 四、ServiceAccount #

--------------------

## 4.1、什么是service account？ ##

什么是service account? 顾名思义，相对于user account（比如：kubectl访问APIServer时用的就是user account），service account就是Pod中的Process用于访问Kubernetes API的account，它为Pod中的Process提供了一种身份标识。相比于user account的全局性权限，service account更适合一些轻量级的task，更聚焦于授权给某些特定Pod中的Process所使用。

Service Account概念的引入是基于这样的使用场景：运行在pod里的进程需要调用Kubernetes API以及非Kubernetes API的其它服务（如image repository/被mount到pod上的NFS volumes中的file等）。我们使用Service Account来为pod提供id。  
Service Account和User account可能会带来一定程度上的混淆，User account可以认为是与Kubernetes交互的个体，通常可以认为是human, 目前并不作为一个代码中的类型单独出现，比如第一节中配置的用户，它们的区别如下。

**Kubernetes有User Account和Service Account两套独立的账号系统：**  
1.User Account是给人用的，Service Account 是给Pod 里的进程使用的，面向的对象不同。  
2.User Account是全局性的，即跨namespace使用。 Service Account 是属于某个具体的Namespace，即仅在所属的namespace下使用。  
3.User Account是与后端的用户数据库同步的。创建一个新的user account通常需要较高的特权并且需要经过比较复杂的business process（即对于集群的访问权限的创建），而service account则不然。

如果kubernetes开启了ServiceAccount（–admission\_control=…,ServiceAccount,… ）那么会在每个namespace下面都会创建一个默认的default的ServiceAccount。即service account作为一种resource存在于Kubernetes cluster中，我们可以通过kubectl获取

**1、当前cluster中的service acount列表：**

kubectl get serviceaccount --all-namespaces

![20190708173208139.png][]

**2、service account的详细信息**

我们查看一下kube-system namespace下名为”default”的service account的详细信息：

kubectl describe serviceaccount/default -n kube-system

![20190708173301660.png][]

我们看到service account并不复杂，只是关联了一个secret资源作为token，该token也叫service-account-token，该token才是真正在API Server验证(authentication)环节起作用的。

**3、查看系统的secret 的token列表：**

\[root@k8s-master k8s-kube-scheduler\]\# kubectl get secret  -n kube-system  
NAME                  TYPE                                  DATA      AGE  
coredns-token-cdn9x   kubernetes.io/service-account-token   2         1h  
default-token-lht2v   kubernetes.io/service-account-token   2         1h

\[root@k8s-master k8s-kube-scheduler\]\# kubectl get secret  
NAME                  TYPE                                  DATA      AGE  
db-user-pass          Opaque                                0         18d  
default-token-k7jfg   kubernetes.io/service-account-token   2         1h  
registry-key-secret   kubernetes.io/dockerconfigjson        1         18d

**4、查看系统的secret  详细：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ndWlzdS5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 1][]

我们看到这个类型为service-account-token的secret资源包含的数据有三部分：namespace和token。

>  *  namespace：这个就是Secret所在namespace的值的base64编码：\# echo -n “kube-system”|base64 => “a3ViZS1zeXN0ZW0=”
>  *  token：这是一段用API Server私钥签发(sign)的bearer tokens的base64编码，在API Server authenticating环节，它将派上用场。

**5、获取原始token：**

获取对应sa的secret从中获取token。并进行base64解码。

kubectl get secret default-token-lht2v  -n kube-system  -o jsonpath=\{".data.token"\} | base64 -d

![20190712153855935.png][]

**6、使用token 请求apiserver：**

获取对应sa的secret从中获取token。并进行base64解码。

curl -k -H 'Authorization: Bearer token' https://111.111.111.111:6443

curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkZWZhdWx0LXRva2VuLWxodDJ2Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImRlZmF1bHQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI2MDg2MmMxMS04ZTgzLTExZTktYjY2YS0wMDUwNTZiMTIzYjEiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06ZGVmYXVsdCJ9.SCn9sq6i4t4fLPW7kuTe3VfoQUO_iXY6M6vKjR40wqPDFJll5-F9n92iY0DqpBAs-vTWeZDmUuevjSJYeRzJlQmMzw5tZj4CIXZ_LHdiiW4kwmAWiproDE-nAXjF4vKHKkWsGLwpeHOQ2F2pCMIibQkk60ZudlJb_qszoTQvt2NgkUmh-DxwEy6uj6pc-j14s--qNSrValkPIoZV7u2zmPEXzC9sFjADKnqUJ4GCtSS3VIVfqUZvSecWB95f-VIBnQwKJAcOvN7Nspk8Vjp0zW3CAWTmiPm_1AHqIuM0daxl6JLpUBZvfQnCAm_s928DbSyyNrTR9V3ra0M3pHcPdw' https://192.168.10.50:6443/api
    {
      "kind": "APIVersions",
      "versions": [
        "v1"
      ],
      "serverAddressByClientCIDRs": [
        {
          "clientCIDR": "0.0.0.0/0",
          "serverAddress": "192.168.10.50:6443"
        },
        {
          "clientCIDR": "192.168.0.0/16",
          "serverAddress": "192.168.0.1:443"
        }
      ]
    }

## 4.2、默认的service account ##

**1、开启ServiceAccount**

如果K8S apiserver的启动参数中添加--admission\_control=ServiceAccount

apiserver在启动的时候会自己创建一个key和crt（见/var/run/kubernetes/apiserver.crt和apiserver.key）

然后在启动./kube-controller-manager 时添加flag：

\--service\_account\_private\_key\_file=/var/run/kubernetes/apiserver.key

那么k8s会在每个namespace下面都会创建一个默认的service account资源,并命名为”default”：

kubectl get serviceaccount --all-namespaces

![2019070818201783.png][]

如果Pod中没有显式指定spec.serviceAccount字段值，那么Kubernetes会将该namespace下的”default” service account自动mount到在这个namespace中创建的Pod里。

**2、查看pod的service account资源,**

当用户在namespace下创建pod时会默认使用默认的service account资源,。

我们以namespace “default”为例，我们查看一下其中的一个Pod的信息：

kubectl describe pod/webapp-nl754

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ndWlzdS5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 2][]

可以看到，secret：default-token-k7jfg就是我们default这个serviceaccount下的secret。它被装载到容器内部`mountPath: /var/run/secrets/kubernetes.io/serviceaccount`目录中

Pod创建成功后，可以查询Pod的容器挂载/var/run/secrets/kubernetes.io/serviceaccount，实际上这个目录是ServiceAccount的Secret，里面包含了一个token,应用通过使用这个token便可以去访问Kubernetes API：

\# kubectl exec  webapp-62xws ls /var/run/secrets/kubernetes.io/serviceaccount  
namespace  
token

**3、查看pod的token的内容：**

\# kubectl exec  webapp-62xws cat /var/run/secrets/kubernetes.io/serviceaccount/token

也可以深入容器内部，查看mount的serviceaccount路径下的结构：

# docker exec 3d11ee06e0f8 ls  /var/run/secrets/kubernetes.io/serviceaccount
    namespace
    token

这token文件与上面提到的service account的token中的数据是一一对应的。

## 4.3、API Server的service account token原理 ##

**1、开启ServiceAccount**

kubernetes  apiserver开启了ServiceAccount（–admission\_control=…,ServiceAccount,… ）那么会在每个namespace下面都会创建一个默认的default的ServiceAccount。即service account作为一种resource存在于Kubernetes cluster中。

每个ServiceAccount下面都会拥有一个加密过的secret作为Token. 该token也叫service-account-token

**2、apiserver启动的时候，每个ServiceAccount自动生成token。**

该token是APIServer在创建service account时用API server启动参数：–service-account-key-file的值签署(sign)生成的。如果–service-account-key-file未传入任何值，那么将默认使用–tls-private-key-file的值，即API Server的私钥（server.key）。

**3、pod发起请求http请求携带signed bearer token**

在HTTP Header中传递了一个Token字符串，这类似于之前提到的HTTP Token认证方式

类似这样：curl -k -H 'Authorization: Bearer token'  https://192.168.10.50:6443/api

即pod的Token是在指定路径下的一个文件（/run/secrets/kubernetes.io/serviceaccount/token），这token是动态生成的，确切的说，是由KubernetesController进程用API Server的私钥（--service-account-private-key-file指定的私钥）签名生成的一个JWT Secret。

**4、apiserver验证token**

**apiserver**的authenticating环节支持多种身份校验方式：client cert、bearer token、static password auth等。

**apiserver**发现client发起的request使用的是service account token的方式，**apiserver**就会自动采用signed bearer token方式进行身份校验。而request就会使用携带的service account token参与验证。

**apiserver**收到这个Token以后，采用自己的私钥（实际是使用参数service-account-key-file）指定的私钥，如果此参数没有设置，则默认采用tls-private-key-file指定的参数，即自己的私钥，对token进行合法性验证。

**5、通过authenticating后**

API Server将根据Pod username所在的group：system:serviceaccounts和system:serviceaccounts:(NAMESPACE)的权限对其进行[authority][] 和[admission control][]两个环节的处理。在这两个环节中，cluster管理员可以对service account的权限进行细化设置。

# 五、Secrets #

--------------------

Kubernetes提供了Secret来处理敏感信息，目前Secret的类型有3种：

*  Opaque(default): 任意字符串
 *  kubernetes.io/service-account-token: 作用于ServiceAccount
 *  kubernetes.io/dockercfg: 作用于Docker registry

开发者可以任意定义Secret的格式和内容，现在创建一个假设Opaque Secret，比如应用要使用账号密码：

username: value-1
    password: value-2

首先创建Secret，  
secret.yaml:

apiVersion: v1
    kind: Secret
    metadata:
    name: mysecret
    type: Opaque
    data:
    password: dmFsdWUtMg0K
    username: dmFsdWUtMQ0K

注意：其中password和username的值是通过base64 加密。

$ kubectl create -f secret.yaml
    $ kubectl describe secrets mysecret
    Name:       mysecret
    Namespace:  default
    Labels:     <none>
    Annotations:    <none>
    Type:   Opaque

Data

password:   9 bytes username:   9 bytes  
  
现在创建一个Pod使用该Secret  
red-pod.json：

{
    "apiVersion": "v1",
    "kind": "Pod",
    "metadata": {
    "name": "mypod"
    },
    "spec": {
    "containers": [{
      "name": "mypod",
      "image": "redis",
      "volumeMounts": [{
        "name": "foo",
        "mountPath": "/etc/foo",
        "readOnly": true
      }]
    }],
    "volumes": [{
      "name": "foo",
      "secret": {
        "secretName": "mysecret"
      }
    }]
    }
    }

这里将Secret作为一个Volume挂载到Po中容器的/etc/foo下，实际上Secret中的值都会以文件生成到/etc/foo下(文件名是key，文件内容是value)，待Pod运行后查看：

$ kubectl exec mypod ls /etc/foo
    password
    username
    $ kubectl exec mypod cat /etc/foo/password
    value-2
    $ kubectl exec mypod cat /etc/foo/username
    value-1

> Secret用于 Docker Registry的安全认证,参考：  
> [https://github.com/GoogleCloud ... a-pod][https_github.com_GoogleCloud ... a-pod]

## ##

# 六、Security context #

--------------------

Security context是用以对容器进行限制，使得不同的运行容器之前能够实现较为明晰的隔离，以及降低其影响宿主机和其它容器的可能性。通俗而言，容器中的security context用于表征在创建及运行容器时，它能够使用及访问的资源参数。   
securityContext目前只实现了capabilities和privileged ，  
etcd-discovery-controller.yaml:

kind: ReplicationController
    apiVersion: v1
    metadata:
    name: etcd-discovery
    creationTimestamp: 
    spec:
    strategy:
    type: Recreate
    resources: {}
    triggers:
    - type: ConfigChange
    replicas: 1
    selector:
    name: etcd-discovery
    template:
    metadata:
      creationTimestamp: 
      labels:
        name: etcd-discovery
    spec:
      containers:
      - name: discovery
        image: openshift/etcd-20-centos7
        args:
        - etcd-discovery.sh
        ports:
        - containerPort: 2379
          protocol: TCP
        resources: {}
        terminationMessagePath: "/dev/termination-log"
        imagePullPolicy: IfNotPresent
        capabilities: {}
        securityContext:
          capabilities: {}
          privileged: false
      restartPolicy: Always
      dnsPolicy: ClusterFirst
      serviceAccount: ''
    status: {}

===========================================

# 问题 #

--------------------

kube-controller-manager日志出现：

E0711 18:59:01.092033   18548 leaderelection.go:234\] error retrieving resource lock kube-system/kube-controller-manager: Get https://k8s-master:6443/api/v1/namespaces/kube-system/endpoints/kube-controller-manager: x509: certificate is valid for kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, not k8s-master

说明**masterssl.cnf没有指定域名**k8s-master

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ndWlzdS5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 3][]

Kubernetes 解决/var/run/secret/kubernetes.io/serviceaccount/token no such file or directory问题

kubectl get serviceaccount

NAME      SECRETS

default   0

如果没有则需要添加

在apiserver的启动参数中添加：

\--admission\_control=ServiceAccount

apiserver在启动的时候会自己创建一个key和crt（见/var/run/kubernetes/apiserver.crt和apiserver.key）

然后在启动./kube-controller-manager 时添加flag：

\--service\_account\_private\_key\_file=/var/run/kubernetes/apiserver.key

kubectl get serviceaccount

NAME      SECRETS

default   1

[http_docs.kubernetes.org.cn_27.html]: http://docs.kubernetes.org.cn/27.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70]: /images/20211213/39c8055e1907412db319a3e6ea236f2a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 1]: /images/20211213/e7629fcbab9f473e803763d57109c532.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ndWlzdS5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70]: /images/20211213/21867736a06741bf878ec61e03f27c66.png
[https_github.com_kubernetes_ ... rithm]: https://github.com/kubernetes/kubernetes/blob/v1.0.1/docs/authorization.md#authorization-algorithm
[Link 1]: http://docs.kubernetes.org.cn/80.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70 2]: /images/20211213/2ab860dd5e954adf9bfa6cd508b77136.png
[20200624132826141.png]: /images/20211213/6d8deede1f954727b52d6f65e7f49127.png
[20190708173208139.png]: /images/20211213/c9686e4ce26a41929c64249baa9939f2.png
[20190708173301660.png]: /images/20211213/774db20fe4b7428887c2498101c395e0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ndWlzdS5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 1]: /images/20211213/f3c294443b30457a8203363827251331.png
[20190712153855935.png]: /images/20211213/f94737b3e07c43e6a52dc0d3488a801c.png
[2019070818201783.png]: /images/20211213/8ebdd04290644c87a6b74f3d60c6a68a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ndWlzdS5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 2]: /images/20211213/0666d44b4ff141a2bf207b196c589ef6.png
[authority]: https://kubernetes.io/docs/admin/authorization/
[admission control]: https://kubernetes.io/docs/admin/admission-controllers/
[https_github.com_GoogleCloud ... a-pod]: https://github.com/GoogleCloudPlatform/kubernetes/blob/v1.0.1/docs/images.md#specifying-imagepullsecrets-on-a-pod
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ndWlzdS5ibG9nLmNzZG4ubmV0_size_16_color_FFFFFF_t_70 3]: /images/20211213/568cc798580d4119ab32cc2d3a723825.png