Control and Secure Kubectl Access

TL;DR: Managing secure kubectl access to Kubernetes clusters is a pain. Learn how Devtron simplifies this process by offering a user-friendly interface to manage RBAC & provides a secure way to grant access to users.

23 days ago   •   8 min read

By Bhushan Nemade
Table of contents

As organizations increasingly adopt Kubernetes (K8s) for application deployment and management, a significant challenge arises: managing control and secure access to K8s clusters. The traditional approach, for granting access which relies on the command-line tool, has proven to be complex and error-prone. This blog will explore the difficulties teams face and discuss how Devtron's new feature can help teams mitigate these challenges.

The Daily Struggle

Picture this: you are a DevOps person in your organization who manages the infrastructure and is responsible for taking applications/services from pre-production to production. Multiple teams approach you to gain access to the Kubernetes cluster. E.g. Developers need “kubectl” access to the Kubernetes cluster for testing and debugging their applications. Similarly, multiple teams require access to the Kubernetes cluster for multiple reasons. You are generating kubeconfigs for each cluster, configuring them as per the access requested using the command line.


As a person responsible for managing infrastructure, you one day wake up with multiple alarms, some of them for  Data Loss, Configuration Drift, and Privilege Escalation.

You start investigating the incident and find out that the disruption was caused due to: A user who had obtained privileged kubectl access due to misconfigurations and has used that access inappropriately. Your first response was to remove all access for the user and ask your team to check the access privileges of all other members. While your team kept auditing the kubectl access levels, you started wondering how this incident occurred and where the loophole was. After some brainstorming, you realized that the incident was caused by the misconfiguration while configuring RBAC and the complex way you configured user access in kubeconfig i.e. defining roles and rolebindings or configuring service accounts..

This was a single incident caused by a misconfiguration when using command-line tools for critical tasks like access management. There is a high chance of such mistakes occurring more frequently. While managing the infrastructure access, you may face several challenges.

Common Challenges

Access Management Overhead

As someone who manages the organization's infrastructure, granting and revoking access for multiple users using command-line tools can be a time-consuming task. Moreover, if teams need frequent changes in access control the method for updating access control with these command line tools can be a nightmare. A single mistake can result in unauthorized access or accidental disruption of services.

Maintaining Kubeconfig Files

You need to manage multiple kubeconfigs files for different clusters. Keeping these files updated and correctly configured can be a logistical nightmare, leading to potential security gaps and access issues.

Complexity of RBAC Configuration

Configuring robust and concise RBAC (Role-Based Access Control) policies is a challenge in itself. Moreover, using command-line tools to set up RBAC makes the process even more complicated. It becomes difficult to define and enforce granular RBAC policies at the cluster resource level. You and your team need to manage these complex and precise RBAC policies for each user potentially spanning multiple teams across the organization. Maintaining these RBAC configurations using command-line tools can quickly become overwhelming, leading to potential misconfigurations, inconsistencies, and security vulnerabilities.

Scalability and Consistency Issues

As your organization's Kubernetes footprint expands, managing access consistently across multiple environments becomes increasingly difficult, leading to potential inconsistencies and security vulnerabilities.

While these challenges may seem overwhelming, there is a solution that can streamline access management, and simplify RBAC configuration. It also provides a centralized and secure approach for managing Kubernetes access.

Devtron comes with a feature, that offers a comprehensive solution to address these pain points. Empowering operations teams to regain control and enhance security across their Kubernetes clusters. In the following sections, we'll explore how Devtron can help mitigate these challenges and provide a more robust and scalable approach for control and a more secure approach to kubectl access.

Streamlined Approach for kubectl Access with Devtron

As we've discussed, managing secure kubectl access for Kubernetes clusters using a traditional command line can be a daunting task. Moreover, the moment when you need to manage it for multiple teams you may start facing multiple challenges.

As an open-source software delivery platform for Kubernetes, Devtron boasts ease of security and scalability, and it sets secure Kubectl access for multiple users and teams through its intuitive dashboard. You can manage access for multiple clusters without complexities, all through a user-friendly interface. The dashboard allows you to configure precise and robust RBAC policies down to the Kubernetes cluster resource level, such as allocating access to specific pods. The dashboard allows creating groups and attaching permissions or policies, making it convenient to grant appropriate access, like deploying and debugging applications for developer teams, by creating a developer group and associating the relevant policy.

Before we dive into the process of granting kubectl access to team members using Devtron, there are two essential components we need to have in place:

  1. A proxy URL of the Kubernetes cluster, provided by Devtron.
  2. Devtron's access token: A kubectl-compatible token with specific policies and roles attached to it.

Let's dive into Devtron and explore how we can obtain these two essential components. This will enable us to create a secure and controlled kubectl access path for managing access control for teams.

Step 1: Installing Devtron

