Kubernetes检查服务帐户权限

Question

通过Helm Chart部署服务时，安装失败，因为tiller不允许serviceaccount创建ServiceMonitor资源。

注意：

• ServiceMonitor 是Prometheus操作员定义的CRD，用于自动获取Pod中正在运行的容器的指标。
• Helm Tiller安装在单个名称空间中，并且已使用Role和RoleBinding设置了RBAC。

我想验证tiller服务帐户的权限。
kubectl使用该auth can-i命令，此类查询（请参见下文）始终返回no。

• kubectl auth can-i list deployment --as=tiller
• kubectl auth can-i list deployment --as=staging:tiller

检查服务帐户权限的正确方法是什么？
如何启用该tiller帐户创建ServiceMonitor资源？

Answer 1

在尝试了很多事情并在整个Google谷歌搜索之后，我终于找到了这篇关于使用RBAC和PSP保护集群安全的博客文章，其中提供了一个示例来检查服务帐户的访问。

正确的命令是：
kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<namespace>:<serviceaccountname> [-n <namespace>]

要检查该tiller帐户是否有权创建ServiceMonitor对象：
kubectl auth can-i create servicemonitor --as=system:serviceaccount:staging:tiller -n staging

注意：要解决我的tiller帐户问题，我必须servicemonitors在monitoring.coreos.comapiGroup中为资源添加权限。更改之后，上述命令yes（最终）返回了，并且我们的Helm Chart安装成功。

更新的tiller-manager角色：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: tiller-manager
  labels:
    org: ipos
    app: tiller
  annotations:
    description: "Role to give Tiller appropriate access in namespace"
    ref: "https://docs.helm.sh/using_helm/#example-deploy-tiller-in-a-namespace-restricted-to-deploying-resources-only-in-that-namespace"
rules:
- apiGroups: ["", "batch", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups:
    - monitoring.coreos.com
  resources:
    - servicemonitors
  verbs:
    - '*'

Answer 2

这显示您对服务帐户拥有的权限prom-stack-grafana：例如

kubectl -n 监控身份验证 can-i --list --as=system:serviceaccount:monitoring:prom-stack-grafana

Answer 3

注意：kubectl auth can-i命令有一个边缘情况/陷阱/错误，以避免值得注意。
基本上，可以使用与服务帐户类似的语法来命名用户，并且可以欺骗它。
它让我绊倒了很长一段时间，所以我想分享它。

alias k=kubectl
k create ns dev 
k create role devr --resource=pods --verb=get -n=dev 
k create rolebinding devrb --role=devr --user=system:serviceaccount:dev:default -n=dev # wrong syntax 
k auth can-i get pods -n=dev --as=system:serviceaccount:dev:default  # right syntax
# yes 

（事实上​​， k auth can-i 说 yes 让我认为我的角色绑定是正确的语法，但这是错误的）

这是对的：

k delete ns dev
k create ns dev 
k create role devr --resource=pods --verb=get -n=dev 
k create rolebinding devrb --role=devr --serviceaccount=dev:default -n=dev # right syntax 
k auth can-i get pods -n=dev --as=system:serviceaccount:dev:default  # right syntax
# yes

这是错误的直观证据：

k create rolebinding devrb1 --role=devr --user=system:serviceaccount:dev:default -n=dev --dry-run=client -o yaml | grep subjects -A 4
# subjects:
# - apiGroup: rbac.authorization.k8s.io
#   kind: User
#   name: system:serviceaccount:dev:default

k create rolebinding devrb2 --role=devr --serviceaccount=dev:default -n=dev --dry-run=client -o yaml | grep subjects -A 4
# subjects:
# - kind: ServiceAccount
#   name: default
#   namespace: dev

如果对命令式 rbac 命令的语法有疑问，可以通过以下方法快速查找：

1. kubernetes.io/docs
2. 搜索“rbac”
3. 页面上的 control+f“kubectl 创建角色绑定”以获取正确语法的示例。