Kubernetes service account security - kubernetes

Question

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

Answer 1

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.

Answer 2

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.