🚀 AI Generated Incident Summaries Feature is Now Live! See it in action! 🎉
Blog
Kubernetes
Demystifying Kubernetes RBAC

Demystifying Kubernetes RBAC

September 27, 2021
Demystifying Kubernetes RBAC
In This Article:
Our Products
On-Call Management
Incident Response
Continuous Learning
Workflow Automation

With the inception of Kubernetes as an open-source project in 2015, it became the new standard of managing software in the cloud. Modern applications are moving from monolithic architecture to microservice architecture and containerization. When managing multiple microservice applications, managing the number of containers will be a challenging task. To overcome this, we can use Kubernetes for container orchestration. Kubernetes will manage the entire lifecycle of individual containers, spinning up and shutting down resources as needed. If a container shuts down unexpectedly, the orchestration platform will react by launching another container in its place.

To give you an idea, these are some of well known features of Kubernetes:

  • Automated Scheduling
  • Self-Healing Capabilities
  • Automated rollouts & rollback
  • Horizontal Scaling & Load Balancing
  • Environment consistency for development, testing, and production
  • Infrastructure loosely coupled to all component can act as a separate unit
  • Provides a higher density of resource utilization
  • Offers enterprise-ready features
  • Application-centric management
  • Auto-scalable infrastructure
  • Predictable infrastructure

Overview of Role-Based Access Control (RBAC)

RBAC is a security measurement, designed to restrict access to valuable resources based on the roles assigned to the entity(user, group, or service account). We can see RBAC in modern applications and cloud providers. Let's identify why RBAC is important for us.

As an example, let's assume your application doesn't use any RBAC system. An administrator uses his username and password to log in to the system and has full access to the system. In this case, if we add regular users, they will also have full permission in the system.

Why is Kubernetes RBAC Needed?

With the expansion of the Kubernetes environment, complexity grows, and role-based security becomes essential. Therefore, we need to divide the cluster into multiple namespaces and limit access from service accounts and users for each resource.

Not every user needs unrestricted access to the cluster to create, modify or delete resources. As the users and cluster resources increase, you will need to limit access to resources and allow relevant permissions required.

Looking at Kubernetes RBAC resources

Kubernetes have two kinds of roles for defining the action users can perform within the cluster. ClusterRole and Roles operate in Kubernetes within a cluster or namespace, respectively. In Kubernetes, you can use RBAC to assign roles to Kubernetes subjects(users, groups and service accounts) with RoleBindings and ClusterRoleBindings. Kubernetes allowed administrators to create custom roles including but not limited to built-in roles as follows:

  • Cluster-Admin: The "superuser" role of Kubernetes, this user can perform any action on any resource. We can use ClusterRoleBinding to grant cluster-wide full access or RoleBinding for namespace-wide full access.
  • Admin: Has unlimited read/write access to resources within a namespace. This role can be created with Role and RoleBindings with a specific namespace.
  • Edit: Provide full read/write access to the namespace. It can't view or modify Role or RoleBindings.
  • View: This role allows read-only access within the given namespace.

Service Accounts

Kubernetes Service Accounts are used for creating managed Kubernetes resources via Kubernetes API, meant to be used by Kubernetes entities such as Pods for authenticating Kubernetes API server or external services.

Role

A Role always sets permissions within a particular namespace; when you create a Role, you have to specify the namespace it belongs to. Following is an example of a YAML manifest for Kubernetes Role.

Note: The below commands were tested in Kubernetes v1.17

<p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/21a696af4e0dfab8cab3608c121a50ae.js</p>

RoleBinding

A RoleBinding 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 references the role granted. A RoleBinding grants permissions within a specific namespace. Following is an example of a YAML manifest for Kubernetes RoleBinding.

<p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/e283800da70e95b56a2f8a9d862f6cfe.js</p>

ClusterRole

ClusterRole is used to provide permissions to a non-namespaced resource. ClusterRoles have several uses. You can use a ClusterRole to:

  1. define permissions on namespaced resources and be granted within an individual namespace(s)
  2. define permissions on namespaced resources and be granted across all namespaces
  3. define permissions on cluster-scoped resources

To define a role within a namespace, use a Role; to define a cluster-wide role we use ClusterRole.

<p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/42d91cd2ffae004c76472ac6baf1ee54.js</p>

ClusterRoleBinding

