k8s安全

k8s认证问题

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

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

Controller Manager、Scheduler 与 API Server 在同一台机器，所以直接使用 API Server 的非安全端口访问。

kubectl、kubelet、kube-proxy 访问 API Server 就都需要证书进行 HTTPS 双向认证。

Pod调度

因Pod是动态调度的，所以Pod访问通过ServiceAccount进行。

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

查看pod的安全文件，默认目录如下:

/run/secrets/kubernetes.io/serviceaccount

不单独指定的话这三个目录为默认，可在describe中查看

鉴权

鉴权是确定请求方有哪些资源的权 限。

API Server 目前支持以下几种授权策略 （通过 API Server 的启动参数 “--authorization-mode” 设置） AlwaysDeny：表示拒绝所有的请求，一般用于测试

AlwaysAllow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略

ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户 请求进行匹配和控制

Webbook：通过调用外部 REST 服务对用户进行授权

RBAC（Role-Based Access Control）：基于角色的访问控制，现行默认规则

Kubenetes 并不会提供用户管理，那么 User、Group、ServiceAccount 指定的用户又是从哪里 来的呢？ Kubenetes 组件（kubectl、kube-proxy）或是其他自定义的用户在向 CA 申请证书时，需要提供一个 证书请求文件.

{
       "CN": "admin",
        "hosts": [],
        "key": {
        "algo": "rsa",
        "size": 2048
},
           "names": [
{
             "C": "CN",
             "ST": "HangZhou",
             "L": "XS",
             "O": "system:masters",
             "OU": "System"
} 
]
}

API Server会把客户端证书的 CN 字段作为User，把 names.O 字段作为Group.