Authentication

HTTP Token 认证： 通过一个 Token 来识别合法用户

  • HTTP Token 的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串-Token来表达客户的一种方式。Token 是一个很长的很复杂的字符串，每一个Token对应的一个用户名存储在 API Server 能访问的文件中，当客户端发起 API 调用请求时，需要在HTTP Header 里放入Token

HTTP Base认证： 通过 用户名+密码的方式认证

  • 用户名+密码 ：用 BASE64 算法进行编码后的字符串放在 HTTP Request 中的 Header Authorization 域里发送给服务端，服务端收到后进行编码，获取用户名及密码 *
  • 最严格的 HTTPS 证书认证： 基于 CA 根证书签名的客户端身份认证方式

    HTTPS证书认证

    客户端证书（TLS）认证方式，也叫 HTTPS 双向认证。一般我们访问一个 https 网站，认证是单向的，只有客户端会验证服务端的身份，服务端不会管客户端身份如何。我们来大概看下 HTTPS 握手过程（单向认证）：
  1. 客户端发送 Client Hello 消息给服务端；
  2. 服务端回复 Server Hello 消息和自身证书给客户端；
  3. 客户端检查服务端证书的合法性，证书检查通过后根据双方发送的消息生成 Premaster Key，然后用服务端的证书里面的公钥加密 Premaster Key 并发送给服务端 ；
  4. 服务端通过自己的私钥解密得到 Premaster Key，然后通过双方协商的算法和交换的消息生成 Session Key（后续双方数据加密用的对称密钥，客户端也能通过同样的方法生成同样的 Key），然后回复客户端一个消息表明握手结束，后续发送的消息会以协商的对称密钥加密。

HTTPS 双向认证的过程就是在上述第 3 步的时候同时回复自己的证书给服务端，然后第 4 步服务端验证收到客户端证书的合法性，从而达到了验证客户端的目的。在 Kubernetes 中就是用了这样的机制，只不过相关的 CA 证书是自签名的：


Kubernetes-集群安全-认证 - 图1

需要认证的节点

Kubernetes-集群安全-认证 - 图2
两种类型

  • Kubernetes 组件对 API Server 的访问： kubectl、Controller Manager、Scheduler、kubelet、kube-proxy
  • Kubernetes 管理的 Pod 对容器的访问： Pod (dashborad 也是以Pod的形式运行)

安全性说明

  • Controller Manager、Scheduler 与 API Server 在同一台机器，所以直接使用 API Server的非安全端口访问，—insecure-bind-address=127.0.0.1
  • kubectl、kubelet、kube-proxy 访问 API Server 就都需要证书进行 HTTPS 双向认证

证书颁发

  • 手动签发： 通过 k8s 集群的跟 ca 进行签发 HTTPS 证书

  • 自动签发: kubelet 首次访问 API Server 时，使用 token 做认证，通过后， Controller Manger 会为kubelet生成一个证书，以后的访问都是用证书做认证了

    认证

    image.png

    kubeconfig

    kubeconfig文件包含集群参数 （CA证书、API Server地址），客户端参数(上面生成的证书和私钥)，集群context信息（集群名称、用户名）。Kubernetes组件通过启动时指定不同的kubeconfig文件可以切换到不同的集群中

    ServiceAccount

    Pod中的容器访问API Server。因为Pod的创建、销毁是动态的，所以要为它手动生成证书就不可行了。Kubernetes使用了Service Account解决了Pod访问API Server 的认证问题

    Secret 与 SA 的关系

    Kubernetes 设计了一种资源对象叫做 Secret，分为两类： 一种是用于 ServiceAccount 的 service-account-token。 另一种是用于保护用户自定义保密信息的Opaque。ServiceAccount 中用到了包含三个部分：Token、ca.crt、namespace。

  • token：是使用 API Server 私钥签名的JWT。用于访问API Server时，Server端认证

  • ca.crt： 根证书，用于Client端验证API Server发送的证书
  • namespace：标识这个service-account-token的作用域空间 ```shell [root@k8s-master01 ~]# kubectl get secret —all-namespaces |grep default-token default default-token-k2f44 kubernetes.io/service-account-token 3 28d kube-node-lease default-token-h5hjw kubernetes.io/service-account-token 3 28d kube-public default-token-cvz8b kubernetes.io/service-account-token 3 28d kube-system default-token-nft8q kubernetes.io/service-account-token 3 28d

[root@k8s-master01 ~]# kubectl describe secret default-token-nft8q -n kube-system Name: default-token-nft8q Namespace: kube-system Labels: Annotations: kubernetes.io/service-account.name: default kubernetes.io/service-account.uid: bec2652d-49bf-4464-8c72-dbcabdcaf969

Type: kubernetes.io/service-account-token

Data

ca.crt: 1025 bytes namespace: 11 bytes token: eyJhbGciOiJSUzI1NiIsImtpZCI6ImdHeE82a21RUzc2dTNkc2hJYk1NMlNFX0l6VUNsbFItbGx1U3N3Ti0tOE0ifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkZWZhdWx0LXRva2VuLW5mdDhxIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImRlZmF1bHQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJiZWMyNjUyZC00OWJmLTQ0NjQtOGM3Mi1kYmNhYmRjYWY5NjkiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06ZGVmYXVsdCJ9.k6aQGrOIlBxFmE_v5saForSb7kNYH_OcXvBs6bWtj8SdikTupIJdt2b1k-tXGZLPdqi31InnsrStOPpADPI1Pef3tjgaqsEHlJmmz0x6mp9JVhgW-rOQoTaSQIX8LoP0wXB2PMdUjHw1hB8PwQAPmsefqVN_DlL0uFYsJtbqlnA71amS-J_dgedaRDCKMPeU17PGd74UJ2LiUlzsJrr-CD1TVo5Zgg_M5RGLA8ch6ItRmF7tkG77-GvJ-PlVN8yXhH765AnZbfLsCerk1IPWoGUvunKy9i5t8EVQEb2YTRsNnOAQC5EjXZjjxMJviez1LOIEw1CGPJuc90Ehjfsg8w ```

默认情况下，每个namespace都会有一个ServiceAccount，如果Pod在创建时没有指定ServiceAccount,就会使用Pod所属的namespace的ServiceAccount