ClusterRoleBinding is used to grant cluster-wide access to a user or set of users, which we call as subjects (users, groups or service accounts). Following is an example for ClusterRoleBinding:

<p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/6ab61e20d1ed8318136897b6a222dfe9.js</p>

Practical Use Case of Using RBACs

Role and RoleBinding

We can get started in simplest way by applying RBAC into Kubernetes using Role and RoleBinding.

Scenario - We have a service account name serviceAccount1 and need access to all the resources in the namespace app1.

<p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/811cd4c026961928bd7fafb70d713fa2.js</p>

Note: We assume the serviceAccount1 has already been created.

<p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/20ca297ebb4d0030b3053052642f0149.js</p>

In the above YAML role, we grant full access to all the resources within the namespace app1. As I mentioned previously, roles are namespaced, so we need to specify which namespace role is applied when creating a Role. Next, we look into RoleBinding.

<p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/ea78f538367c4f91eb00558d6deb405f.js</p>

From RoleBinding we bind the service account with the role we created previously. So now, the service account has only access to the resources inside the app1 namespace.

It's possible to bind a service account from a different namespace, so that the service account can access the resources in app1 namespace with the role attached to the RoleBinding.

ClusterRole and RoleBinding

ClusterRoles do not belong to any namespace. Therefore ClusterRoles does not scope to any single namespace. But if ClusterRole is linked with a service account via a RoleBinding, ClusterRole permissions are only applied to the namespace that RoleBinding has created.

<p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/f558ba9b858fb016acdc9d27b40e84a5.js</p>

ClusterRole and ClusterRoleBinding

ClusterRole is used to give permissions to cluster-wide resources. ClusterRole or ClusterRoleBinding does not belong to any namespace. Therefore the permissions assigned are cluster-wide. For example, a service account needs to access all the resources in the cluster. So we can use ClusterRoles and ClusterRoleBindings to grant him access to all persistent volumes in the cluster. Example of ClusterRole and ClusterRoleBinding are shown below:

<p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/f763538e7e550ce5362d84da26c6aa58.js</p>

Summary

With the above examples, we can understand the benefits and use cases of Kubernetes RBAC. Below is the summary of what we discussed:

  • Roles and RoleBindings must exist in the same namespace.
  • RoleBindings can exist in separate namespaces to service accounts.
  • RoleBindings can link cluster roles, but they only grant access to the namespace of the role binding.
  • ClusterRoleBindings link accounts to cluster roles and grant access across all resources.
  • ClusterRoleBindings can not reference roles.
Written By:
September 27, 2021
Kasun Rajapakse
Kasun Rajapakse
September 27, 2021
Kubernetes
DevOps
Share this blog:
In This Article:
Get reliability insights delivered straight to your inbox.
Get ready for the good stuff! No spam, no data sale and no promotion. Just the awesome content you signed up for.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
If you wish to unsubscribe, we won't hold it against you. Privacy policy.
Get reliability insights delivered straight to your inbox.
Get ready for the good stuff! No spam, no data sale and no promotion. Just the awesome content you signed up for.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
If you wish to unsubscribe, we won't hold it against you. Privacy policy.
Get the latest scoop on Reliability insights. Delivered straight to your inbox.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
If you wish to unsubscribe, we won't hold it against you. Privacy policy.
Squadcast is a leader in Incident Management on G2 Squadcast is a leader in Mid-Market IT Service Management (ITSM) Tools on G2 Squadcast is a leader in Americas IT Alerting on G2 Best IT Management Products 2024 Squadcast is a leader in Europe IT Alerting on G2 Squadcast is a leader in Enterprise Incident Management on G2 Users love Squadcast on G2
Squadcast is a leader in Incident Management on G2 Squadcast is a leader in Mid-Market IT Service Management (ITSM) Tools on G2 Squadcast is a leader in Americas IT Alerting on G2
Best IT Management Products 2024 Squadcast is a leader in Europe IT Alerting on G2 Squadcast is a leader in Enterprise Incident Management on G2
Users love Squadcast on G2
Copyright © Squadcast Inc. 2017-2024

Demystifying Kubernetes RBAC

Sep 27, 2021
Last Updated:
May 2, 2024
Share this post:
Demystifying Kubernetes RBAC

