DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Related

  • GitOps: Flux vs Argo CD
  • The Production-Ready Kubernetes Service Checklist
  • Optimizing Prometheus Queries With PromQL
  • Demystifying Kubernetes in 5 Minutes

Trending

  • Mastering Advanced Aggregations in Spark SQL
  • Infrastructure as Code (IaC) Beyond the Basics
  • The Future of Java and AI: Coding in 2025
  • Memory Leak Due to Time-Taking finalize() Method
  1. DZone
  2. Software Design and Architecture
  3. Cloud Architecture
  4. What Is Kubernetes RBAC and Why Do You Need It?

What Is Kubernetes RBAC and Why Do You Need It?

Understanding Kubernetes RBAC and its implementation is crucial to practice multitenancy in organizations.

By 
Debasree Panda user avatar
Debasree Panda
·
Sep. 20, 23 · Analysis
Likes (8)
Comment
Save
Tweet
Share
3.9K Views

Join the DZone community and get the full member experience.

Join For Free

What Is Kubernetes RBAC?

Often, when organizations start their Kubernetes journey, they look up to implementing least privilege roles and proper authorization to secure their infrastructure. That’s where Kubernetes RBAC is implemented to secure Kubernetes resources such as sensitive data, including deployment details, persistent storage settings, and secrets. Kubernetes RBAC provides the ability to control who can access each API resource with what kind of access. You can use RBAC for both human (individual or group) and non-human users (service accounts) to define their types of access to various Kubernetes resources. 

For example, there are three different environments, Dev, Staging, and Production, which have to be given access to the team, such as developers, DevOps, SREs, App owners, and product managers.

Practicing RBAC in Kubernetes for various environment


Before we get started, we would like to stress that we will treat users and service accounts as the same, from a level of abstraction- every request, either from a user or a service account, is finally an HTTP request. Yes, we understand users and service accounts  (for non-human users) are different in nature in Kubernetes.

How To Enable Kubernetes RBAC

One can enable RBAC in Kubernetes by starting the API server with an authorization-mode flag on. Kubernetes resources used to apply RBAC on users are: 

  • Role, 
  • ClusterRole,
  • RoleBinding,
  • ClusterRoleBinding

Service Account

To manage users, Kubernetes provides an authentication mechanism, but it is usually advisable to integrate Kubernetes with your enterprise identity management for users such as Active Directory or LDAP. When it comes to non-human users (or machines or services) in a Kubernetes cluster, the concept of a Service Account comes into the picture. 

For example, The Kubernetes resources need to be accessed by a CD application such as Spinnaker or Argo to deploy applications, or one pod of service A needs to talk to another pod of service B. In such cases, a Service Account is used to create an account of a non-human user and specify the required authorization (using RoleBinding or ClusterRoleBinding).

You can create a Service Account by creating a yaml like the below:

YAML
 
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-sa
spec: 
  automountServiceAccountToken: false


And then apply it. 

Shell
 
$ kubectl apply -f nginx-sa.yaml
serviceaccount/nginx-sa created


And now you have to ServiceAccount for pods in the Deployments resource.

YAML
 
kind: Deployment
metadata:
  name: nginx1
  labels:
    app: nginx1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      serviceAccountName: nginx-sa
      containers:
      - name: nginx1
        image: nginx
        ports:
        - containerPort: 80


In case you don’t specify about serviceAccountName in the Deployment resources, then the pods will belong to the default Service Account. Note there is a default Service Account for each namespace and one for clusters. All the default authorization policies as per the default Service Account will be applied to the pods where Service Account info is not mentioned. 

In the next section, we will see how to assign various permissions to a Service Account using RoleBinding and ClusterRoleBinding. 

Role and ClusterRole

Role and ClusterRole are the Kubernetes resources used to define the list of actions a user can perform within a namespace or a cluster, respectively. 

In Kubernetes, the actors, such as users, groups, or ServiceAccount, are called subjects. A subject's actions, such as create, read, write, update, and delete, are called verbs. 

YAML
 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-only
  namespace: dev-namespace
rules:
- apiGroups:
  - ""
  resources: ["*"]
  verbs:
  - get
  - list
  - watch


In the above Role resource, we have specified that the read-only role is only applicable to the deb-ns namespace and to all the resources inside the namespace. Any ServiceAccount or users that would be bound to the read-only role can take these actions- get, list, and watch. 

