k8s RBAC 多租户权限控制实现

简介: 访问到权限分两部分 1.Authenticating认证授权配置由kube-apiserver管理 这里使用的是 Static Password File 方式。apiserver启动yaml里配置basic-auth-file即可,容器启动apiserver的话要注意这个文件需要是在容器内能访问到的。

访问到权限分两部分

1.Authenticating认证
授权配置由kube-apiserver管理

这里使用的是 Static Password File 方式。
apiserver启动yaml里配置basic-auth-file即可,容器 启动apiserver的话要注意这个文件需要是在容器内能访问到的。(可以通过挂载文件,或者在已经挂载的路径里增加配置文件)
basic-auth-file文件格式见官方文档 注意password在第一个,之前没注意被卡了很久。
修改了文件以后需要重启apiserver才能生效。这里kubectl delete 删除pod有问题,使用docker命令查看apiserver容器其实没有重启。解决方案是使用docker kill杀掉容器。自动重启。

[root@tensorflow1 ~]# curl -u admin:admin "https://localhost:6443/api/v1/pods" -k
{
   
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
   

  },
  "status": "Failure",
  "message": "pods is forbidden: User \"system:anonymous\" cannot list pods at the cluster scope",
  "reason": "Forbidden",
  "details": {
   
    "kind": "pods"
  },
  "code": 403
}

这个就是没有通过认证的报错

2.Authorization授权

k8s RBAC授权规则

简单来说就是 权限--角色--用户绑定
需要配置两个文件
一个是role/clusterRole,定义角色以及其权限
一个是roleBinding/clusterRoleBinding,定义用户和角色的关系

{
   
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
   

  },
  "status": "Failure",
  "message": "pods is forbidden: User \"admin\" cannot list pods at the cluster scope",
  "reason": "Forbidden",
  "details": {
   
    "kind": "pods"
  },
  "code": 403
}

这个就是没有权限访问,需要配置RBAC

文件如下:
方案1:role + roleBinding

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: user1
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["*"]
- apiGroups: [""] # "" indicates the core API group
  resources: ["namespaces"]
  verbs: ["*"]


kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: user1-rolebinding
  namespace: user1
subjects:
- kind: User
  name: user1 # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: myauth-user
  apiGroup: rbac.authorization.k8s.io

方案2:clusterRole + roleBinding (推荐)

clusterRole定义全局权限,roleBinding将权限限制到namespace。clusterRole仅需要定义一次。

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myauth-user
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["*"]
- apiGroups: [""] # "" indicates the core API group
  resources: ["namespaces"]
  verbs: ["*"]
- apiGroups: [""] # "" indicates the core API group
  resources: ["resourcequotas"]
  verbs: ["*"]

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: user2-rolebinding
  namespace: user2
subjects:
- kind: User
  name: user2 # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: myauth-user
  apiGroup: rbac.authorization.k8s.io

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: user1-rolebinding
  namespace: user1
subjects:
- kind: User
  name: user1 # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: myauth-user
  apiGroup: rbac.authorization.k8s.io

3.配置

新建静态密码文件

# vi /etc/kubernetes/pki/basic_auth_file
admin,admin,1004
jane2,jane,1005
user1,user1,1006
user2,user2,1007

修改apiserver配置
修改/etc/kubernetes/manifests/kube-apiserver.yaml
在一堆参数配置下面增加

  • --basic-auth-file=/etc/kubernetes/pki/basic_auth_file
eg:
    - --etcd-servers=https://127.0.0.1:2379
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
    - --basic-auth-file=/etc/kubernetes/pki/basic_auth_file

这里将静态文件放在/etc/kubernetes/pki/目录下的原因是,apiserver通过容器启动,这个路径已经挂载容器中了,可以被访问到。放在其他路径需要额外配置挂载路径。apiserver只会启动在master节点上,故仅需要在master节点上配置即可。

