本文主要从不同层面与多个维度描述Kubernetes技术与架构的安全性。
云原生的安全性
从系统分层架构的角度分析，自底向上，云原生的安全性主要包括云、集群、容器以及代码四个层面，简称云原生4C安全，其架构图如下所示：
| Cloud 该层是云计算层，是由云计算的基础设施构成，主要是由云计算提供商构建，其安全性的维度包括API server接口服务器的网络访问、Node服务器节点的网络访问、访问云计算提供商的API接口服务、访问etcd、etcd加密 |
| Cluster 该层是集群层，是由集群内可配置的组件、运行在集群中的应用构成，其安全性的维度包括RBAC授权、鉴权、应用秘钥管理、符合Pod标准安全性、服务质量、网络策略、TLS安全措施 |
| Container 该层是容器层，是由容器组件构成，其安全性的维度包括容器病毒扫描以及OS依赖安全、镜像签名、安全增强、用户权限 |
| Code 该层是代码层，应用程序代码主要由开发者提供，其安全维度包括TLS安全访问、限制交互端口的范围、第三方依赖安全性、静态代码检查、动态攻击防御（例如，常见的攻击包括SQL注入、CSRF或者XSS） |
Pod安全标准
Pod的标准安全性主要包括三个级别的安全策略，由宽松到严格分别是特权（Privileged），该安全策略一般是对系统或者基础设施，默认地，权限授予给具有特权或者可信任的用户使用，基线（Baseline），该安全策略一般是对容器化层面的非关键应用的操作人员或者开发者，约束（Restricted），该安全策略一般是对Pod层面的关键应用的操作人员或者开发者，其作用是安全性增强。
服务账户（Service Account）
在Kubernetes集群中，服务账户是非人造账户ID，主要是用于Kubernetes集群内外的组件、Pod以及实体之间的信任互访，其使用场景主要包括Pod与Kubernetes集群API server服务器之间的信任访问、Pod与外部服务之间的信任访问、Pod与容器镜像服务中心之间的信任访问、第三方安全软件与不同Pod之间的信任访问，服务账号的信任访问包括token授权以及token鉴权两个部分。
Pod安全性确认
Kubernetes集群使用Pod安全性确认控制器保证Pod在创建的过程中实施Pod的安全性策略。
Kubernetes API访问控制
如上所示，外部用户使用服务账户ID信任访问Kubernetes的流程，该流程包括四个步骤，分别是获取授权、接受鉴权、授权确认、读写数据
RBAC
RBAC（Role Based Access Control）是基于角色的访问控制，每个角色是一个权限的子集合，被授权该角色的资源能拥有子集合内的权限。
Secret
Secret是Kubernetes对象类型，用于保存Kubernetes集群内的敏感信息，例如，密码、token或者SSH秘钥。
多租户
| Tenant 从系统分层架构的角度看，租户是一个不同资源类型而组成的综合体，其拥有的资源来自下层物理部署的架构、上层逻辑功能的架构以及用户群的划分 |
| Multi-team tenancy 该租户类型的资源划分的粒度是以团队为单位，每个团队拥有独立的资源集合，其中包括内存、计算、网络相关的物理资源，业务数据也是从物理数据存储上相互隔离、不同团队的业务数据是相互独立 |
| Multi-customer tenancy 该租户类型的资源划分的粒度更细、是以企业或者不同的客户为单位进行资源划分，业务数据在功能逻辑上使用权限进行隔离、客户的权限不同则拥有资源的集合不同 |
| Kubernetes资源隔离（Isolation） Kubernetes技术与架构的资源隔离主要包括两个方面，控制面资源隔离以及数据面资源隔离 |
| 控制面资源隔离（Control plane isolation） 控制面资源隔离的维度主要包括命名空间、访问控制、资源配额 |
| 数据面资源隔离（Data Plane Isolation） 数据面资源隔离的维度主要包括网络、存储、容器、节点 |
鉴权机制
现代化软件硬件系统的数据安全传输以及数据安全存储，基本上都是以数字证书的形式实现，例如，X.509类型的加密标准的数字证书，该类型数字证书的加密标准既能提供对称加密以及非对称加密、双重签名的安全保证。
安全性检查清单
Kubernetes集群技术与架构的安全性检查清单的维度主要包括鉴权授权、网络安全、Pod安全性、日志审计、Pod布局、容器镜像、权限确认控制器。
