Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I'm running kubernetes v1.11.5 and I'm installing helm with a tiller deployment for each namespace. Let's focus on a single namespace. This is the tiller service account configuration:

apiVersion: v1 kind: ServiceAccount metadata: name: tiller namespace: marketplace-int kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: tiller-manager namespace: marketplace-int rules: - apiGroups: - extensions - apps - rbac.authorization.k8s.io - roles.rbac.authorization.k8s.io - authorization.k8s.io resources: ["*"] verbs: ["*"] kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: tiller-binding namespace: marketplace-int subjects: - kind: ServiceAccount name: tiller namespace: marketplace-int roleRef: kind: Role name: tiller-manager apiGroup: rbac.authorization.k8s.io

When I try to deploy a chart I get this error:

Error: release citest failed: roles.rbac.authorization.k8s.io "marketplace-int-role-ns-admin" is forbidden: 
attempt to grant extra privileges: 
[{[*] [*] [*] [] []}] user=&{system:serviceaccount:marketplace-int:tiller 5c6af739-1023-11e9-a245-0ab514dfdff4 
[system:serviceaccounts system:serviceaccounts:marketplace-int system:authenticated] map[]} 
ownerrules=[{[create] [authorization.k8s.io] [selfsubjectaccessreviews selfsubjectrulesreviews] [] []} 
{[get] [] [] [] [/api /api/* /apis /apis/* /healthz /openapi /openapi/* /swagger-2.0.0.pb-v1 /swagger.json /swaggerapi /swaggerapi/* /version /version/]} 
{[*] [ extensions apps rbac.authorization.k8s.io roles.rbac.authorization.k8s.io authorization.k8s.io] [*] [] []}] ruleResolutionErrors=[]

The error comes when trying to create rbac config for that namespace (with tiller sa):

# Source: marketplace/templates/role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    app: citest
    chart: marketplace-0.1.0
    heritage: Tiller
    release: citest
    namespace: marketplace-int
  name: marketplace-int-role-ns-admin
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]

The error message clearly says that the tiller service account doesn't have permission for roles.rbac.authorization.k8s.io but that permission is granted as showed previously.

$kubectl describe role tiller-manager
Name:         tiller-manager
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"rbac.authorization.k8s.io/v1","kind":"Role","metadata":{"annotations":{},"name":"tiller-manager","namespace":"marketplace-i...
PolicyRule:
  Resources                          Non-Resource URLs  Resource Names  Verbs
  ---------                          -----------------  --------------  -----
  *                                  []                 []              [*]
  *.apps                             []                 []              [*]
  *.authorization.k8s.io             []                 []              [*]
  *.extensions                       []                 []              [*]
  *.rbac.authorization.k8s.io        []                 []              [*]
  *.roles.rbac.authorization.k8s.io  []                 []              [*]

Honestly, I don't fully understand the error message to check if the ownerrules are fine and I'm trying to find out what does it means this kind of messages that seems to be related with the role description: {[*] [*] [*] [] []}

Any clue about what permissions I am missing?

This is due to permission escalation prevention in RBAC. See https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping for details.

Permission to create a role object is necessary, but not sufficient.

A user can only create/update a role if at least one of the following things is true:

  • they already have all the permissions contained in the role, at the same scope as the object being modified (cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role). In your case, that would mean the user attempting to create the role must already have apiGroups=*, resources=*, verbs=* permissions within the namespace where it is attempting to create the role. You can grant this by granting the cluster-admin clusterrole to the serviceaccount within that namespace with a rolebinding.

  • they are given explicit permission to perform the "escalate" verb on the roles or clusterroles resource in the rbac.authorization.k8s.io API group (Kubernetes 1.12 and newer)

  • with kubectl create clusterrolebinding tiller-clusteradmin-mkp-int --clusterrole=cluster-admin --serviceaccount=marketplace-int:tiller works fine. If I have three tiller deployments, all of them will have permissions to create anything at cluster level? If there is any error configuring CI, that could cause to use tiller inside namespace 1 to deploy into namespace2? – RuBiCK Jan 6, 2019 at 17:44

    First you need to give cluster-admin permission to tiller SA.

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: tiller
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cluster-admin
    subjects:
      - kind: ServiceAccount
        name: tiller
        namespace: marketplace-int
    

    Once you assign cluster-admin role to tiller SA, you should be able to create the role.

    But I don’t want to give cluster level permissions. That’s the reason I’m creating a tiller per namespace. Let’s forget tiller. With a SA with the permissions listed in my question I can’t create that role for an authorized namespace. Is that correct? – RuBiCK Jan 4, 2019 at 21:06

    You should be able to create roles within that same namespace. I tried this myself, meaning creating a role using the same role that you described in your question and I was able to do it successfully (I changed my namespace to test), so I don't think it's related to your role definition but how tiller is using that specific service account to create new things.

    # With an cluster-admin cluster role
    $ echo '---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: tiller
      namespace: test
    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: tiller-manager
      namespace: test
    rules:
    - apiGroups:
      - extensions
      - apps
      - rbac.authorization.k8s.io
      - roles.rbac.authorization.k8s.io
      - authorization.k8s.io
      resources: ["*"]
      verbs: ["*"]
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: tiller-binding
      namespace: test
    subjects:
    - kind: ServiceAccount
      name: tiller
      namespace: test
    roleRef:
      kind: Role
      name: tiller-manager
      apiGroup: rbac.authorization.k8s.io' | kubectl apply -f -
    

    Then:

    $ kubectl -n test describe secret tiller-token-xxxxx
    Name:         tiller-token-xxxx
    Namespace:    test
    Labels:       <none>
    Annotations:  kubernetes.io/service-account.name: tiller
    Type:  kubernetes.io/service-account-token
    ca.crt:     1025 bytes
    namespace:  4 bytes
    token:      <my-token>
    

    Then:

    $ mv ~/.kube ~/.kube.tmp
    $ echo 'apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      labels:
        app: citest
        chart: marketplace-0.1.0
        heritage: Tiller
        release: citest
      namespace: test
      name: marketplace-int-role-ns-admin
    rules:
      - apiGroups: ["*"]
        resources: ["*"]
        verbs: ["*"]' | kubectl -n test --token <your-token> --server <your-kubeapiserver> apply -f - 
    role.rbac.authorization.k8s.io/marketplace-int-role-ns-admin created
            

    Thanks for contributing an answer to Stack Overflow!

    • Please be sure to answer the question. Provide details and share your research!

    But avoid

    • Asking for help, clarification, or responding to other answers.
    • Making statements based on opinion; back them up with references or personal experience.

    To learn more, see our tips on writing great answers.