k8s---安全机制

k8s的安全机制,分布式集群管理工具,就是容器编排。安全机制的核心:APIserver。为整个集群内部通信的中介,也是外控控制的入口。所有的机制都是围绕apiserver来进行设计:

请求api资源:

1、认证

2、鉴权

3、准入机制

三个条件都通过,才可以在k8s集群当中创建。

认证

认证:Authentcation

HTTP TOKEN:通过token识别合法用户。tocken是一个很长很复杂的字符串,字符串是用来表达客户的一种方1、式。每一个token对应一个用户名,用户名存储在apiserver能够访问的文件中。

客户端发起请求时,http heard包含token

客户端发起请求---------------token-------------apiserver(用户存储文件)--------------解码--------------用户名--------------访问集群。

2、http base:用户+密码的验证方式。用户和密码都是通过base64进行加密,加密完成的字符串,http request的headr Authorization发送给服务端。服务端收到加密字符串,解码,获取用户名和密码,验证通过,登录成功。

3、https证书:最严重的方式,也是最严谨的方式,基于CA根证书签名的用户端身份进行验证。

认证的访问类型:

k8s组件对api server组件的访问:kubelet kube-proxy

pod对APl server的访问。pod coredns、dashboard都是pod,也需要访问api

客户端访问、kubectl访问

kubelet kube-proxy controller manager sheduler 与apiserver在一台服务器,可以直接使用api server的非安全端口访问。

kubectl kubelet kube-proxy 都是通过apiserver的https证书,进行双向验证,都是用6443端口进行验证。

签发证书的方式

1、手动签发:二进制部署就是手动签发,CA签发----把证书匹配到每个对应组件,然后访问6443即可

2、自动签发:kubeadm,kubelet第一次访问api server使用token,token通过之后,controller manager会为kubelet生成一个证书以后都是通过证书访问。kubeadm修改了证书的有效期,默认1年。

3、kubeconfig文件包含集群的参数,CA证书,APIserver地址,客户端的证书(客户端的证书和私钥),集群的名称和用户名。

k8s组件通过启动时指定访问不同的kubeconfig,可以访问不同的集群--------apiserver-----------namespace--------资源对象------pod--------容器

kubeconfig既是集群的描述文件,也是一个集群信息的保存文件,包含了集群的访问方式和认证信息

~/.kube/config 保存的时kubectl的访问认证信息

4、serviceAccount:就是为了方便pod中的容器访问apiserver。pod的一切动作(增删查改)动态的,每个pod需要手动生成一个证书,使用serviceAccount来进行循环认证,service Account 里面包含了统一的认证信息,直接进行api server访问。

5、secret:保存资源对象、保存的是自定义的保密信息。

serviceAccount保存的是token service-account-token

serviceAccount的组成部分

1、token

2、ca.crt

3、namespace

这三个部分都会被自动挂载到pod当中

认证

鉴权:之前的认证过程只是确认了双方都是可信的。可以互相通信。健全是为了确定请求方的访问权限。

能做哪些指定的操作。这些操作都是由鉴权来决定的。

通俗来讲:能做那些操作。

鉴权的策略

1、AlwayDeny:拒绝所有,一般测试

2、AlwaysAllow:允许所有,应用测试

3、ABAC attribute-based access control 基于属性的访问控制

4、webhook:外部访问集群内部的的鉴权方式

5、RBAC role-based access control 基于角色的控制访问控制,也是k8s现在默认的规则机制。

角色:

role: 指定密码空间的资源控制限制

rolebind:将角色绑定到指定的命名空间

集群

clusterrole:可以授权所有命名空问的资源控制权限

clusterrolebinding:将集群的角色绑定到命名空间

准入控制:

准入控制是apiserver的一个准入控制器的插件列表,不同的插件可以实现不同的准入控制机制。

一般情况下,建议使用官方默认的准入控制器 limitRanger(命名空间的配额管理)、serviceAccount、resourceQuota(命名空间的配额限制)都属于准入控制器。

3、实验,实现不同用户管理自己的命名空间

实验举例

实验目的:实现不同用户管理自己的命名空间

认证--->---鉴权--->---准入机制

命名空间: lucky-cloud

上传证书文件并赋权

bash 复制代码
useradd lucky
passwd lucky
#创建一个用户
 
mkdir lucky
cd /usr/local/bin/
chmod +x cfssl*
 
