版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/huangjun0210/article/details/86704828
kubernetes集群安全
1. APIServer安全模型
APIServer的安全验证环节
- 0：传输安全（Transport Sercurity）
- 1：身份验证（Authentication）
- 2：授权（Authorization）
- 3：准入控制（Admission Control）
传输安全是APIServer安全模型的基础
- APIServer的非安全端口（–insecure-port）近用于测试或其他master组件与APIServer交互，不会进行身份验证和授权
- APIServer的安全端口（–secure-port=6443）
- 所有内外部发起的到APIServer的请求均通过安全端口与APIServer进行交互
2. APIServer安全验证步骤
2.1 身份验证（Authentication）
身份验证环节关注API请求的Header
- 目标：身份验证，并识别出请求所代表的kubemetes user信息
- 验证策略：支持client certificates， bearer tokens，HTTP basic auth以及authenticating proxy
- 结果：通过身份验证的请求会被附上一些身份信息属性，包括Username、UID、Groups以及一些对授权环节可能有用的信息
Kubernetes 中的"User"：Normal User和ServiceAccount
- Normal User：Kubernetes中并没有任何对象可以用来表示Normal User
- Service Account：由Kubernetes管理的、用于pod访问apiserver的"user"
- 匿名请求：username - system:anonymous , group - system:unauthenticated
身份验证策略：支持多种验证策略，采用"短路验证"方式
- 客户端证书验证：–client-ca-file=SOMEFILE。Usemame={CN}，Groups={Organizations}
- Basic Auth：–basic-auth-file=SOMEFILE
Authorization： Basic BASE64ENCODED(USER:PASSWORD} -> password,user,uid,“groupl,group2,group3”
- Bearer Token：–token-auth-file=SOMEFILE
Authorization：Bearer THETOKEN -> token,user,uid,“groupl,group2,group3”
Service Account:
- 由Kubernetes自动创建，使用签名bearer token对请求进行验证
- 组成：Service Account -> {name, namespace, secret}；secret -> {ca.crt, namespace, token}
- Secret 对象自动挂载到 Pod 内/var/run/secrets/kubernetes.io/serviceaccount 路径下
Username: system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)
Groups:system:serviceaccounts、system:serviceaccounts:(NAMESPACE)
2.2 授权（Authorization)
根据请求信息和授权策略判断请求是否具有操作目标对象的权限
- 支持多种授权模块：ABAC，RBAC，Node，Webhook等
- 启用授权模块：–authorization-mode=xx,yy
- 开启多种授权模块时，采用短路方式授权
Kubernetes RBAC实现
通过Role和RoleBinding实现了RBAC中三类元素的映射连接
2.3 准入控制（Admission Control）
API请求的结果写入etcd之前的最后一道安全防线
- Kubernetes内置了一些admission controllers，可以通过apiserver 的–admission-control 配置开启
- 意义：和APIServer配合共同实现一些高级功能
- 工作方式：请求依次通过所有admission controller，如果有一个controller返回失败，则请求失败