【云原生】kubernetes安全框架RBAC
Adminssion Control实际上是一个准入控制器插件列表,发送到API Server的请求都需要经过这个列表中的每个准入控制器插件的检查, 检查不通过,则拒绝请求。K8s目前支持多种授权策略,目前企业主要使用RBAC (Role-Based Access Control,基于角色的访问控制)完成授权工作。• 资源操作方法: get , list , create , update , p
感谢点赞和关注 ,每天进步一点点!加油!
目录
一、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 权限 报错
感谢点赞和关注!
更多推荐
所有评论(0)