Configuring UAA to Provide a Single Entry Point for Kubernetes and Cloud Foundry

by Carlo Gutierrez and Andrei KrasnitskiMay 3, 2018

A part of the UAA service, OpenID Connect can be used to enable authentication and authorization for Kubernetes and minimize password security risks.

Table of Contents

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.

Andrei Krasnitski

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

How authentication and authorization flow in Kubernetes

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.”

An example of the X509 client certificate

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.”

An example of a static password / token

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.

An example of a service account

Webhook tokens are a relatively new method that enables external services to perform authentication actions against the Kubernetes cluster.

A webhook token workflow

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

JSON web tokens are encrypted into three parts

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.

OpenID Connect authentication workflow within Kubernetes

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.

An example of an ABAC policy

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.

An example of a RBAC role

Andrei also provided a side-by-side comparison of the two authorization methods.

RBAC	ABAC
Authorization policy changes can be made using the `kubectl` command-line tool.	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=URL identifies the URL of a provider, which allows the API server to discover public signing keys.
--oidc-client-id=ID is the client ID for verifying signatures of the JSON web tokens.
--oidc-username-claim=email specifies what -mail to use as a username.
--oidc-ca-file=/k8s-ca.em is the path for the certificate authority.

Kubo-release users can use these commits instead

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.