K8s提权之RBAC权限滥用_user "admin" cannot list resource "roles" in api g

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

k8s的RBAC

RBAC - 基于角色的访问控制。

RBAC 使用 rbac.authorization.k8s.io API Group 来实现授权决策，允许管理员通过 Kubernetes API
动态配置策略，要启用 RBAC ，需要在 apiserver 中添加参数 --authorization- mode=RBAC ，如果使用的 kubeadm 安装的集群，1.6 版本以上的都默认开启了 RBAC :
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep "authorization- mode"

RBAC相关对象

K8s所有的资源对象都是模型化的API对象，允许执行CRUD，RBAC也有相关API对象，像Role、ClusterRole对象都是K8s内部的 API
资源，可以使用 kubectl 相关的命令来进行操作：

Role 和 ClusterRole ：角色和集群角色，这两个对象都包含上面的 Rules 元素，二者的区别在于，在 Role 中，定义的规则只适用于单个命名空间，也就是和 namespace 关联的，而 ClusterRole 是集群范围内的，因此定义的规则不受命名空间的约束。

RoleBinding 和 ClusterRoleBinding ：角色绑定和集群角色绑定，简单来说就是把声明的 Subject 和我们的 Role 进行绑定的过程(给某个用户绑定上操作的权限)，二者的区别也是作用范围的区别：RoleBinding 只会影响到当前 namespace 下面的资源操作权限，而 ClusterRoleBinding 会影响到所有的 namespace。

举一些RBAC使用的例子。

创建一个只能访问固定namespace的的 `hx` 用户

1.新创建一个用户凭证

给hx用户创建一个私钥：

openssl genrsa -out hx.key 2048

再使用这个私钥创建一个 证书签名请求文件 , -subj 参数后是用户名和组(CN表示用户名，O表示组)：

openssl req -new -key hx.key -out hx.csr -subj "/CN=hx/O=huoxian"

然后再使用K8s的CA证书来批准上面的证书请求：

这时候证书文件生成成功：

$ ls h*                                                                                                              ─╯
hx.crt  hx.csr  hx.key
现在使用创建的证书和私钥来在集群中创建新的凭证和上下文(Context): 
sudo kubectl config set-credentials hx --client-certificate=hx.crt --client- key=hx.key
 
 为hx用户设置新的 Context: 
$ sudo kubectl config set-context hx-context --cluster=kubernetes --namespace=kube-system --user=hx                  ─╯
Context "hx-context" created.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: hx-role
  namespace: kube-system
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["deployments", "replicasets", "pods"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # 也可以使用['*']
其中几个重要的字段： 
  apiGroups：其中的apiGroups: ["", "extensions", "apps"]为什么这么写？是因为通过https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/文档查询得知，Pod属于 core API Group(为空即可)，Deployment属于 apps API Group，ReplicaSets属于extensionsAPI Group。
 
  verbs:可以对这些资源对象执行的操作,如果是所有操作就用*代替。
 
创建hx-role这个Role：
  
2.创建角色权限绑定
 
将hx用户和这个role绑定起来： 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: hx-rolebinding
  namespace: kube-system
subjects:
                    1、网络安全理论知识（2天）①了解行业相关背景，前景，确定发展方向。②学习网络安全相关法律法规。③网络安全运营的概念。④等保简介、等保规定、流程和规范。（非常重要）2、渗透测试基础（一周）①渗透测试的流程、分类、标准②信息收集技术：主动/被动信息搜集、Nmap工具、Google Hacking③漏洞扫描、漏洞利用、原理，利用方法、工具（MSF）、绕过IDS和反病毒侦察④主机攻防演练：MS17-010、MS08-067、MS10-046、MS12-20等3、操作系统基础（一周）
				java调用k8s api接口时报错信息：
Message: Forbidden! User admin doesn't have permission. namespaces is forbidden: User "admin" cannot list resource "namespaces" in API group "" at the cluster scope.
解决方案：
kubectl create clusterrolebinding admin-cr --clusterrole=clus
Error from server (Forbidden): nodes.metrics.k8s.io is forbidden: User "kubernetes" cannot list resource "nodes" in API group "metrics.k8s.io" at the cluster scope
Secrets
Namespaces
资源与api group关联（如pods属于core api group，deployments属于apps api group）。
在RBAC中的几个概念：
Rules：规定一组可以在不同api group上的资源执行的规则（verbs）
Role与Clus
				1.在k8s集群使用过程中,总是遇到各种rbac的权限问题.记录了几个报错,见下:
"message": "pods is forbidden: User \"kubernetes\" cannot list resource \"pods\" in API group \"\" at the cluster scope"
"message": "pservices is forbid...
				1.准备配置文件
[root@k8s-master1 ~]# wget https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended/kubernetes-dashboard.yaml
--2019-04-23 11:11:25-- https://raw.githubuserconten...
场景一、限制 kubectl 命令
当集群部署完成之后，使用 kubectl 命令能够控制整个集群，这是因为 ~/.kube/config 的凭证权限足够高。我们不能直接分发该凭证，应该创建新的碰正限制访问权限。
第一步、检查 RBA
				优先级导致不公平，抢占是强盗行为，受害者莫名奇妙。此特性增加系统复杂性并带来额外不稳定因素。如果资源紧张，首先应该扩容，硬件很便宜，应该禁用优先级特性。
Pod优先级指明pod的相对重要程度。在1.9之前的版本中，如果pod因为资源问题无法调度，则kubernetes尝试抢占低优先级pod资源，将它们排挤掉，为高优先级pod提供运行条件。
在1.9及之后的版本中，pod优先级会影响pod的调度...

k8s的RBAC

RBAC相关对象

创建一个只能访问固定namespace的的 hx 用户

1.新创建一个用户凭证

2.创建角色权限绑定

创建一个只能访问固定namespace的的 `hx` 用户