启动好以后在master机器上执行kubectl get all,多半是执行不成功的,因为修改apiserver配置文件后,apiserver自动重启,然后启动失败,所以就无法访问集群了。
使用docker ps 查看发现k8s_kube-scheduler 和k8s_kube-controller-manager重启了,但是apiserver没起来。
执行systemctl restart kubelet,再docker ps 就能看到apiserver启动成功了。如果还没启动起来,那再看看上面哪里配置有问题。

应用

使用--username={
   username} --password={
   password} 参数访问kubectl
参考https://kubernetes-v1-4.github.io/docs/user-guide/kubectl/kubectl_create/
kubectl get all -n user1 --username=user1 --password=user1
kubectl create -f tf1-rc.yaml --username=user1 --password=user1

使用 curl -u {username}:{password} ```js
"https://{masterIP}:6443/api/v1/" -k 访问http restful api
curl -u jane:jane2 "https://localhost:6443/api/v1/namespaces/user1/pods" -k
curl -u jane:jane2 "https://localhost:6443/api/v1/namespaces/user1" -k

curl -u user1:user1 "https://localhost:6443/api/v1/namespaces/user1" -k
curl -u user1:user1 "https://localhost:6443/api/v1/namespaces/user1/pods" -k
curl -u user1:user1 "https://localhost:6443/api/v1/namespaces/user1/resourcequotas/" -k

curl -u user2:user2 "https://localhost:6443/api/v1/namespaces/user2" -k
curl -u user2:user2 "https://localhost:6443/api/v1/namespaces/user2/pods" -k
curl -u user2:user2 "https://localhost:6443/api/v1/namespaces/user2/resourcequotas/" -k

```
本文转自CSDN-k8s RBAC 多租户权限控制实现

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
6月前
|
前端开发 NoSQL 中间件
rbac基于用户角色的权限管理
rbac - 基于角色的权限管理,介绍了acl(访问权限列表)基于用户的权限管理,rbac基于角色的权限管理。
rbac基于用户角色的权限管理
|
安全 数据安全/隐私保护
基于RBAC实现权限系统
基于RBAC实现权限系统
504 0
|
8月前
|
存储 监控 安全
深入理解RBAC权限系统
RBAC(Role-Based Access Control)是一种访问控制模型,其核心概念是基于角色的权限分配。该模型的设计目标是简化对系统资源的访问管理,提高系统的安全性和可维护性。
969 1
深入理解RBAC权限系统
|
数据安全/隐私保护 Python
rootwrap 权限控制
rootwrap 权限控制
80 0
|
监控 安全 数据安全/隐私保护
|
Kubernetes 安全 中间件
RBAC权限管理(一)
RBAC权限管理
1261 0
|
存储 缓存 运维
基于RBAC模型的权限管理设计
RBAC模型(Role-Based Access Control:基于角色的访问控制)是比较早期提出的权限实现模型,在多用户计算机时期该思想即被提出,其中以美国George Mason大学信息安全技术实验室(LIST)提出的RBAC96模型最具有代表,并得到了普遍的公认。 RBAC认为权限授权的过程可以抽象地概括为:Who是否可以对What进行How的访问操作,并对这个逻辑表达式进行判断是否为True的求解过程,也即是将权限问题转换为Who、What、How的问题,Who、What、How构成了访问权限三元组,具体的理论可以参考RBAC96。
585 0
基于RBAC模型的权限管理设计
|
监控 安全 数据安全/隐私保护
【应用安全】RBAC与ABAC:有什么区别?
在任何公司,网络用户必须经过身份验证和授权,才能访问系统中可能导致安全漏洞的部分。获得授权的过程称为访问控制。在本指南中,我讨论了管理系统访问控制的两种主要方法:基于角色的访问控制(RBAC)和基于属性的访问控制。
|
安全 数据安全/隐私保护
RBAC的用户权限管理原理
RBAC的用户权限管理原理
173 0
|
前端开发 数据安全/隐私保护
关于接口权限控制以及rbac
关于接口权限控制以及rbac
345 0
关于接口权限控制以及rbac

热门文章

最新文章