kubernetes集群的认证、受权、准入控制

1、kubernetes集群安全架构

用户使用kubectl、客户机或经过REST请求访问API。能够受权用户和Kubernetes服务账户进行API访问。当一个请求到达API时，它会经历几个阶段，以下图所示:

 

1.访问K8S集群的资源须要过三关：认证、鉴权、准入控制；

2.普通用户若要安全访问集群API Server，每每须要证书、Token或者用户名+密码；

3.Pod访问，须要ServiceAccountK8S安全控制框架主要由下面3个阶段进行控制，每个阶段都支持插件方式，经过API Server配置来启用插件。

• 1. Authentication
• 2. Authorization
• 3. Admission Contro

2、认证

API Server处理请求的过程当中，认证插件负责鉴定⽤户⾝份，受权插件⽤于操做权限许可鉴别，⽽准⼊控制则⽤于在资源对象的建立、删除、更新或链接（proxy）操做时实现更精细的许可检查。Kubernetes使⽤⾝份验证插件对API请求进⾏⾝份验证，⽀持的认证⽅式包括客户端证书、承载令牌（bearer tokens）、⾝份验证代理（authenticating proxy）或HTTP basic认证等。

下面咱们基于客户端证书来作认证：

1.将apiserver的根证书（ca.pem，ca-key.pem，ca-config.json）放到同一个目录下执行如下脚本：

[root@master hejianlai]# cat rbac-user.sh 
cat > hejianlai-csr.json <<EOF
{
  "CN": "hejianlai",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "L": "BeiJing",
      "ST": "BeiJing"
    }
  ]
}
EOF

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes hejianlai-csr.json | cfssljson -bare hejianlai 

kubectl config set-cluster kubernetes \
  --certificate-authority=ca.pem \
  --embed-certs=true \
  --server=https://172.31.182.140:6443 \     #Master ip
  --kubeconfig=hejianlai-kubeconfig
  
kubectl config set-credentials hejianlai \
  --client-key=hejianlai-key.pem \
  --client-certificate=hejianlai.pem \
  --embed-certs=true \
  --kubeconfig=hejianlai-kubeconfig

kubectl config set-context default \
  --cluster=kubernetes \
  --user=hejianlai \
  --kubeconfig=hejianlai-kubeconfig

kubectl config use-context default --kubeconfig=hejianlai-kubeconfig

 3、RBAC受权

官方地址：https://kubernetes.io/docs/reference/access-authn-authz/rbac/

RBAC是⼀种操做受权机制，⽤于界定“谁”（subject）可以或不可以“操做”（verb）哪一个或哪类“对象”（object）。动做的发出者即“主体”，一般以“帐号”为载体，它既能够是常规⽤户（User Account），也能够是服务帐号（Service Account）。“操做”（verb）⽤于代表要执⾏的具体操做，包括建立、删除、修改和查看等，对应于kubectl来讲，它一般由create、apply、delete、update、patch、edit和get等⼦命令来给出。⽽“客体”则是指操做施加于的⽬标实体，对Kubernetes API来讲主要是指各种的资源对象以及⾮资源型URL。

 

Kubernetes 使用 API ​​服务器受权 API 请求。它根据全部策略评估全部请求属性来决定容许或拒绝请求。 一个API请求的全部部分必须被某些策略容许才能继续。这意味着默认状况下拒绝权限。

（尽管 Kubernetes 使用 API ​​服务器，可是依赖于特定种类对象的特定字段的访问控制和策略由准入控制器处理。）

配置多个受权模块时，将按顺序检查每一个模块。 若是任何受权模块批准或拒绝请求，则当即返回该决定，而且不会与其余受权模块协商。 若是全部模块对请求没有意见，则拒绝该请求。一个拒绝响应返回 HTTP 状态代码 403 。

Kubernetes仅审查如下API请求属性：

• user - 身份验证期间提供的user字符串。
• group - 通过身份验证的用户所属的组名列表。
• extra - 由身份验证层提供的任意字符串键到字符串值的映射。
• API - 指示请求是否针对 API 资源。
• Request path - 各类非资源端点的路径，如/api或/healthz。
• API request verb - API 动词get，list，create，update，patch，watch，proxy，redirect，delete和deletecollection用于资源请求。要肯定资源API端点的请求动词，请参阅肯定请求动词。
• HTTP request verb - HTTP 动词get，post，put和delete用于非资源请求。
• Resource - 正在访问的资源的 ID 或名称（仅限资源请求） - 对于使用get，update，patch和delete动词的资源请求，您必须提供资源名称。
• Subresource - 正在访问的子资源（仅限资源请求）。
• Namespace - 正在访问的对象的名称空间（仅适用于命名空间资源请求）。
• API group - 正在访问的 API 组（仅限资源请求）。空字符串表示核心API组。

一、建立role其权限只有简单的查看pod，我这里指定命名空间pci

[root@master rbac]# cat role.yaml 
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: pci
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

 2.建立rolebinding 绑定用户

[root@master rbac]# cat role-binding.yaml 
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: pci
subjects:
- kind: User
  name: hejianlai # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role #this must be Role or ClusterRole
  name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
  apiGroup: rbac.authorization.k8s.io

 3、准入控制

Kubernetes系统经过三个独⽴的组件间的相互协做来实现服务帐户的⾃动化，三个组件具体为：Service Account准⼊控制器、令牌控制器（token controller）和Service Account帐户控制器。Service Account控制器负责为名称空间管理相应的资源，并确保每一个名称空间中都存在⼀个名为“default”的Service Account对象。

[root@master hejianlai]# cat sa.yaml 
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader
  namespace: pci

---

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sa-read-pods
  namespace: pci
subjects:
- kind: ServiceAccount
  name: pod-reader
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

 这时咱们能够看见在pci这个命名中间下有一个默认的defaul和刚建立的pod-reader

这时咱们验证下权限是否有效：

上图咱们能够看到除了该命名空间下除了pod能够访问，其余的权限都是被拒绝的。

经过查看这个pod-reader生成的token咱们就能够访问：

kubectl describe secret pod-reader -n pci

记住这个token要复制到记事本里取消自动换行！！！

而后咱们用这个token去访问UI时也是只能看到pci这个命名中间下的。