Step 2: Onboarding Kubernetes Cluster

  • Now that we have Devtron up and running. Let's proceed with the onboarding of the Kubernetes cluster.
  • Devtron enables you to onboard managed Kubernetes clusters of any flavor, including GKE, EKS, and AKS. Additionally, you can onboard your on-premises self-managed Kubernetes clusters.

Global Configurations -> Clusters & Environments -> Add Cluster

[Fig. 1] Onboarding Kubernetes Cluster

Once our cluster is onboarded we can navigate to Resource Browser of Devtron. Here, we get an overview of our Kubernetes cluster. After onboarding your Kubernetes cluster to Devtron, Devtron provides a proxy URL that allows you to access the cluster securely.

Refer to this to learn more about Resource Browser

Step 3: Onboarding Teams and Setting a Robust RBAC

  • With our Kubernetes cluster onboarded to Devtron, we can now start onboarding teams, granting them access to the cluster. You can add individual team members to the Devtron dashboard and configure a robust and precise RBAC.
Adding User and Setting RBAC
[Fig. 2] Adding User and Setting RBAC

As we can see with Devtron's user-friendly interface, we were able to onboard both our Kubernetes cluster and a user within a few minutes. At the same time, when operations teams need to manage access for users, they typically have to navigate through a complex command line process involving multiple commands. With Devtron you can manage the access of the user through an intuitive dashboard, Devtron has a feature where you can mark the status of users: ‘Active’, ‘Inactive’, or ‘Keep active until’ which is time-based access (TTL).

  • Up until now, we have onboarded both our Kubernetes cluster and a user to Devtron. In this scenario, our user is a developer, as in most organizations, developers often require access to the Kubernetes cluster using kubectl for testing their applications and debugging purposes.

Step 5: Generating an API Token

  • Our first developer requires access to the cluster to test the application running in a specific pod, while the second developer needs access to debug the application.
  • If we follow traditional methods, we would have to manually configure two separate kubeconfig files for each cluster carefully assigning the appropriate roles and permissions for each developer a complex and error-prone process.
  • However, Devtron allows super-admins to generate an API token with precise policies and roles attached. Using this token provided by super-admins, developers can access the Kubernetes resources of the specific cluster through kubectl.
  • In scenarios where we need to modify the permissions granted to our developers, Devtron allows us to modify the permissions associated with the API tokens. Through Devtron's intuitive dashboard, we can easily modify the permissions of tokens assigned to a specific developer, ensuring their access aligns with their evolving responsibilities without the need for complex manual configurations.
Generate API Token
[Fig. 3] Generate API Token
  • With the API token generated, with specific permissions and roles defined for our developers, we are now ready to provide them access using this token. Armed with this token, our developers can securely access the designated Kubernetes cluster and interact with the specific resources they have been granted access to.

Step 6: Accessing Kubernetes Cluster through kubectl

  • With the cluster proxy URL and API token in hand, we now possess the essential components required to provide secure and controlled access to our Kubernetes cluster. Let's put these components into action and explore how to leverage them for granting kubectl access to our team members. With the cluster proxy URL and API token at hand, these components can be shared with the developers. To gain access to the Kubernetes cluster, developers will utilize a simplified kubeconfig file that differs significantly from the traditional approach. Developers can leverage a single template for the kubeconfig file, wherein they need to paste the provided proxy URL and API token. Once these values are populated, developers can simply run the command apply kubeconfig and they will immediately have access to the Kubernetes cluster.
apiVersion: v1
kind: Config
- cluster:
    insecure-skip-tls-verify: true
    server: https://<devtron_host_name>/orchestrator/k8s/proxy/cluster/<cluster_name>
  name: devtron-cluster
- context:
    cluster: devtron-cluster
    user: admin
  name: devtron-cluster
current-context: devtron-cluster
- name: admin
    token: <devtron_token>
  • The developer needs to replace the placeholders with specific values in this file.
devtron_host_name The hostname of the Devtron server
cluster_name Name of the cluster (or cluster ID)
devtron_token API token or session token
replace the placeholders with specific values
[Fig. 4] Accessing Kubernetes Cluster
  • Now that we are in the Kubernetes cluster, let’s check to see if we can perform any actions. We will be doing fundamental things, such as forwarding the port of application deployed in the Kubernetes cluster. By which we will be able to use the application locally.
Port Forwarding
[Fig. 5] Executing Kubectl Commands with Proper RBAC


Managing secure kubectl access to Kubernetes clusters is a critical and challenging task, especially for organizations increasingly adopting K8s for application deployment. The traditional command-line approach has proven to be complex, time-consuming, and error-prone. Devtron offers a robust solution to these challenges. By providing a user-friendly interface that simplifies and streamlines the process of giving a robust and precise approach to secure kubectl access. This not only saves time but also ensures that the right people have the right access to the right resources, making kubectl access management a smooth, secure, and scalable process.

If you have any queries, don't hesitate to connect with us. Join the lively discussions and shared knowledge in our actively growing Discord Community.

Spread the word

Keep reading