by Bharathiraja Shanmugam
Kubernetes, an automated system for managing containerized applications, offers multiple benefits to developers. It eliminates application downtime by creating a new pod automatically when an existing pod crashes, and it allows teams to easily scale applications for traffic increases or decreases. Many organizations are moving their existing applications to Kubernetes due to these and other features.
When using one of the managed Kubernetes services provided by cloud vendors, such as Amazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (GKE), or Azure Kubernetes Service (AKS), you’ll need to determine user access to that service. Kubernetes offers a command-line client tool, kubectl, that uses your admin configuration file to access your Kubernetes cluster. If other team members need to access that cluster, you’ll need to create a separate config file with the proper access permissions. This can be handled through Kubernetes access control.
However, not all members of an organization require the same level of access. Development and sales teams, for instance, will have different needs, and overly broad access across an organization can raise the risk of human error or security breaches. Kubernetes allows you to create different roles and assign needed permissions to those roles, then assign roles to different users.
There are essential components to keep in mind when assigning Kubernetes access control. The following are ten of these components, which will help you to improve developer experience (DX) and security as well as optimize your app’s scalability.
1. Single Sign-On
Rather than relying on static passwords, which can raise a security risk, you can use single sign-on (SSO) authentication to access your Kubernetes cluster. Kubernetes offers the ability to use an OpenID Connect (OIDC) token to authenticate for SSO, which provides a user-friendly login experience. OIDC supports identity providers such as Salesforce, Azure AD, and Google, which will give you an access token, an ID token, and a refresh token. The ID token is a JWT that you can then use for authorization.
Dex is another open-source tool for SSO on the Kubernetes cluster, developed from CoreOS. Dex supports LDAP, GitHub, SAML 2.0, GitLab, OAuth 2.0, Google, LinkedIn, Microsoft, Bitbucket Cloud, OpenShift, Atlassian Crowd, Gitea, and OpenStack Keystone for SSO. You can control token generation after login using Dex and force the user to re-authenticate if needed. Dex also provides strong documentation to implement various connectors.
2. Audit Logging
The audit logging feature records all requests to the Kubernetes cluster. It captures the URL requested in the Kubernetes API server, which users or services made the request, when the request was made, from where it was made and to where, and why the request was approved or rejected. Audit logs store data in JSON Lines format and contain metadata in key-value pairs.
There are many tools available to analyze audit log files, such as Prometheus and Grafana. Analysis helps you detect issues like authentication or authorization failures and slow API requests. You can also use the log report data to identify unusual traffic to the cluster, which can help you mitigate any attacks.
This is a vital feature for your server application, because the logs will tell you how your cluster is performing and whether there are problems.
3. Role-Based Access Control
Role-based access control (RBAC) is used to add new users or groups to your Kubernetes cluster. By default, the admin configuration certificate file can’t be distributed to all users. By using RBAC, you can define which Kubernetes components can be accessed by which users and what activity they can perform with each component.
The four components of RBAC are Role, ClusterRole, RoleBinding, and ClusterRoleBinding. Role and ClusterRole define access permissions. RoleBinding and ClusterRoleBinding bind the Role and ClusterRole to the user. The Role and ClusterRole are the same, but the Role is created for a specific namespace and the ClusterRole is used for the cluster.
RBAC can be used with OIDC, so you can control access permissions of the Kubernetes components for the created users or groups. By using RBAC, you define which resources can be accessed by which users or groups using Role and RoleBinding. RBAC allows for flexibility in access control; you can add or modify the access permissions at any time.
4. Policy Configuration
Kubernetes policies allow you to restrict resource usage and protect components from unauthorized access. Policies include resource quotas, pod security policies, and network policies.
Network policies allow you to control the network access of the pods by restricting the node port access. Resource quotas are used to limit CPU and memory usage by Kubernetes components. If the components exceed the limit, then those components can’t be created, which will return the HTTP status code 403 Forbidden. Lastly, the pod in the Kubernetes cluster is used to run the application. A pod security policy allows you to define certain conditions, and the pod will only run if it meets those conditions.
5. Kubernetes Contexts
A kubeconfig file is used for authentication and authorization. Within that file, the kube-context contains the Kubernetes cluster (server URL and certificate authority data), username, and namespace. This type of file is created using RBAC or the managed Kubernetes provider.
The context defines which user is associated with which namespace and with which cluster, because the kubeconfig file has the option to define multiple Kubernetes cluster URLs. Use the kubectl config current-context command to get the current context, then the kubectl config use-context namespace_name command to switch to a different context.
etcd, a Kubernetes control plane component, is a highly available key-value store. All the Kubernetes cluster data will be stored in etcd, which serves as a distributed database. ectd allows all the nodes in the Kubernetes cluster to read and write components’ state data. It stores the actual state and desired state of the Kubernetes components. The kubectl get command reads the data from etcd, and the kubectl create command creates new entries in etcd.
Securing etcd is important because if an unauthorized person gains access, they can modify or delete any of the data of your Kubernetes components. Enable TLS for etcd to protect it from unauthorized access.
7. Hardened Worker Node Access
Whenever you issue a command using kubectl, the worker node in the Kubernetes cluster will do the work for you. The control plane instructs the worker node based on the command, then stores the component state data in the etcd database. This means the pod will run only on the worker node.
If someone gains access to the worker node using a SSH connection, they can create a security threat to your application. You should not give direct access to your worker node. Ensure the node is disabled for SSH access. Control the network port access in the worker node to avoid unnecessary problems.
8. External Secrets
Kubernetes secrets are used to store sensitive information such as passwords. However, the data is Base64 encoded by default, which is not sufficient to protect the application credentials.
Using an external secrets manager is recommended because if a user can access those credentials, that raises the possibility of misuse. There are many tools and providers available that can store your sensitive data, such as AWS Secrets Manager and HashiCorp Vault.
9. Namespaces
Namespaces are used to isolate Kubernetes components. You can place components such as pods, services, or secrets in different namespaces based on your needs, even running database pods in one namespace and frontend application pods in another namespace.
If you split the frontend application and database application, you can create access permissions using RBAC and easily restrict access to the Kubernetes components. RBAC with namespaces will help you to implement better access control to the resources.
10. Continuous Updates
Kubernetes releases a new version three times a year, and you should update your cluster each time. The new version will address any existing bugs and add new functionality. For instance, RBAC was added in Kubernetes version 1.6. If you are not continuously updating, then you won’t be able to use the latest features.
If you use a managed Kubernetes provider, that makes the upgrade process easier. Your provider will handle the work and give you the updated user interface.
Conclusion
Kubernetes, while popular, is a complex platform and you must pay close attention to the user access you provide on your cluster. Not all users will need the same level of access permissions on all components. Ensuring specific user access will help you keep your cluster secure and ensure better transparency across your organization, as each team member will know their defined role in your Kubernetes application.
These access control components may sound time-consuming to implement, but your managed Kubernetes provider can help or even do much of the work for you. Taking the time to ensure proper access control up front will save you and your organization from trouble down the road.
Photo by Evelyn Paris on Unsplash
Originally published at https://loft.sh.
