kubernetes通过一系列机制来实现集群的安全控制，其中包括API Server的认证授权、准入控制机制及保护敏感信息的Secret机制等。集群的安全性必须考虑如下几个目标：
1、保证容器与其所在宿主机的隔离
2、限制容器给基础设施或其他容器带来的干扰
3、最小权限原则---合理限制所有组件的权限，确保组件只执行它被授权的行为，通过限制单个组件的能力来限制它的权利范围
4、明确组件间边界的划分
5、划分普通用户和管理员的角色
6、在必要时允许将管理员权限赋予给普通用户
7、允许拥有Secret数据(Keys,Certs,Passwords)的应用在集群中运行
kubecernetes集群中所有资源的访问和变更都是通过kubernetes API Server的REST API实现的，由此可得知集群安全的关键点就在于辨别认证客户端身份(Authentication)及访问授权(Authorization)两个关键问题。
kubernetes提供了3种级别的客户端身份认证方式：
1、HTTPS证书认证：基于CA根证书签名的双向数字证书认证方式
2、HTTP Token认证：通过一个Token来识别合法用户
3、HTTP Base认证：通过用户名+密码的方式认证
kubernetes授权中授予不用的用户不同的访问权限，API Server目前支持下面6中授权策略，其中最主要的是RBAC授权策略；设置kubernetes授权策略方式：通过API Server的启动参数"--authorization-mode"配置
1、AlwaysDeny：表示拒绝所有请求，一般用于测试
2、AlwaysAllow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略，这是kubernetes的默认配置
3、ABAC：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制
4、Webhook：通过调用外部REST服务对用户进行授权
5、RBAC：基于角色的访问控制
6、Node：一种专用模式，用于对kubelet发出的请求进行访问控制
RBAC是什么？怎么使用？
RBAC是kubeadm安装方式的默认选项，可见非常重要；具有以下优势：
1、对集群中的资源和非资源权限均有完整的覆盖
2、整个RBAC完全由几个API对象完成，同其他API对象一样，可以用kubectl或API进行操作
3、可以在运行时进行调整，无须重新启动API Server
RBAC的API资源对象说明：
RBAC内有四个顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding；和其他API资源对象一样，用户可以使用kubectl或者API调用等方式操作这些资源对象。
Role（角色）：一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。角色只能对命名空间内的资源进行授权
示例：
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get","watch","list"]
rules参数说明：
apiGroups：支持的API组列表，例如"apiVersion: batch/v1""apVersion: extensions:v1beta1""apiVersion: apps/v1beta1"等
resources：支持的资源对象列表，例如pods,deployment,jobs等
verbs：对资源对象的操作方法列表，例如get,watch,list,delete,replace,patch等
ClusterRole（集群角色）：集群角色具有和角色一致的命名空间内资源的管理能力，但因是集群级别的范围，还可以用于以下特殊元素的授权
1、集群范围的资源，例如Node
2、非资源型的路径，例如"/healthz"
3、包含全部命名空间的资源，--all--namespaces
示例：
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get","watch","list"]
以上配置表达的是将所定义的集群角色可以让用户有权访问任意一个或所有命名空间的secrets(单指目前定义)
RoleBinding（角色绑定）：是指将一个角色绑定到一个目标上，绑定目标包括User（用户）、Group（组）或者Service Account；RoleBinding只能为某个命名空间授权。RoleBinding可以引用Role进行授权，也可以对ClusterRole进行授权，但只能对属于同一命名空间内ClusterRole定义的资源主体进行授权。常见的做法是集群管理员为集群范围预先定义好一组ClusterRole，然后在多个命名空间中重复使用这些ClusterRole。
使用RoleBinding引用Role授权
示例：
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: test-pod
namespace: default
subjects:
- kind: User
name: User_NAME
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: Pod-reader
apiGroup: rbac.authorization.k8s.io
使用RoleBinding引用CLusterRole授权
示例：
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: test-pod
namespace: defalult
subjects:
- kind: User
name: User_NAME
roleRef:
kind: ClusterRole
name: CLUSTERROLE_NAME
apiGroup: rbac.authorization.k8s.io
ClusterRoleBinding(集群角色绑定)：集群角色绑定中的角色只能是集群角色，用于进行集群级别或者对所有命名空间都生效的授权。
示例：
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: clusterrolebg_test1
subjects:
- kind: Group
name: manager
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: CLUSTERROLE_NAME
apiGroup: rbac.authorization.k8s.io
说到RBAC就必须要说一下ServiceAccount，那么ServiceAccount是什么呢？
ServiceAccount是指一个账号，是给运行在Pod里的进程使用的，为Pod的进程提供了必要的身份证明；
一个完整的示例：
