Kubernetes安全机制

一、kubernetes的安全框架

1.框架

• 流程
  • kubect先请求api资源，然后是过三关
    • 第一关是认证（Authentication）
    • 第二关是授权（Authorization）
    • 第三关是准入控制（Admission Control）
  • 只有通过这三关才可能会被k8s创建资源
• K8S安全控制框架主要由下面3个阶段进行控制，每一个阶段都 支持插件方式，通过API Server配置来启用插件
• 普通用户若要安全访问集群API Server，往往需要证书、Token 或者用户名+密码；Pod访问，需要ServiceAccount

2.机制

• apiserver使用的是token认证

[root@master01 ~]# ps aux | grep apiserver
...
--token-auth-file=/opt/kubernetes/cfg/token.csv 
...

• 可以通过ServiceAccount在pod中去访问apiserver

[root@master01 ~]# kubectl get sa
NAME      SECRETS   AGE
default   1         3d

• 传输安全：告别8080，迎接6443
• 默认8080监听本地（是通过master及其他组件连接使用）

[root@master01 ~]# netstat -ntap | grep 8080 | grep LISTEN
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      1815/kube-apiserver 

• 对外提供服务端口是6443

[root@master01 ~]# netstat -ntap | grep 6443 | grep LISTEN
tcp        0      0 192.168.170.128:6443    0.0.0.0:*               LISTEN      1815/kube-apiserver 

二、三大模块

1.第一模块：认证

1）kubernetes的用户系统

• kubernetes有两种类型的用户
  • ServiceAccount
  • 一般用户

一般用户

• 一般用户被认为是由外部独立的服务(比如公司的员工)管理的
• 例如:一个分发私钥的管理员，一个像Keystone或谷歌帐户这样的用户存储，甚至一个包含用户名和密码列表的文件
• 在这方面，Kubernetes没有表示普通用户帐户的对象。不能通过API调用将普通用户添加到集群中

ServiceAccount

• 服务帐户是由Kubernetes API管理的用户。它们被绑定到特定的名称空间，并由API服务器自动创建或通过API调用手动创建。服务帐户被关联到一组用作凭证的secret中，这些secret凭证被挂载到pod中，允许集群内进程与Kubernetes API通信

• API请求要么绑定到普通用户，要么绑定到服务帐户，要么作为匿名请求处理。这意味着集群内外的每个进程，不论是PC客户端上使用kubectl的人工用户或者节点上的kubelets，再到控制平面的成员，向API服务器发出请求时都必须进行身份验证，或者被视为匿名用户

2)认证

• API SERVER 认证方式(K8S 的所有访问都是通过 api server)
  • 三种客户端身份认证：
    • HTTPS 证书认证：基于CA证书签名的数字证书认证
    • HTTP Token认证：通过一个Token来识别用户（生产环境中使用广泛）
    • HTTP Base认证：用户名+密码的方式认证
  • Authenticating proxy: 第三方授权协议

Https证书认证

[root@master01 ~]# cat /root/k8s/k8s-sert/k8s-cert.sh 
。。。
cat > server-csr.json <<EOF
{
    "CN": "kubernetes",
    "hosts": [
      "10.0.0.1",
      "127.0.0.1",
      "192.168.170.128",
      "192.168.170.129",
      "192.168.170.100",
      "192.168.170.134",
      "192.168.170.131",
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "BeiJing",
            "ST": "BeiJing",
            "O": "k8s",
            "OU": "System"
        }
    ]
}
。。。

Http Token认证

[root@master01 ~]# cat /opt/kubernetes/cfg/token.csv 
73af5869be7dea86e14a328bb99da139,kubelet-bootstrap,10001,"system:kubelet-bootstrap"

• 原理：token 是一个难以被模仿的字符串, 每个token对应一个用户名, 存放在API server能访问的一个文件中. 当客户端发起API调用时, token放在header中, API 就能识别是否非法

Http Basic认证

• 这种认证方式是把 用户名+冒号+密码 用base64 算法进行编码后放到header中进行身份识别

3）认证策略

• apiserver 拥有一条链式的认证插件, 没个请求被认证插件验证时,插件会试图将请求与以下属性进行关联

用户名(username):标识最终用户的字符串。常见的值可能是kube-admin或jane@example.com。

UID:标识最终用户并试图比username更一致和惟一的字符串。

组(group):一组字符串，它将用户与一组通常分组的用户相关联。

额外字段(extra fileds):字符串映射到包含附加信息授权方可能会发现有用的字符串列表

• 所有值对身份验证系统都是不透明的，只有在由授权方( authorizer)使用时才具有意义

• 可以同时启用多个身份验证方法。通常应该使用至少两种方法:

  • 服务帐户(service account) 的服务帐户令牌(service account token)
  • 一种用于用户身份验证的方法

• 当启用多个验证器模块时，第一个模块将成功地验证 “请求短路评估” (request short-circuits evaluation)。，如果验证失败，则进行断路操作，API服务器不保证运行验证器的执行顺序

• 所有通过验证的用户都会被添加进system:authenticated组

• 可以使用authenticating proxy 或authentication webhook与其他身份验证协议(LDAP、SAML、Kerberos、备用x509方案等)集成

3）CA认证

• 涉及的概念：根证书, 自签名证书, 密钥, 私钥, 加密算法
• 认证的步骤：</