最好的K8S 安全机制介绍 3 ——RBAC授权
RBAC 授权
RBAC使用RBAC.authoriz.k8s.io API组驱动授权决策,允许管理员通过Kubernetes API动态配置策略。
RBAC 的API 资源对象说明
-
Role—— 一组权限的集合,只有许可形式的权限,没有拒绝形式的权限, 用户被授予角色即表示拥有角色对应的资源的访问权限。角色存在与namespace 内,跨 namespace的角色需要时用cluster role。
-
Cluster Role—— 集群角色,和角色拥有同样的作用,但是其范围为整个集群。同时拥有集群范围的资源类型(如 NODE, /healthz 等)访问权限。
-
aggregated cluster role—— 聚合集群角色,可以让一个集群角色,拥有其他几个集群角色的权限 k8s version 1.9+
-
RoleBinding——将角色绑定到到一个目标上,目标可以是user,group,service account
-
ClusterBinding—— 将集群角色绑定到一个目标上,目标可以是user,group,service account。
一个读取default namespace 中 pod的role的例子
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"] #注意,resources 的值都是资源类型的复数形式,比如资源类型pod,就要写pods,rolebinding 就要写rolebindings
verbs: ["get", "watch", "list"]
一个能够访问所有namespace 中secret的cluster role的例子
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"] #注意,resources 的值都是资源类型的复数形式,比如资源类型pod,就要写pods,rolebinding 就要写rolebindings
verbs: ["get", "watch", "list"]
一个聚合集群角色(aggregate cluster role)的例子
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring
aggregationRule:
clusterRoleSelectors:
- matchLabels:
rbac.example.com/aggregate-to-monitoring: "true" # 这里需要和下面的cluster role的label 匹配
rules: [] # controller manager 自动填充此处的值.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-endpoints
labels:
rbac.example.com/aggregate-to-monitoring: "true"
rules:
- apiGroups: [""]
resources: ["services", "endpoints", "pods"]
verbs: ["get", "list", "watch"]
一个 rolebinding的例子
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane # 注意大小写铭感
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role #这里必须是 Role 或者 ClusterRole
name: pod-reader # 这里的名称必须和创建的 role 或者 cluster role 匹配.
apiGroup: rbac.authorization.k8s.io
一个clusterrolebingding 的例子,允许所有在manager 组下的用户都能够读取所有命名空间下的secret
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # 大小写敏感
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
对资源的引用方式
大多数资源可以通过endpoint URL 的方式进行引用比如pod的日志.
GET api/v1/namespaces/{namespace}/pods/{name}/log
完整的URL 范式如下
api/GROUPNAME/VERSION/namespaces/{namespace-instance-name}/RESOURCENAME/{resource-instance-name}/$SUBRESOURCENAME
大写字母表示k8s内建的术语值
{}表示某一类术语的实例值
例如groupname 可以是rbac.authorization.k8s.io 但或者extentions 但是不会是一个实例值.
RESOURCENAME 可能是pods(复数形式)或者secrets等
namespace 就可能是一个实例值比如default 或者test ,那么就可能是pod-1230d的形式
注意当GROUPNAME 是core的时候, GROUPNAME省略不写
更多详情,请见api 说明文档
如果要读取多个资源,可以在role的定义文件中,将resources 定义为一个数组
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"] # 资源列表
verbs: ["get", "list"]
资源可以通过ResourceName 进行引用,在指定Resource Name 后,使用get delete update 和patch 动词的请求,就会被限制在这个资源范围内.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: configmap-updater
rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["my-configmap"]
verbs: ["update", "get"]
默认的角色和角色绑定
adminssion control
在请求通过认证与授权后,并不能获得成功的响应还需要通过adminssion control的检查才能成功获取资源内容. adminssion control 通过其自身包含的plugins 来进行检查. adminssion control 作为一部分组件,包含在api server 中, 通过在api server 启动参数进行设置
kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...
plugins 简介
AlwaysPullImages
在启动容器之前,总是尝试重新下载镜像。
DefaultStorageClass
关注PersistentVolumeClaim资源的创建,如果其中没有包含任何设定的Storage class,则为其设置为指定的值,如果没有设置default storage class 此控制器不会进行任何操作,如果设置了2个及以上,会返回错误。此控制器只关注PVC的创建过程,更新过程无效。
DefaultTolerationSeconds
对没有设置node.kubernetes.io/not-ready:NoExecute
或 node.alpha.kubernetes.io/unreachable:NoExecute
容忍的pod 设置5分钟的默认容忍时间
其他详细介绍请参见 adminssion control 文档
如果文章对您有帮助,请点一下下面的 "喜欢"