As passing through k8s documentation I bumped into one thing that is quite unclear.
From the following link we see that one of the main differences between Role and ClusterRole would be that in the ClusterRole you can specify access to cluster-wide resources (nodes, psp) while in the Role you cannot do that as those are namespaced scoped resources.
Now, i have bumped into lots of examples where some cluster-wide resources appears to be added in the Role manifest and it seems to work. Let's take the following example for PSP where from the api-resources we can see that these are non-namespaced resources.
kubectl api-resources | grep -i psp
podsecuritypolicies psp policy false PodSecurityPolicy
Also, checking out the psp k8s docs we can see that both Role and ClusterRole can be created...
Same situation with nodes/certificatesigningrequests.
I have tested it out and deployed a service account, Role and RoleBinding and they throw:
Warning: resource 'nodes' is not namespace scoped
yes
Any idea about this issue?
you can not manage a resource that is not part of any namespace with inherently namespaced Role/RoleBinding. Those can only be managed by ClusterRole/ClusterRoleBindings
Related
I am trying to understand security implication of granting kubernetes serviceaccount permission to perform deployments, service creation, etc. The role is clusterrole with namespaced rolebinding.
Use case are using service account to automate/orchestrate some tasks inside cluster. Version is 1.16
Service account can used to grant different access level to different purpose. for developer ClusterRole need to list, get and watch resources but not delete. but Admin can delete and create resources.
If you are developing K8 operator, operator need to communicate with cluster for create, update and delete resources then operator need service with ClusterRoleBinding of all verbs. so that operator can perform all operation on resources. but not good practice to assign full permission to regular deployment.
Let me discuss about this.
According to the docs.
A Role always _sets permissions within a particular namespace__; when you create a Role, you have to specify the namespace it belongs in
ClusterRole, by contrast, is a non-namespaced resource. The resources have different names (Role and ClusterRole) because a Kubernetes object always has to be either namespaced or not namespaced; it can't be both.
A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.
If you want to define a role within a namespace, use a Role; if you want to define a role cluster-wide, use a ClusterRole.
A RoleBinding may reference any Role in the same namespace. Alternatively, a RoleBinding can reference a ClusterRole and bind that ClusterRole to the namespace of the RoleBinding. If you want to bind a ClusterRole to all the namespaces in your cluster, you use a ClusterRoleBinding.
So answering your question - handling ClusterRoles it could be definitively security risk.
The best solution is to grant as minimal permissions as possible.
Grant a role to an application-specific service account (best practice)
Grant a role to the "default" service account in a namespace
Grant a role to all service accounts in a namespace
Grant a limited role to all service accounts cluster-wide (discouraged)
Grant super-user access to all service accounts cluster-wide (strongly discouraged)
There is no one answer for this question because you need to plan and test action/permissions between your application/deployment and kubernetes API. F.e at namesapaced or non namesapced resources, inside one namespace or across the entire cluster.
In you example you can simply use Role/Rolebinding if you are working inside the same namespace. You can use ClusterRole/Rolebinding and extend permissions by additional RoleBinding allowing the ServiceAccount to create new k8s objects into another namespace.
Assuming we are talking about ServiceAccount for deployment, here you can find good advice for "RBAC in Deployments: A use case"
If you create ServiceAccount for your deployment and create appropriate Role/ClusterRole and Rolebinding/ClusterRoleBinding:
you can perform:
kubectl can-i get secrets --as=system:serviceaccount:[namespace]:[service_account_name] -n [target_namespace]
For testing please take a look also at Access Clusters Using the Kubernetes API.
This command will show you if particular ServiceAccount (defined by subject in Rolebinding/ClusterRolebinding) has permissions (defined by verbs in Role/ClusteRole) to get secrets (defined by resources Role/ClusterRole) in specified namespace.
Following this approach you can verify if your deployment has enough permissions to perform all required operation against Kubernetes API.
While working with RBAC in Kubernetes you should consider mentioned below topics:
Have multiple users with different properties, establishing a proper authentication mechanism.
Have full control over which operations each user or group of users can execute.
Have full control over which operations each process inside a pod can execute.
Limit the visibility of certain resources of namespaces.
I have bunch of users. Every user should be able to create/change/delete substances in namespaces like *-stage. Namespaces can be added or removed dynamically. I can create ServiceAccount in every namespace and grant privileges.
I created pod in k8s and install kubectl and ssh into it. So every user has access to this pod and can use kubectl. I know that I can mount ServiceAccount secrets to pod. As far as I have different ServiceAccounts for every namespace I don't know how to grant privileges to all *-stage namespaces for every user. I don't want to create cluster-admin ClusterRoleBinding for ServiceAccount, cause users should be able to modify only *-stage namespaces. Can you help me please?
I am posting a community wiki answer based on OP's solution for better visibility:
Actually, I have already solved problem. I create ["*"] role in every
*-stage namespace and bind it to ServiceAccount. Then I mount ServiceAccount to kubectl pod which is available over ssh. So every
user has unlimited access to *-stage namespaces.
Also I am adding links for the official docs regarding ServiceAccount and role-based access control as a supplement.
What is the difference between RoleBinding and ClusterRoleBinding?
And what are the usages of them?
A rolebinding is namespace scoped and clusterrolebinding is cluster scoped i.e across all namespace.
ClusterRoles and ClusterRoleBindings are useful in the following cases:
Give permissions for non-namespaced resources like nodes
Give permissions for resources in all the namespaces of a cluster
Give permissions for non-resource endpoints like /healthz
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.
Please refer the Kubernetes documentation here
A Role always sets permissions within a particular namespace; when you create a Role, you have to specify the namespace it belongs in.
ClusterRole, by contrast, is a non-namespaced resource. The resources
have different names (Role and ClusterRole) because a Kubernetes
object always has to be either namespaced or not namespaced; it can’t
be both.
The Cluster variants apply to every namespace. The others only to the namespace they are in.
I have secrets in one namespace added to a Service Account.
If you then ClusterRoleBind this ServiceAccount, will the ServiceAccount then be usable in all namespaces?
You can not use a service account which is contained in namespace from any other namespace. When you give a cluster role to a service account the service account gets permission to do operations defined in the ClusterRole across all namespaces but it's still usable only from the namespace where it's created.
No, service accounts are namespaced and can only be automatically used from within one namespace.
I'm trying to connect my k8s cluster to my ceph cluster with this manual:
https://akomljen.com/using-existing-ceph-cluster-for-kubernetes-persistent-storage/
I want to deploy rbd-provision pods into kube-system namespace like this https://paste.ee/p/C1pB4
After deploying pvc I get errors because my pvc is in default namespace. Can I do with that anything? I read docs and if I'm right I can't use ServiceAccount with 2 ns, or can?
No. Service account is namespaced object and it is limited to particular namespace only
Service accounts can be granted permissions in another namespace.
For example, within the namespace "acme", grant the permissions in the view ClusterRole to the service account in the namespace "acme" named "myapp" :
kubectl create rolebinding myapp-view-binding \
--clusterrole=view --serviceaccount=acme:myapp \
--namespace=acme