k8s认证和授权和token User account和 server account
https://blog.csdn.net/weixin_49888547/article/details/125169107
https://blog.csdn.net/weixin_43266367/article/details/127146419
https://cuichongxin.blog.csdn.net/article/details/121095698
https://blog.csdn.net/qq_34556414/article/details/123811196
https://blog.51cto.com/kaliarch/5912217 脚本
User account:实实在在现实中的人,人可以登陆的账号,客户端想要对 apiserver 发起请求,
apiserver 要识别这个客户端是否有请求的权限,那么不同的用户就会有不同的权限,靠用户账号表
示,叫做 username
ServiceAccount:方便 Pod 里面的进程调用 Kubernetes API 或其他外部服务而设计的,是
kubernetes 中的一种资源
sa 账号:登陆 dashboard 使用的账号
user account:这个是登陆 k8s 物理机器的用户
1:docker cp 3d5997a058c7:/etc/kubernetes/ssl/kube-ca.pem ./
kubectl config set-cluster k8s --server=https://172.29.1.11:6443 --certificate-authority=kube-ca.pem --embed-certs=true --kubeconfig=/opt/use/cbmljs.conf 集群
2:
umask 077;openssl genrsa -out cbmljs.key 2048
openssl rand -writerand .rnd
openssl req -new -key cbmljs.key -out cbmljs.csr -subj "/O=k8s/CN=cbmljs"
docker cp 3d5997a058c7:/etc/kubernetes/ssl/kube-ca-key.pem ./
openssl x509 -req -in cbmljs.csr -CA kube-ca.pem -CAkey kube-ca-key.pem -CAcreateserial -out cbmljs.crt -days 365
user:
kubectl config set-credentials cbmljs --client-certificate=cbmljs.crt --client-key=cbmljs.key --embed-certs=true --kubeconfig=/opt/use/cbmljs.conf 用户
kubectl config view --kubeconfig=/opt/use/cbmljs.conf
第七步 创建context配置,语句是 set-context,如下:
kubectl config set-context cbmljs@k8s --cluster=k8s --user=cbmljs --kubeconfig=/opt/use/cbmljs.conf
第八步 切换context配置
kubectl config use-context cbmljs@k8s --kubeconfig=/opt/use/cbmljs.conf
第九步 授权
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pods-reader
rules:
- apiGroups:
- ""
resources:
- pods
- namespaces
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: cbmljs-pods-reader
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pods-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: cbmljs
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-reader
rules:
- apiGroups:
- ""
resources:
- pods
- namespaces
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: billy-read-all-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: cbmljs
-------------------------------------------------------------------------------------------------------------------------------------
ServiceAccount
Service account 是为了方便 Pod 里面的进程调用 Kubernetes API 或其他外部服务而设计的。它
与 User account 不同,User account 是为人设计的,而 service account 则是为 Pod 中的进程
调用 Kubernetes API 而设计;User account 是跨 namespace 的,而 service account 则是仅
局限它所在的 namespace;每个 namespace 都会自动创建一个 default service account;
开启 ServiceAccount Admission Controller 后
1)每个 Pod 在创建后都会自动设置 spec.serviceAccount 为 default(除非指定了其他
ServiceAccout)
2)验证 Pod 引用的 service account 已经存在,否则拒绝创建;
当创建 pod 的时候,如果没有指定一个 serviceaccount,系统会自动在与该 pod 相同的
namespace 下为其指派一个 default service account。这是 pod 和 apiserver 之间进行通信
kubectl create serviceaccount test1
kubectl describe serviceaccount test1
kubectl get secret
kubectl describe secret test1-token-ghqqf
kubectl config view
kubectl get secret/secret-for-my-sa -o jsonpath={.data.token} |base64 -d
kubectl config set-credentials my-sa --token <token> --kubeconfig test-kubeconfig
kubectl config set-context my-sa@k8s-cluster1 --cluster k8s-cluster1 --user my-sa --kubeconfig test-kubeconfig
------------------------------------
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pods-reader
namespace: default
rules:
- apiGroups: [""] #核心API群组
resources: ["pods", "services", "pods/log"] #规则对pods、services和pods/log(pod的日志)资源生效
verbs: ["get", "list", "watch"] #仅能执行get、list和watch操作
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: pods-reader-for-my-sa
namespace: default
subjects:
- kind: ServiceAccount
name: my-sa
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pods-reader