The more prominent and complex Kubernetes deployments become, the more important it is to define strict access controls and tighter security. In this blog, Kasun has explained how RBAC can be implemented in Kubernetes clusters to restrict user permissions to relevant resources only.

Table of Contents:

    With the inception of Kubernetes as an open-source project in 2015, it became the new standard of managing software in the cloud. Modern applications are moving from monolithic architecture to microservice architecture and containerization. When managing multiple microservice applications, managing the number of containers will be a challenging task. To overcome this, we can use Kubernetes for container orchestration. Kubernetes will manage the entire lifecycle of individual containers, spinning up and shutting down resources as needed. If a container shuts down unexpectedly, the orchestration platform will react by launching another container in its place.

    To give you an idea, these are some of well known features of Kubernetes:

    • Automated Scheduling
    • Self-Healing Capabilities
    • Automated rollouts & rollback
    • Horizontal Scaling & Load Balancing
    • Environment consistency for development, testing, and production
    • Infrastructure loosely coupled to all component can act as a separate unit
    • Provides a higher density of resource utilization
    • Offers enterprise-ready features
    • Application-centric management
    • Auto-scalable infrastructure
    • Predictable infrastructure

    Overview of Role-Based Access Control (RBAC)

    RBAC is a security measurement, designed to restrict access to valuable resources based on the roles assigned to the entity(user, group, or service account). We can see RBAC in modern applications and cloud providers. Let's identify why RBAC is important for us.

    As an example, let's assume your application doesn't use any RBAC system. An administrator uses his username and password to log in to the system and has full access to the system. In this case, if we add regular users, they will also have full permission in the system.

    Why is Kubernetes RBAC Needed?

    With the expansion of the Kubernetes environment, complexity grows, and role-based security becomes essential. Therefore, we need to divide the cluster into multiple namespaces and limit access from service accounts and users for each resource.

    Not every user needs unrestricted access to the cluster to create, modify or delete resources. As the users and cluster resources increase, you will need to limit access to resources and allow relevant permissions required.

    Looking at Kubernetes RBAC resources

    Kubernetes have two kinds of roles for defining the action users can perform within the cluster. ClusterRole and Roles operate in Kubernetes within a cluster or namespace, respectively. In Kubernetes, you can use RBAC to assign roles to Kubernetes subjects(users, groups and service accounts) with RoleBindings and ClusterRoleBindings. Kubernetes allowed administrators to create custom roles including but not limited to built-in roles as follows:

    • Cluster-Admin: The "superuser" role of Kubernetes, this user can perform any action on any resource. We can use ClusterRoleBinding to grant cluster-wide full access or RoleBinding for namespace-wide full access.
    • Admin: Has unlimited read/write access to resources within a namespace. This role can be created with Role and RoleBindings with a specific namespace.
    • Edit: Provide full read/write access to the namespace. It can't view or modify Role or RoleBindings.
    • View: This role allows read-only access within the given namespace.

    Service Accounts

    Kubernetes Service Accounts are used for creating managed Kubernetes resources via Kubernetes API, meant to be used by Kubernetes entities such as Pods for authenticating Kubernetes API server or external services.

    Role

    A Role always sets permissions within a particular namespace; when you create a Role, you have to specify the namespace it belongs to. Following is an example of a YAML manifest for Kubernetes Role.

    Note: The below commands were tested in Kubernetes v1.17

    <p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/21a696af4e0dfab8cab3608c121a50ae.js</p>

    RoleBinding

    A RoleBinding 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 references the role granted. A RoleBinding grants permissions within a specific namespace. Following is an example of a YAML manifest for Kubernetes RoleBinding.

    <p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/e283800da70e95b56a2f8a9d862f6cfe.js</p>

    ClusterRole

    ClusterRole is used to provide permissions to a non-namespaced resource. ClusterRoles have several uses. You can use a ClusterRole to:

    1. define permissions on namespaced resources and be granted within an individual namespace(s)
    2. define permissions on namespaced resources and be granted across all namespaces
    3. define permissions on cluster-scoped resources

    To define a role within a namespace, use a Role; to define a cluster-wide role we use ClusterRole.

    <p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/42d91cd2ffae004c76472ac6baf1ee54.js</p>

    ClusterRoleBinding

    ClusterRoleBinding is used to grant cluster-wide access to a user or set of users, which we call as subjects (users, groups or service accounts). Following is an example for ClusterRoleBinding:

    <p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/6ab61e20d1ed8318136897b6a222dfe9.js</p>

    Practical Use Case of Using RBACs

    Role and RoleBinding

    We can get started in simplest way by applying RBAC into Kubernetes using Role and RoleBinding.

    Scenario - We have a service account name serviceAccount1 and need access to all the resources in the namespace app1.

    <p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/811cd4c026961928bd7fafb70d713fa2.js</p>

    Note: We assume the serviceAccount1 has already been created.

    <p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/20ca297ebb4d0030b3053052642f0149.js</p>

    In the above YAML role, we grant full access to all the resources within the namespace app1. As I mentioned previously, roles are namespaced, so we need to specify which namespace role is applied when creating a Role. Next, we look into RoleBinding.

    <p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/ea78f538367c4f91eb00558d6deb405f.js</p>

    From RoleBinding we bind the service account with the role we created previously. So now, the service account has only access to the resources inside the app1 namespace.

    It's possible to bind a service account from a different namespace, so that the service account can access the resources in app1 namespace with the role attached to the RoleBinding.

    ClusterRole and RoleBinding

    ClusterRoles do not belong to any namespace. Therefore ClusterRoles does not scope to any single namespace. But if ClusterRole is linked with a service account via a RoleBinding, ClusterRole permissions are only applied to the namespace that RoleBinding has created.

    <p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/f558ba9b858fb016acdc9d27b40e84a5.js</p>

    ClusterRole and ClusterRoleBinding

    ClusterRole is used to give permissions to cluster-wide resources. ClusterRole or ClusterRoleBinding does not belong to any namespace. Therefore the permissions assigned are cluster-wide. For example, a service account needs to access all the resources in the cluster. So we can use ClusterRoles and ClusterRoleBindings to grant him access to all persistent volumes in the cluster. Example of ClusterRole and ClusterRoleBinding are shown below:

    <p>CODE: https://gist.github.com/ShubhanjanMedhi-dev/f763538e7e550ce5362d84da26c6aa58.js</p>

    Summary

    With the above examples, we can understand the benefits and use cases of Kubernetes RBAC. Below is the summary of what we discussed:

    • Roles and RoleBindings must exist in the same namespace.
    • RoleBindings can exist in separate namespaces to service accounts.
    • RoleBindings can link cluster roles, but they only grant access to the namespace of the role binding.
    • ClusterRoleBindings link accounts to cluster roles and grant access across all resources.
    • ClusterRoleBindings can not reference roles.
    What you should do now
    • Schedule a demo with Squadcast to learn about the platform, answer your questions, and evaluate if Squadcast is the right fit for you.
    • Curious about how Squadcast can assist you in implementing SRE best practices? Discover the platform's capabilities through our Interactive Demo.
    • Enjoyed the article? Explore further insights on the best SRE practices.
    • Schedule a demo with Squadcast to learn about the platform, answer your questions, and evaluate if Squadcast is the right fit for you.
    • Curious about how Squadcast can assist you in implementing SRE best practices? Discover the platform's capabilities through our Interactive Demo.
    • Enjoyed the article? Explore further insights on the best SRE practices.
    • Get a walkthrough of our platform through this Interactive Demo and see how it can solve your specific challenges.
    • See how Charter Leveraged Squadcast to Drive Client Success With Robust Incident Management.
    • Share this blog post with someone you think will find it useful. Share it on Facebook, Twitter, LinkedIn or Reddit
    • Get a walkthrough of our platform through this Interactive Demo and see how it can solve your specific challenges.
    • See how Charter Leveraged Squadcast to Drive Client Success With Robust Incident Management
    • Share this blog post with someone you think will find it useful. Share it on Facebook, Twitter, LinkedIn or Reddit
    • Get a walkthrough of our platform through this Interactive Demo and see how it can solve your specific challenges.
    • See how Charter Leveraged Squadcast to Drive Client Success With Robust Incident Management
    • Share this blog post with someone you think will find it useful. Share it on Facebook, Twitter, LinkedIn or Reddit
    What you should do now?
    Here are 3 ways you can continue your journey to learn more about Unified Incident Management
    Discover the platform's capabilities through our Interactive Demo.
    See how Charter Leveraged Squadcast to Drive Client Success With Robust Incident Management.
    Share the article
    Share this blog post on Facebook, Twitter, Reddit or LinkedIn.
    We’ll show you how Squadcast works and help you figure out if Squadcast is the right fit for you.
    Experience the benefits of Squadcast's Incident Management and On-Call solutions firsthand.
    Compare our plans and find the perfect fit for your business.
    See Redis' Journey to Efficient Incident Management through alert noise reduction With Squadcast.
    Discover the platform's capabilities through our Interactive Demo.
    We’ll show you how Squadcast works and help you figure out if Squadcast is the right fit for you.
    Experience the benefits of Squadcast's Incident Management and On-Call solutions firsthand.
    Compare Squadcast & PagerDuty / Opsgenie
    Compare and see if Squadcast is the right fit for your needs.
    Compare our plans and find the perfect fit for your business.
    Learn how Scoro created a solid foundation for better on-call practices with Squadcast.
    Discover the platform's capabilities through our Interactive Demo.
    We’ll show you how Squadcast works and help you figure out if Squadcast is the right fit for you.
    Experience the benefits of Squadcast's Incident Management and On-Call solutions firsthand.
    We’ll show you how Squadcast works and help you figure out if Squadcast is the right fit for you.
    Learn how Scoro created a solid foundation for better on-call practices with Squadcast.
    We’ll show you how Squadcast works and help you figure out if Squadcast is the right fit for you.
    Discover the platform's capabilities through our Interactive Demo.
    Enjoyed the article? Explore further insights on the best SRE practices.
    We’ll show you how Squadcast works and help you figure out if Squadcast is the right fit for you.
    Experience the benefits of Squadcast's Incident Management and On-Call solutions firsthand.
    Enjoyed the article? Explore further insights on the best SRE practices.
    Written By:
    September 27, 2021
    September 27, 2021
    Share this post:
    Subscribe to our LinkedIn Newsletter to receive more educational content
    Subscribe now
    ant-design-linkedIN

    Subscribe to our latest updates

    Enter your Email Id
    Thank you! Your submission has been received!
    Oops! Something went wrong while submitting the form.
    FAQs
    More from
    Kasun Rajapakse
    No items found.
    Learn how organizations are using Squadcast
    to maintain and improve upon their Reliability metrics
    Learn how organizations are using Squadcast to maintain and improve upon their Reliability metrics
    mapgears
    "Mapgears simplified their complex On-call Alerting process with Squadcast.
    Squadcast has helped us aggregate alerts coming in from hundreds...
    bibam
    "Bibam found their best PagerDuty alternative in Squadcast.
    By moving to Squadcast from Pagerduty, we have seen a serious reduction in alert fatigue, allowing us to focus...
    tanner
    "Squadcast helped Tanner gain system insights and boost team productivity.
    Squadcast has integrated seamlessly into our DevOps and on-call team's workflows. Thanks to their reliability...
    Alexandre Lessard
    System Analyst
    Martin do Santos
    Platform and Architecture Tech Lead
    Sandro Franchi
    CTO
    Squadcast is a leader in Incident Management on G2 Squadcast is a leader in Mid-Market IT Service Management (ITSM) Tools on G2 Squadcast is a leader in Americas IT Alerting on G2 Best IT Management Products 2022 Squadcast is a leader in Europe IT Alerting on G2 Squadcast is a leader in Mid-Market Asia Pacific Incident Management on G2 Users love Squadcast on G2
    Squadcast awarded as "Best Software" in the IT Management category by G2 🎉 Read full report here.
    What our
    customers
    have to say
    mapgears
    "Mapgears simplified their complex On-call Alerting process with Squadcast.
    Squadcast has helped us aggregate alerts coming in from hundreds of services into one single platform. We no longer have hundreds of...
    Alexandre Lessard
    System Analyst
    bibam
    "Bibam found their best PagerDuty alternative in Squadcast.
    By moving to Squadcast from Pagerduty, we have seen a serious reduction in alert fatigue, allowing us to focus...
    Martin do Santos
    Platform and Architecture Tech Lead
    tanner
    "Squadcast helped Tanner gain system insights and boost team productivity.
    Squadcast has integrated seamlessly into our DevOps and on-call team's workflows. Thanks to their reliability metrics we have...
    Sandro Franchi
    CTO
    Revamp your Incident Response.
    Peak Reliability
    Easier, Faster, More Automated with SRE.