Kubernetes 检查 serviceaccount 权限答案

【问题标题】：Kubernetes check serviceaccount permissionsKubernetes 检查 serviceaccount 权限
【发布时间】：2019-07-20 05:30:44
【问题描述】：

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

注意：

ServiceMonitor 是 Prometheus Operator 定义的 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资源？

【问题讨论】：

标签： kubernetes kubectl

【解决方案1】：

在尝试了很多事情并在整个宇宙中搜索之后，我终于找到了this blogpost about Securing your cluster with RBAC and 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 帐户的问题，我必须在monitoring.coreos.com apiGroup 中添加对servicemonitors 资源的权限。更改后，上述命令返回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:
    - '*'

【讨论】：

kubectl auth can-i 对这类问题非常有用的命令?谢谢

【解决方案2】：

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

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

【讨论】：

【解决方案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 说是的事实让我认为我的角色绑定是正确的语法，但它是错误的）

这是正确的：

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 命令的语法有疑问，这里有一个快速查找的方法：

kubernetes.io/docs
搜索“rbac”
control+f "kubectl create rolebinding" 在页面上获取正确语法示例。

【讨论】：