kubernetes 认证授权

最新推荐文章于 2024-07-22 14:17:37 发布

Mlul392

最新推荐文章于 2024-07-22 14:17:37 发布

阅读量90

点赞数

分类专栏： kubernetes 文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/weixin_56744753/article/details/134295246

版权

kubernetes 专栏收录该内容

19 篇文章 0 订阅

订阅专栏

一、kubernetes API访问控制

Authentication（认证）
认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。通常启用X509 Client Certs和Service Accout Tokens两种认证方式。
Kubernetes集群有两类用户：由Kubernetes管理的Service Accounts （服务账户）和（Users Accounts）普通账户。k8s中账号的概念不是我们理解的账号，它并不真的存在，它只是形式上存在。
Authorization（授权）
必须经过认证阶段，才到授权请求，根据所有授权策略匹配请求资源属性，决定允许或拒绝请求。授权方式现共有6种，AlwaysDeny、AlwaysAllow、ABAC、RBAC、Webhook、Node。默认集群强制开启RBAC。
Admission Control（准入控制）
用于拦截请求的一种方式，运行在认证、授权之后，是权限认证链上的最后一环，对请求API资源对象进行修改和校验。
访问k8s的API Server的客户端主要分为两类：
kubectl ：用户家目录中的 .kube/config 里面保存了客户端访问API Server的密钥相关信息，这样当用kubectl访问k8s时，它就会自动读取该配置文件，向API Server发起认证，然后完成操作请求。
pod：Pod中的进程需要访问API Server，如果是人去访问或编写的脚本去访问，这类访问使用的账号为：UserAccount；而Pod自身去连接API Server时，使用的账号是：ServiceAccount，生产中后者使用居多。
kubectl向apiserver发起的命令,采用的是http方式,其实就是对URL发起增删改查的操作。
$ kubectl proxy --port=8888 &
$ curl http://localhost:8888/api/v1/namespaces/default
$ curl http://localhost:8888/apis/apps/v1/namespaces/default/deployments
以上两种api的区别是：
api它是一个特殊链接,只有在核心v1群组中的对象才能使用。
apis 它是一般API访问的入口固定格式名。
UserAccount与serviceaccount：
用户账户是针对人而言的。服务账户是针对运行在 pod 中的进程而言的。
用户账户是全局性的。其名称在集群各 namespace 中都是全局唯一的，未来的用户资源不会做 namespace 隔离，服务账户是 namespace 隔离的。
通常情况下，集群的用户账户可能会从企业数据库进行同步，其创建需要特殊权限，并且涉及到复杂的业务流程。服务账户创建的目的是为了更轻量，允许集群用户为了具体的任务创建服务账户 ( 即权限最小化原则 )。

二、pod绑定sa

创建serviceaccount：

kubectl create sa admin

绑定：

vim pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  serviceAccountName: admin
  containers:
    - name: nginx
      image: nginx

三、认证

cd /etc/kubernetes/pki/
openssl genrsa -out test.key 2048
openssl req -new -key test.key -out test.csr -subj "/CN=test"
openssl  x509 -req -in test.csr -CA ca.crt -CAkey ca.key  -CAcreateserial -out test.crt -days 365
kubectl config set-credentials test --client-certificate=/etc/kubernetes/pki/test.crt --client-key=/etc/kubernetes/pki/test.key --embed-certs=true
kubectl config set-context test@kubernetes --cluster=kubernetes --user=test
kubectl config view

切换用户（默认用户没有任何权限，需要授权）

kubectl config use-context test@kubernetes

切回admin

kubectl config use-context kubernetes-admin@kubernetes

vim roles.yaml

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

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

kubectl apply -f roles.yaml
kubectl run demo --image nginx
kubectl get pod

四、授权

RBAC（Role Based Access Control）：基于角色访问控制授权。
允许管理员通过Kubernetes API动态配置授权策略。RBAC就是用户通过角色与权限进行关联。
RBAC只有授权，没有拒绝授权，所以只需要定义允许该用户做什么即可。
RBAC包括四种类型：Role、ClusterRole、RoleBinding、ClusterRoleBinding。

RBAC的三个基本概念：
Subject：被作用者，它表示k8s中的三类主体， user， group， serviceAccount
Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。
RoleBinding：定义了“被作用者”和“角色”的绑定关系。
Role 和 ClusterRole
Role是一系列的权限的集合，Role只能授予单个namespace 中资源的访问权限。
ClusterRole 跟 Role 类似，但是可以在集群中全局使用。
RoleBinding和ClusterRoleBinding
RoleBinding是将Role中定义的权限授予给用户或用户组。它包含一个subjects列表(users，groups ，service accounts)，并引用该Role。
RoleBinding是对某个namespace 内授权，ClusterRoleBinding适用在集群范围内使用。

示例：

vim roles.yaml

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

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

---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myclusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "delete", "create", "update"]
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding						#RoleBinding必须指定namespace
metadata:
  name: rolebind-myclusterrole
  namespace:  default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: test

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding				#ClusterRoleBinding全局授权，无需指定namespace
metadata:
  name: clusterrolebinding-myclusterrole
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: test

kubectl apply -f roles.yaml
kubectl config use-context test@kubernetes
kubectl config use-context kubernetes-admin@kubernetes
kubectl delete -f roles.yaml
kubectl config delete-user test
kubectl config delete-context test@kubernetes

Mlul392

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
kubernetes 认证授权

一、kubernetes API访问控制Authentication（认证认证方式现共有8种，可以启用一种或多种认证方式，只要有一种认证方式通过，就不再进行其它方式的认证。通常启用X509 ClientCerts和ServiceAccoutTokens两种认证方式。Kubernetes集群有两类用户：由Kubernetes管理的ServiceAccounts （服务账户）和（UsersAccounts）普通账户。k8s中账号的概念不是我们理解的账号，它并不真的存在，它只是形式上存在。
复制链接

扫一扫

专栏目录