I am planning to deploy review-apps to kubernetes using namespaces. That is, my CI generates a random ID, I build a namespace from this like review-app-xxx and inside I'm deploying several helm charts.
How can I easily give access to all those namespaces to a group of people ?
Concrete example: assume I have several of those namespaces
review-app-aaaa
review-app-bbbb
review-app-cccc
What is the most simple way to give full access to those namespaces for a user belonging to group tech:dev ?
EDIT:
The non-dry way to think about it is to have one roleBinding per namespace like this
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: namespace-full-access-cluster-role
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: full-access-staging-namespace-for-devs
namespace: review-app-aaaa
subjects:
- kind: Group
name: devs
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: namespace-full-access-cluster-role
apiGroup: rbac.authorization.k8s.io
but is there a way to dry this ?
Related
I followed all the instructions from here : https://console.cloud.google.com/kubernetes/clusters/details/us-central1-c/myapp/details?project=plenary-axon-332219&pli=1
So far I can log in successfully, but I cannot list any pods.
I tried checking different formats for the cluster role binding but still no difference
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: people-who-view-secrets
subjects:
- kind: User
name: Issuer_URI#email
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-viewer
apiGroup: rbac.authorization.k8s.io
Has anyone seen this?
You need to add resources to manipulate
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: secret-viewer
rules:
- apiGroups: [""]
# The resource type for which access is granted
resources: ["secrets", "pods"] #here or namespaces , nodes
# The permissions granted by the ClusterRole
verbs: ["get", "watch", "list"]
I want to allow a ServiceAccount in namespace A to access a resource in namespace B.
To achieve this I connect the ServiceAccount to a ClusterRole via a ClusterRoleBinding.
The documentation says I can "use a ClusterRole to [1.] define permissions on namespaced resources and be granted within individual namespace(s)"
But looking through the K8s documentation I can't find a way how to create a ClusterRole with namespaced resources. How can I achieve this?
...how to create a ClusterRole with namespaced resources...
Read further down a bit:
A ClusterRole can be used to grant the same permissions as a Role.
Because ClusterRoles are cluster-scoped. You can also use them to
grant access to:
...
namespaced resources (like Pods), across all namespaces
ClusterRole won't help you to restraint access to a single namespaced object. You can however use RoleBinding to reference a ClusterRole and restraint access to the object in the namespace of the RoleBinding.
I believe you need to create clusterrole not role.
example:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["rolebindings"]
verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterroles"]
verbs: ["bind"]
# omit resourceNames to allow binding any ClusterRole
resourceNames: ["admin","edit","view"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: role-grantor-binding
namespace: user-1-namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: user-1
above example is from this link.
I find both other answers a little confusing, hopefully this is clearer.
You did the right thing in creating a ClusterRole, but you want to bind it using a namespaced RoleBinding, not a ClusterRoleBinding.
Example using your examples. Notice how the RoleBinding is in the B namespace, giving A's ServiceAccount the permissions defined in the ClusterRole, but limited to the B namespace.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: what-a-is-allowed-to-do-in-b
rules:
- apiGroups: [""]
resources: ["pods", "deployments"] # etc
verbs: ["get", "list", "create"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-app
namespace: namespace-a
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: what-a-is-allowed-to-do-in-b
namespace: namespace-b
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: what-a-is-allowed-to-do-in-b
subjects:
- kind: ServiceAccount
name: my-app
namespace: namespace-a
Notes:
You have to use the ClusterRole because you can't get outside your own namespace without one. By using a RoleBinding, which is namespaced, you can then limit the access to the scope of the namespace of that RoleBinding.
I have a service account, in the default namespace, with a clusterRoleBinding to a clusterRole that can observe jobs.
I wish to use this service account in any namespace rather than have to define a new service account in each new namespace. The service account is used by an init container to check a job has completed before allowing deployment to continue.
Not sure what extra info I need to provide but will do so on request.
You can simply reference a ServiceAccount from another namespace in the RoleBinding:
For example, below is sample use to refer the service account in one namespace to another for just reading the pods.
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
name: pod-reader
namespace: ns2
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: pod-reader-from-ns1
namespace: ns2
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pod-reader
subjects:
- kind: ServiceAccount
name: ns1-service-account
namespace: ns1
I know that you can assign multiple roles to one service account when you want your service account to access multiple namespaces, but what I wonder is how it will behave when you assign to it more than one clusterrole which is cluster scoped. From my perspective, I think that it will choose one of them but I'm not sure.
Permissions are purely additive (there are no "deny" rules).
reference
This is the golden 🥇 rule here that we must memorize for kubernetes RBAC roles.
"purely additive" means always ALLOW no revoke.
Hence, "purely additive" means there are neither conflicts nor order of precedence.
It's not like AWS IAM policies where we have DENY and ALLOW .. That's time, we have to know which one has the highest order of precedence.
It's not like also subnets ACL , where we have DENY and ALLOW .. That's time, we need to assign number for each rule. This number will decide the order of precedence.
Example:
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: node-reader
rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "watch", "list"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: pod-reader
subjects:
- kind: User
name: abdennour
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: pod-reader
apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: node-reader
subjects:
- kind: User
name: abdennour
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: node-reader
apiGroup: rbac.authorization.k8s.io
as you can see in this example, the user Abdennour should have at the end the wide read access for both: nodes & pods.
If you assign a service account multiple clusterroles using multiple role or clusterrole bindings the service account will have permission which is aggregate of all of those cluster roles meaning all the verbs on all the resources defined in those clusterroles.
Trying to write my first set of RBAC roles. So trying to figure out the best way to have 2 roles for multiple namespaced components.
Admin-role (RW for 3 namespaces say default, ns1 & ns2)
user-role (Read-only for 3 namespaces say default, ns1 & ns2)
Was thinking will need a service account with 2 clusterRoles for admin/user
apiVersion: rbac.authorization.k8s.io/v1
kind: ServiceAccount
metadata:
name: sa
namespace: default
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: admin-master
rules:
- apiGroups:
- batch
resources:
- pods
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: user-master
rules:
- apiGroups:
- batch
resources:
- pods
verbs:
- get
- list
- watch
Then make use of roleBindings:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: admin-rw
namespace: ns1
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: admin-master
subjects:
- kind: ServiceAccount
name: sa
namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: user-readonly
namespace: ns1
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: user-master
subjects:
- kind: ServiceAccount
name: sa
namespace: default
But not sure how the best way to bind roles admin-rw/user-readonly with namespace 2 (ns2)?
Roles are scoped, either bound to an specific namespace or cluster-wide. For namespace-scoped roles, you can just simply deploy the same role in multiple namespaces.
The idea behind this is to have partitioned permissions in the cluster, although it implies more administrative effort but is a safer practice.
Additionally, in your definition, you're trying to bind permissions to specific namespaces, however, you're using ClusterRole which is a cluster-scoped resource. You might want to change that to Role if you want namespace-scoped permissions.
You might find this CNCF article useful on this matter.
This answer https://stackoverflow.com/a/57729174/2660452 is wrong.
ClusterRole and Role defines which resources you can operated. if your role need to manage resources in multiple namespaces, you need to use ClusterRole
and RoleBinding defines which namespace your account will be granted.
here is the example from official document: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-example
A RoleBinding can also reference a ClusterRole to grant the permissions defined in that ClusterRole to resources inside the RoleBinding's namespace. This kind of reference lets you define a set of common roles across your cluster, then reuse them within multiple namespaces.
For instance, even though the following RoleBinding refers to a ClusterRole, "dave" (the subject, case sensitive) will only be able to read Secrets in the "development" namespace, because the RoleBinding's namespace (in its metadata) is "development".
apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "dave" to read secrets in the "development" namespace.
# You need to already have a ClusterRole named "secret-reader".
kind: RoleBinding
metadata:
name: read-secrets
#
# The namespace of the RoleBinding determines where the permissions are granted.
# This only grants permissions within the "development" namespace.
namespace: development
subjects:
- kind: User
name: dave # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io