Similarly, the ClusterRole resource will allow you to create roles pertinent to clusters. An example is given below:

YAML
 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: chief-role
rules:
- apiGroups:
- ""
resources: ["*"]
verbs:
- get
- list
- watch
- create
- update
- patch
- delete


Any user/group/ServiceAccount bound to the chief-role will be able to take any action in the cluster. 

In the next section, we will see how to grant roles to subjects using RoleBinding and ClusterRoleBinding.  

Also, note Kubernetes allows you to configure custom roles using Role resources or use default user-facing roles such as the following:

  • Cluster-admin: For cluster administrators, Kubernetes provides a superuser Role. The Cluster admin can perform any action on any resource in a cluster. One can use a superuser in a ClusterRoleBinding to grant full control over every resource in the cluster (and in all namespaces) or in a RoleBinding to grant full control over every resource in the respective namespace.
  • Admin: Kubernetes provides an admin Role to permit unlimited read/write access to resources within a namespace. admin role can create roles and role bindings within a particular namespace. It does not permit write access to the namespace itself. This can be used in the RoleBinding resource. 
  • Edit: edit role grants read/write access within a given Kubernetes namespace. It cannot view or modify roles or role bindings. 
  • View: view role allows read-only access within a given namespace. It does not allow viewing or modifying of roles or role bindings. 

RoleBinding and ClusterRoleBinding 

To apply the Role to a subject (user/group/ServiceAccount), you must define a RoleBinding. This will give the user the least privileged access to required resources within the namespace with the permissions defined in the Role configuration. 

YAML
 
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: Role-binding-dev
roleRef:
  kind: Role
  name: read-only #The role name you defined in the Role configuration
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
  name: Roy #The name of the user to give the role to
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: nginx-sa#The name of the ServiceAccount to give the role to
  apiGroup: rbac.authorization.k8s.io


Similarly, ClusterRoleBinding resources can be created to define the Role of users. Note we have used the default superuser ClusterRole reference provided by Kubernetes instead of using our custom role. This can be applied to cluster administrators. 

YAML
 
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
 name: superuser-binding
roleRef:
 kind: ClusterRole
 name: superuser
 apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
 name: Aditi
 apiGroup: rbac.authorization.k8s.io


Benefits of Kubernetes RBAC

The advantage of Kubernetes RBAC is it allows you to “natively” implement the least privileges to various users and machines in your cluster. The key benefits are:

Proper Authorization 

With the least privileges to various users and Service Accounts to Kubernetes resources, DevOps and architects can implement one of the main pillars of zero trust. Organizations can reduce the risk of data breaches and data leakage and also avoid internal employees accidentally deleting or manipulating any critical resources. 

Separation of Duties

Applying RBAC on Kubernetes resources will always facilitate separation of duties of users such as developers, DevOps, testers, SREs, etc., in an organization. For e.g., for creating/deleting a new resource in a dev environment, developers should not depend on admin. Similarly, deploying new applications into test servers and deleting the pods after testing should not be a bottleneck for DevOps or testers. Applying authorization and permissions to users such as developers and CI/CD deployment agents into respective workspaces (say namespaces or clusters) will decrease the dependencies and cut the slack. 

100% Adherence to Compliance

Many industry regulations, such as HIPAA, GDPR, SOX, etc., demand tight authentication and authorization mechanisms in the software field. Using Kubernetes RBAC, DevOps, and architects can quickly implement RBAC into their Kubernetes cluster and improve their posture to adhere to those standards. 

Disadvantages of Kubernetes RBAC

For small and medium enterprises, using Kubernetes RBAC is justified, but it is not advisable to use Kubernetes RBAC for the below reasons:

  • There can be many users and machines, and applying Kubernetes RBAC can be cumbersome to implement and maintain. 
  • Granular visibility of who performed what operation is difficult. For example, large enterprises would require information such as violations or malicious attempts against RBAC permissions.  
Contextual design Kubernetes YAML cluster dev pods

Published at DZone with permission of Debasree Panda. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • GitOps: Flux vs Argo CD
  • The Production-Ready Kubernetes Service Checklist
  • Optimizing Prometheus Queries With PromQL
  • Demystifying Kubernetes in 5 Minutes

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!