Kubernetes(k8s)权限管理RBAC详解

打印 上一主题 下一主题

主题 873|帖子 873|积分 2619

目录

一、简介

kubernetes 集群相关所有的交互都通过apiserver来完成,对于这样集中式管理的系统来说,权限管理尤其重要,在1.5版的时候引入了RBAC(Role Base Access Control)的权限控制机制
启用RBAC,需要在 apiserver 中添加参数--authorization-mode=RBAC,如果使用的kubeadm安装的集群,1.6+版本都默认开启了RBAC。
  1. $ grep -C3 'authorization-mode' /etc/kubernetes/manifests/kube-apiserver.yaml
复制代码

API Server目前支持以下几种授权策略:

  • AlwaysDeny:表示拒绝所有请求,一般用于测试。
  • AlwaysAllow:允许接收所有请求。
    如果集群不需要授权流程,则可以采用该策略,这也是Kubernetes的默认配置。
  • ABAC(Attribute-Based Access Control):基于属性的访问控制。
    表示使用用户配置的授权规则对用户请求进行匹配和控制。
  • Webhook:通过调用外部REST服务对用户进行授权。
  • RBAC:Role-Based Access Control,基于角色的访问控制(本章讲解)。
  • Node:是一种专用模式,用于对kubelet发出的请求进行访问控制。
更多权限管理,可参考:http://docs.kubernetes.org.cn/51.html#Kubernetes
二、用户分类

K8s的用户分两种,一种是普通用户一种是ServiceAccount(服务账户)。
1、普通用户

  • 普通用户是假定被外部或独立服务管理的。管理员分配私钥。平时常用的kubectl命令都是普通用户执行的。
  • 如果是用户需求权限,则将Role与User(或Group)绑定(这需要创建User/Group),是给用户使用的。
2、ServiceAccount(服务账户)**

  • ServiceAccount(服务帐户)是由Kubernetes API管理的用户。它们绑定到特定的命名空间,并由API服务器自动创建或通过API调用手动创建。服务帐户与存储为Secrets的一组证书相关联,这些凭据被挂载到pod中,以便集群进程与Kubernetes API通信。(登录dashboard时我们使用的就是ServiceAccount)
  • 如果是程序需求权限,将Role与ServiceAccount指定(这需要创建ServiceAccount并且在deployment中指定ServiceAccount),是给程序使用的。
相当于Role是一个类,用作权限申明,User/Group/ServiceAccount将成为类的实例。
工作流程图

三、K8s角色&角色绑定(以ServiceAccount展开讲解)

1)授权介绍

在RABC API中,通过如下的步骤进行授权:

  • 定义角色:在定义角色时会指定此角色对于资源的访问控制的规则。
  • 绑定角色:将主体与角色进行绑定,对用户进行访问授权。
角色

  • Role:授权特定命名空间的访问权限
  • ClusterRole:授权所有命名空间的访问权限
角色绑定

  • RoleBinding:将角色绑定到主体(即subject)
  • ClusterRoleBinding:将集群角色绑定到主体
主体(subject)

  • User:用户
  • Group:用户组
  • ServiceAccount:服务账号
​图解如下:

2)角色(Role和ClusterRole)

Role是权限的定义,在kubernetes中角色分为两种一种是Role针对特定的命名空间,一种是ClusterRole在整个集群范围内都生效。
Role示例如下:
[code]cat >Role-001.yaml

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

正序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

九天猎人

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表