2015 wasn’t very long ago, but when we look at significant events in computing, that was the year that the Cloud Native Computing Foundation (CNCF) was founded to promote the use of containers in the cloud. The first project the CNCF adopted was Kubernetes, a project built and maintained by Google.
The goal of Kubernetes was to provide an open source framework for automating the deployment and management of container-based applications. Within four years, it has risen in prominence to become a dominant player within the container space. With the support of Google, and adoption by major IT players like Intel, Evernote, Starbucks, and Yahoo, among others, it appears to be not only here to stay — It’s continuing to take the world by storm.
In this article, we’re going to talk about Kubernetes security and access control. We’re going to discuss mechanisms in place within the Kubernetes ecosystem to authenticate and authorize users, and we’re going to consider the benefits of using a central security service to manage not only Kubernetes, but also our entire IT infrastructure.
Kubernetes Authentication and Authorization
Access within a Kubernetes cluster consists of two distinct operations. Users of the cluster authenticate through a variety of means before they can gain access. Different providers of Kubernetes hosting may use different strategies, but in general, a user needs to authenticate through one of the following:
- Authentication proxy
- Bearer token
- Client certificate
- HTTP basic authentication
- OpenID
- Webhooks
After authentication, a user can access all resources within the cluster. We can limit this access by configuring authorization, which determines which resource they can access within the cluster. Authorization can be configured to grant or deny all access to users — or for a more granular approach, you can enable one of the following authorization methods.
- Attribute-Based Access Control (ABAC)
- Role-Based Access Control (RBAC)
- Webhooks
RBAC provides the most straightforward and comprehensive control of what and how users can access resources.
Understanding RBAC
In its most basic form, RBAC involves the creation of different roles. Roles could include administrators, supervisors, users with full access, and users with read-only access. Users are then assigned a role based on the access they require.
The benefit of the RBAC approach is that you don’t need to assign access rights at the user’s level. When you consider the different permutations between rights and the number of users, managing such a system would require tremendous overhead, have a high risk for errors, and would be an auditing nightmare.
RBAC dramatically simplifies the process of assigning rights to users, and in so doing, reduces the time for administration and the propensity for errors. Determining roles and assigning those roles for each cluster is in itself a potential mammoth task, so perhaps we should consider a system which encompasses the benefits of RBAC, but on a global level.
The Benefits of a Centralized Security Service
CyberArk Conjur is a security service which can support the security needs of your organization within a central service. An RBAC model, which is controlled by policies, creates users, groups, and resources, and maintains the relationships between them. Integrations with LDAP further simplify administration, automatically adding and removing users as they join, move within, or leave your organization.
Conjur uses industry-standard cryptography and has been professionally audited to ensure your data and secrets are as safe as possible. All communication between Kubernetes and Conjur is encrypted through TLS, keeping your secrets secure. Conjur is also highly scalable and built to support containerized applications, which makes it the perfect security service to support your Kubernetes clusters.
Using RBAC with Conjur
Conjur provides detailed documentation of how to connect and use Conjur with your Kubernetes, OpenShift or Google Kubernetes Engine (GKE). I’m going to highlight some of the benefits and walk through the steps at a high level, including links to additional information as appropriate.
As I mentioned above, using Conjur centralizes all your security requirements, allowing developers to focus on developing and deploying applications, while your security team maintains the access policies in Conjur. Conjur also supports rotation of secrets and encryptions keys and centralized auditing.
Create Policies for the Cluster
The first step in integrating your cluster and Conjur is to create the policies needed to support authorization and authentication. You’ll find example policies here, and you’ll want to make sure you create policies for:
- Users and groups
- Any services which need access
- Kubernetes authentication identities
Initialize the CA
The CA certificate ensures that communication between the cluster and Conjur is encrypted and safe from unauthorized access or manipulation. The steps to initialize and apply the CA certificate are here.
Configure the Conjur Authenticators
The authenticators are defined within a Conjur policy, and each cluster includes the value of the authenticator as an environment variable.
Configure the Authenticator Client
You can download the authenticator client from DockerHub. You can include the client as an init container, or as a sidecar application. The application manifest for each option is listed below.
Each approach requires configuration with the Conjur Appliance information, which is detailed here.
Configure a Shared Volume
To manage tokens between the container and the authenticator, you’ll need to create a shared, in-memory volume which is mounted to both the container and the authenticator at /run/conjur.
Configure the Application
The application needs access to information about the Conjur Appliance. A detailed description of the required parameters is here. The application manifest also needs to be configured with the authenticator client name, as shown here.
Accessing Secrets with Conjur
As an added benefit, the connection to Conjur for authentication and authorization also allows you to use Conjur to store passwords which can be specific to the user, or the service being accessed. You can access these secrets using Summon, the Conjur API, or a variety of client libraries for Ruby, Go, Java and .NET.
If the secrets for your application need to be loaded into Conjur, you’ll need to add these to the appropriate policy and set them through the Conjur CLI, or REST API.
Learning More
If you’ve followed these steps, all that remains is to start your application. You’ll find additional information in the Conjur documentation, and you can also connect with Conjur and other users on the CyberArk Commons or GitHub.
