Question

通过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资源？

Answer 1

在尝试着迷失一切并在整个Google上进行谷歌搜索之后，我终于找到了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帐户的问题，我必须在servicemonitors apiGroup中为monitoring.coreos.com资源添加权限。更改之后，上述命令最终返回了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

注意：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" 以获取正确语法的示例。

Kubernetes检查服务帐户权限

2 个答案: