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?
We will also assume that RBAC has been enabled in your cluster through the --authorization-mode=RBAC option in your Kubernetes API server. You can check this by executing the command kubectl api-versions ; if RBAC is enabled you should see the API version . rbac.authorization.k8s.io/v1 .
Dashboard. Go to Dashboard > Applications > APIs and click the name of the API to view. Scroll to RBAC Settings and enable the Enable RBAC toggle. To include all permissions assigned to the user in the permissions claim of the access token, enable the Add Permissions in the Access Token toggle, and click Save.
RBAC in Kubernetes is the mechanism that enables you to configure fine-grained and specific sets of permissions that define how a given user, or group of users, can interact with any Kubernetes object in cluster, or in a specific Namespace of cluster.
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)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With