Kubernetes 安全框架（上）-RBAC

• 访问 K8S 集群的资源需要过三关：认证、鉴权、准入控制

• 普通用户若要安全访问集群 API
  Server，往往需要 证书、Token 或者 用户名+密码；Pod 访问，需要 ServiceAccount

• K8S 安全控制框架主要由下面 3 个阶段进行控制，每一个阶段都支持插件方式，通过 API Server 配置来启用插件。

  1.Authentication（鉴权）
  2.Authorization（授权）
  3.Admission Control（准入控制）

1.鉴权（Authentication）

三种客户端身份认证：

• HTTPS 证书认证：基于 CA 证书签名的数字证书认证
• HTTP Token 认证：通过一个 Token 来识别用户
• HTTP Base 认证：用户名 + 密码的方式认证

上述第一种：
apiserver http 接口：https 通信

1. 安全通信
2. 基于证书来认证（从证书里拿用户名、用户组）

2.授权（Authorization）

RBAC（Role-Based Access
Control，基于角色的访问控制）：负责完成授权（Authorization）工作。

根据 API 请求属性，决定允许还是拒绝。

• user：用户名
• group：用户分组
• extra：用户额外信息
• API
• 请求路径：例如/api，/healthz
• API 请求方法：get，list，create，update，patch，watch，delete
• HTTP 请求方法：get，post，put，delete
• 资源
• 子资源
• 命名空间
• API 组

3.准入控制（Admission Control）

AdminssionControl 实际上是一个准入控制器插件列表，发送到 APIServer 的请求都需要经过这个列表中的每个准入控制器插件的检查，检查不通过，则拒绝请求。

准入控制：

• 用户可以定制化插件
• 官方实现一些高级插件

基于角色的权限访问控制：RBAC

RBAC（Role-Based Access
Control，基于角色的访问控制），允许通过 Kubernetes API 动态配置策略。

分类

角色

• Role：授权特定命名空间的访问权限
• ClusterRole：授权所有命名空间的访问权限

角色绑定

•RoleBinding：将角色绑定到主体（即 subject）
•ClusterRoleBinding：将集群角色绑定到主体

主体（subject）

• User：用户
• Group：用户组
• ServiceAccount：服务账号（给应用去赋予权限，参考 Ingress 配置，当 k8s 应用程序要访问 apiserver 时，需要配置 ServiceAccount，让应用程序携带 token 去访问 apiserver）

案例

为 aliang 用户授权 default 命名空间 Pod 读取权限

图片解释：当给 apiserver 发起一个请求时，apiserver 会查看校验 x509 格式的证书，从中提取用户名和组，然后匹配当前创建的 RBAC 规则，看能不能满足现在发起的请求，如果不满足的话直接拒绝请求

• 1.用 K8S CA 签发客户端证书：cert.sh

cat > ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "kubernetes": {
        "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ],
        "expiry": "87600h"
      }
    }
  }
}
EOF

cat > aliang-csr.json <<EOF
{
  "CN": "aliang",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "BeiJing",
      "L": "BeiJing",
      "O": "k8s",
      "OU": "System"
    }
  ]
}
EOF

cfssl gencert -ca=/etc/kubernetes/pki/ca.crt -ca-key=/etc/kubernetes/pki/ca.key -config=ca-config.json -profile=kubernetes aliang-csr.json | cfssljson -bare aliang

参数解释：
ca-config.json ：ca 配置文件
aliang-csr.json：证书请求文件
CN: 用户名
O:用户组

若是二进制部署的 k8s 集群，请注意证书路径！！！

• 2.生成 kubeconfig 授权文件 kubeconfig.sh

kubectl config set-cluster kubernetes \
    --certificate-authority=/etc/kubernetes/pki/ca.crt \
    --embed-certs=true \
    --server=https://192.168.0.7:6443 \
    --kubeconfig=aliang.kubeconfig

# 设置客户端认证
kubectl config set-credentials aliang \
    --client-key=aliang-key.pem \
    --client-certificate=aliang.pem \
    --embed-certs=true \
    --kubeconfig=aliang.kubeconfig

# 设置默认上下文
kubectl config set-context kubernetes \
    --cluster=kubernetes \
    --user=aliang \
    --kubeconfig=aliang.kubeconfig

# 设置当前使用配置
kubectl config use-context kubernetes \
    --kubeconfig=aliang.kubeconfig

192.168.0.7 指的是 master 节点的 IP，不能随意指定

aliang.kubeconfig 内容格式与 ~/.kube/config 一致

此时，使用 kubectl --kubeconfig=aliang.kubeconfig get pod 还是没有权限访问 pod 的，因为还需要创建 RBAC 权限策略

• 3.创建 RBAC 权限策略

#定义role角色,权限组：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  
 ---

#创建角色绑定,声明主体：
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: aliang
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

参数解释：
resources:可以访问的资源(后面需使用复数形式)
verbs：操作资源的方法

若想新增其他权限，请参看官方文档:使用 RBAC 鉴权，即时生效

apply 过后既可以使用 kubectl --kubeconfig=aliang.kubeconfig get pod 访问 pod 了，但其余的资源比如 svc，指定命名空间或者是删除 pod 也无权访问。