vim user-cert.sh
cat > lucky-csr.json <<EOF
{
 "CN": "lucky",
 "hosts": [],
 "key": {
   "algo": "rsa",
   "size": 2048
},
 "names": [
  {
   "C": "CN",
   "ST": "Nanjing",
   "O": "k8s",
   "OU": "system"
   }
  ]
}
  EOF
 
chmod +x user-cert.sh
./user-cert.sh
 
cd /etc/kubernetes/pki/
cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /opt/lucky/lucky-csr.json | cfssljson -bare lucky
#基于设定的信息,创建一个认证证书
bash 复制代码
cd /opt/lucky
 
vim rbac-kubeconfig.sh
APISERVER=$1
# 设置集群参数
export KUBE_APISERVER="https://$APISERVER:6443"
kubectl config set-cluster kubernetes \
  --certificate-authority=/etc/kubernetes/pki/ca.crt \
  --embed-certs=true \
  --server=${KUBE_APISERVER} \
  --kubeconfig=lucky.kubeconfig
 
# 设置客户端认证参数
kubectl config set-credentials lucky \
  --client-key=/etc/kubernetes/pki/lucky-key.pem \
  --client-certificate=/etc/kubernetes/pki/lucky.pem \
  --embed-certs=true \
  --kubeconfig=lucky.kubeconfig
 
# 设置上下文参数
kubectl config set-context kubernetes \
  --cluster=kubernetes \
  --user=lucky \
  --namespace=lucky-cloud \
  --kubeconfig=lucky.kubeconfig
  
kubectl create namespace lucky-cloud
chmod +x rbac-kubeconfig.sh
./rbac-kubeconfig.sh 192.168.10.10
#此处为master的ip
 
# 使用上下文参数生成 lucky.kubeconfig 文件
kubectl config use-context kubernetes --kubeconfig=lucky.kubeconfig
 
//查看证书
cat lucky.kubeconfig

bash 复制代码
mkdir /home/lucky/.kube
cp lucky.kubeconfig /home/lucky/.kube/config
chown -R lucky:lucky /home/lucky/.kube/
 
 
//RBAC授权
vim rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: lucky-cloud
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "create"]
 
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: lucky-cloud
subjects:
- kind: User
  name: lucky
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
  
  
kubectl apply -f rbac.yaml
 
kubectl get role,rolebinding -n lucky-cloud
bash 复制代码
//切换用户,测试操作权限
su - lucky
 
vim pod-test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-test
spec:
  containers:
    - name: nginx
      image: nginx
 
 
kubectl create -f pod-test.yaml
 
kubectl get pods -o wide
bash 复制代码
//访问 svc 资源就会被拒绝
kubectl get svc
 
//也无法访问 default 命名空间
kubectl get pods -n default
 
//使用 root 用户查看
kubectl get pods -n lucky-cloud -o wide
 
//也可以通过绑定 admin 角色,来获得管理员权限
kubectl create rolebinding lucky-admin-binding --clusterrole=admin --user=lucky --namespace=lucky
相关推荐
九皇叔叔2 小时前
Kubernetes 资源管理方式详解:命令式与声明式管理
docker·容器·k8s
迪康Defender5 小时前
终端安全实战:如何高效解决企业U盘泄密与管控难题
运维·网络·安全·web安全·终端安全管理
网安小学生(兼顾数据库版)5 小时前
固件+软件供应链:ONEKEY+Mend如何实现全链路安全覆盖
网络·安全·web安全
春天花会开1316 小时前
Supabase 自部署 Edge Functions 超时从 60s 延长到 360s 完整复盘
运维·云原生
珠海西格电力7 小时前
零碳园区管理系统“智慧大脑”功能对园区运营成本的影响有哪些?
大数据·人工智能·安全·系统架构·能源
发量惊人的中年网工7 小时前
2026年DDoS防护方案怎么选?从攻击响应、清洗位置到成本账单,解析全球高防方案
大数据·网络·安全·ddos
国科安芯8 小时前
抗辐射LDO芯片在星载SAR成像系统中的供电架构应用研究
安全·ldo·成像系统·抗辐射·星载sar
程序猿小郑8 小时前
Docker Compose 构建完整服务实战指南:从入门到最佳实践
docker·容器
航飞光电市场经理10 小时前
UWB定位技术选型指南:从芯片架构到定位引擎的底层能力分析
大数据·人工智能·物联网·安全·人员定位
终端安全笔记12 小时前
iOS 27 之后「策略空转」:设备升级不报错,但旧策略不再管它
android·网络·安全·ios·智能手机