Configuring UAA to Provide a Single Entry Point for Kubernetes and Cloud Foundry
The need to unify authentication/authorization
Kubernetes is gaining in popularity in the Cloud Foundry ecosystem as developers explore hybrid deployment options. This trend brings up a new problem where multiple credentials are needed to sign on to the different platforms.
Cloud Foundry makes use of its identity management service—User Account and Authentication (UAA). Kubernetes has a bunch of built-in options for authentication / authorization, however, many of them still leave space for improvement.
In this blog post, we overview how to configure OpenID Connect—available through Cloud Foundry’s UAA—to simplify authentication / authorization and enable better security in comparison to standard means within Kubernetes.
Andrei Krasnitski, Cloud Foundry engineer at Altoros, was a speaker during Day 3 of the Cloud Foundry Summit 2018 in Boston. He briefed attendees about the use of UAA in Kubernetes, as well as built-in options for authentication and authorization.
First, one need to understand the difference between these two terms:
- Authentication (AuthN) determines the identity of a user, a server, or a client.
- Authorization (AuthZ) determines if a user, a server, or a client has permission to execute specific tasks.
“Authentication is the process, which determines who you are. Authorization determines whether a user is allowed to perform certain actions.” —Andrei Krasnitski
Authentication and authorization are used by operators through the
kubectl command-line tool, you can check out a cheat sheet featuring first-aid commands to use with the tool. They are also used in machine-to-machine communications for Kubernetes pods and control plane (API server, controller, scheduler, etc.)
Built-in authentication options for Kubernetes
The current build for Kubernetes already includes some methods for authentication. One of these methods involves using X509 client certificates. Based on his experience, Andrei noted that this solution was not ideal, since it meant “using only one certificate for all clusters.”
Static passwords or tokens can also be used for authentication. “In Kubenetes case, these are CSV files stored somewhere in the file system,” explained Andrei. “These are not the best solutions, but can be good if you want to quickly spin up a server for testing.”
Next up are service accounts, which are typically used for non-interactive workflows in Kubernetes. These can be manually created using the
kubectl create serviceaccount (NAME) command.
Webhook tokens are a relatively new method that enables external services to perform authentication actions against the Kubernetes cluster.
The next method involves using OpenID Connect. For the purpose of configuring UAA for Kubernetes, this is the most important option as Andrei explained. OpenID Connect is an extension on top of the OAuth 2.0 protocol. Instead of the usual workflow on OAuth 2.0, it retrieves additional JSON tokens, which can be used for further authentication.
“The JSON web tokens contains information like a user e-mail, which is very common when you want to perform authentication against the cluster.” —Andrei Krasnitski
Kubernetes does not offer any OpenID Connect identity providers out of the box. Kubernetes also has two major compatibility requirements:
- Discovery. Identity providers should publish all metadata information on well-known URLs.
- Security. Identity providers should always run in the Transport Layer Security mode.
While there are existing identity providers, such as Google, Microsoft, Yahoo, PayPal, and Amazon, there are also self-hosted options like UAA for Cloud Foundry. UAA is an OpenID Connect identity provider, which be can used for a cluster. It’s basically an OAuth 2.0 server that can connect using SAML and LDAP. It also has APIs for user account management.
Built-in authorization options for Kubernetes
Once a user has finally been authenticated, it’s time to check whether or not a user has the permission to perform tasks. Similar to authentication, Kubernetes also has existing modules for authorization. Attribute-based access control (ABAC) is one of these options.
ABAC is stored the same way as static passwords and tokens but in a single JSON object per line format. You can specify users access to namespaces, resources, and so on.
The next mode of authorization is Role-based access control (RBAC). “This is essentially just a collection of the roles,” commented Andrei. For example, you can have a developer role, which has one set of permission on the cluster and an administer role, which has full access. Roles are always allowed to work with an existing namespace, and cluster roles are applied cluster-wide.
Andrei also provided a side-by-side comparison of the two authorization methods.
|Authorization policy changes can be made using the ||Requires SSH and file system access on Kubernetes Master to make changes in the authorization policy file.|
|Changes are applied on the fly.||An operator must restart an API server to pick up a new policy.|
|Authorization is managed by Kubernetes API.||Authorization is managed by a user-configured local file.|
From this comparison, Andrei favored the use of RBAC as in comparison to ABAC it doesn’t require the API server to be restarted every time the policy files get updated.
Configuring OpenID Connect in Kubernetes
Next, Andrei explained how to set up OpenID Connect as it enables a single entry point for both Cloud Foundry and Kubernetes. One needs to configure the following flags on the API server:
--oidc-issuer-url=URLidentifies the URL of a provider, which allows the API server to discover public signing keys.
--oidc-client-id=IDis the client ID for verifying signatures of the JSON web tokens.
--oidc-username-claim=emailspecifies what -mail to use as a username.
--oidc-ca-file=/k8s-ca.emis the path for the certificate authority.
Surely, the main reason for using OpenID Connect is that it provides a single authentication and authorization solution for both Cloud Foundry and Kubernetes. In addition, it is easily configured, includes a service discovery mechanism, and minimizes password security risks.
Want details? Watch the video!
Table of contents
These are the slides from the session.
- Kubernetes kubectl CLI Cheat Sheet
- Kubo Enables Kubernetes Environments Managed by Cloud Foundry’s BOSH
- Evaluating Pivotal Container Service for Kubernetes Clusters
To stay tuned with the latest updates, subscribe to our blog or follow @altoros.