kubernetes安全框架RBAC

感谢点赞和关注 ,每天进步一点点!加油!

目录 

一、Kubernetes 安全概述

二、鉴权、授权和准入控制

2.1 鉴权(Authentication)

2.2 授权(Authorization)

2.3 准入控制

三、基于角色的权限访问控制: RBAC

四、案例:为指定用户授权访问不同命名空间权限


一、Kubernetes 安全概述


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

1. Authentication (鉴权)

2. Authorization (授权)

3. Admission Control (准入控制)


二、鉴权、授权和准入控制


2.1 鉴权(Authentication)

客户端要想访问K8s集群API Server,一般需要证书、 Token或者用户名+密码; 如果Pod访问,需要ServiceAccount

三种客户端身份认证:

• HTTPS 证书认证:基于CA证书签名的数字证书认证

• HTTP Token认证:通过一个Token来识别用户

• HTTP Base认证:用户名+密码的方式认证

2.2 授权(Authorization)

K8s目前支持多种授权策略,目前企业主要使用RBAC (Role-Based Access Control,基于角色的访问控制)完成授权工作。

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

比较常见的授权维度:

• user:用户名

• group:用户分组

• 资源,例如pod、 deployment

• 资源操作方法: get , list , create , update , patch ,watch , delete

• 命名空间

• API组

2.3 准入控制


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


三、基于角色的权限访问控制: RBAC


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

角色

• Role:授权特定命名空间的访问权限

• ClusterRole:授权所有命名空间的访问权限

角色绑定

• RoleBinding:将角色绑定到主体(即subject)

• ClusterRoleBinding:将集群角色绑定到主体

主体(subject)

• User:用户

• Group:用户组

• ServiceAccount:服务账号


四、案例:为指定用户授权访问不同命名空间权限


示例:为kangll用户授权default命名空间Pod读取权限

1. 用K8S CA签发客户端证书

2. 生成kubeconfig授权文件

3. 创建RBAC权限策略

集群信息

角色

IP

组件

k8s-master1

192.168.2.119

apiServer , controller, schedule, etcd

k8s-node1

192.168.2.118

kubelet , kube-proxy, docker ,etcd

k8s-node2

192.168.2.210

kubelet , kube-proxy, docker ,etcd

安装cfssl 工具,用于生成证书

wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
chmod +x cfssl_linux-amd64 cfssljson_linux-amd64 cfssl-certinfo_linux-amd64
mv cfssl_linux-amd64 /usr/local/bin/cfssl
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
mv cfssl-certinfo_linux-amd64 /usr/bin/cfssl-certinfo

chmod +x  /usr/local/bin/cfssl
chmod +x  /usr/local/bin/cfssljson
chmod +x  /usr/bin/cfssl-certinfo

运行如下命令,生成证书

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

cat > kangll-csr.json <<EOF
{
  "CN": "kangll",
  "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 kangll-csr.json | cfssljson -bare kangll

如下图:

生成kubeconfig授权文件, 运行如下命令:

kubectl config set-cluster kubernetes \
  --certificate-authority=/etc/kubernetes/pki/ca.crt \
  --embed-certs=true \
  --server=https://192.168.2.119:6443 \
  --kubeconfig=kangll.kubeconfig
 
# 设置客户端认证
kubectl config set-credentials kangll \
  --client-key=kangll-key.pem \
  --client-certificate=kangll.pem \
  --embed-certs=true \
  --kubeconfig=kangll.kubeconfig

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

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

 运行rbac.yaml, 创建RBAC权限策略

运行rbac.yaml, 创建RBAC权限策略 

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

---

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: kangll
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

kangll用户成功的读取 pod 信息

没有delete pod 权限 报错

感谢点赞和关注!

猜你喜欢

转载自blog.csdn.net/qq_35995514/article/details/130462559
今日推荐