paint-brush
About Kubernetes Authenticationby@sudip-sengupta
663 reads
663 reads

About Kubernetes Authentication

by Sudip SenguptaJuly 11th, 2020
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Kubernetes uses authentication, Authorization and Admission to enforce security access and permissions. There are 3 steps that are taken in the authentication process. The first thing in Authentication is Identity, Identity and Identity Identity Identity. The two minimal methods required are - Service account tokens for service accounts and at least one other method of user authentication. The API server reads bearer tokens from a file when given the option "Bearer" on the command line. The token list cannot be changed without restarting the API server, and the token list can't be changed.
featured image - About Kubernetes Authentication
Sudip Sengupta HackerNoon profile picture

There are 3 steps that Kubernetes uses to enforce security access and permissions are: Authentication, Authorization and Admission. In this article we are going to consider Authentication first.


The Authentication, Authorization and Admission Control Process

The first thing in Authentication is Identity.

Identity

  • Kubernetes assumes that 'users' are managed outside of Kubernetes:

     a. In production environments it can be LDAP (Lightweight Directory Access Protocol), SSO (Single-Sign On), Kerberos or SAML (Security Assertion Markup Language) for identity management.

     b. In development or test environments, other Authentication Strategies may be employed.

  • Kubernetes does not have a notion of a human user.

Authentication Strategies

Kubernetes uses authenticating proxy, bearer tokens, client certificates, or HTTP basic authorization to authenticate API requests through authentication plugins. As HTTP request are made to the API Server, plugins attempt to associate the following attributes with the request:

  • Username: A string which identifies the end-user
  • UID: A string which identifies the end-user and attempts to be more consistent and unique than a username
  • Groups: A set of string which associate users with a set of commonly grouped users
  • Extra fields: A map of strings which holds additional information Authorizers might find useful

All of these values are opaque to the authentication system and only hold significance when interpreted by an 

authorizer
. Kubernetes administrators typically enable multiple authentication methods. The two minimal methods required are - Service account tokens for service accounts and at least one other method of user authentication.

X509 Client Certificates

  • As of Kubernetes 1.4, client certificates can also indicate a user's group memberships using the certificate's organization fields.
  • To include multiple group memberships for a user, include multiple organization fields in the certificate.
  • Client certificate authentication is enabled by passing the 
    --client-ca-file=<FILE>
     option to the API server.
  • The referenced file must contain one or more certificate authorities to use to validate client certificates presented to the API server.
  • If a client certificate is presented and verified, the common name of the subject is used as the user name for the request.

For instance, using the 

openssl
 command line tool to generate a certificate signing request:

openssl req -new -key <pem_file>.pem -out <out-csr-file>.pem -subj "/CN=admin/O=prod/O=dev/O=uat"

This would create a CSR (Certificate Signing Request) for the username admin, belonging to three groups: 

prod
dev
 and 
uat
.

Static Token File

The API server reads bearer tokens from a file when given the 

--token-auth-file=<FILENAME>
 option on the command line. Today, tokens last indefinitely, and the token list cannot be changed without restarting the API server. The token file is a 
CSV
 file with a minimum of 3 columns:
token, user name, user uid
, followed by optional group names.

token, user, uid,"prod,dev,uat"
Note: If you have more than one group, the column must be double quoted.

Putting a Bearer Token in a Request

When using bearer token authentication from an HTTP client, the API server expects an 

Authorization
 header with a value of 
Bearer <Token>
. The bearer token must be a character sequence that can be put in an HTTP header value using no more than the encoding and quoting facilities of HTTP. For instance, if the bearer token is 
ad644f3f-bfch-295b-75bk-h9g8ngf36hb6
, then it would appear in an HTTP header as shown below:

Authorization: Bearer ad644f3f-bfch-295b-75bk-h9g8ngf36hb6

Static Password File

Basic authentication is enabled by passing the 

--basic-auth-file=<FILENAME>
 option to the API server. Now, the basic auth credentials last indefinitely, and the password cannot be changed without restarting the API server.

The basic auth file is a 

csv
 file with a minimum of 3 columns: 
password, user name, user id
. In Kubernetes version 1.6 and later, you can specify an optional 4th column containing comma-separated group names. If you have more than one group, you must enclose the 4th column value in double quotes 
(")
:

password,user,uid,"group1,group2,group3"

When using basic authentication from an HTTP client, the API server expects an 

Authorization 
header with a value of:

Basic BASE64ENCODED(USER:PASSWORD)

Service Account Tokens

A service account is an automatically enabled authenticator that uses signed bearer tokens to verify requests. The plugin takes 2 optional flags:

--service-account-key-file

A file containing a PEM-encoded key for signing bearer tokens. If unspecified, the API server's TLS private key will be used

--service-account-lookup

If enabled, tokens which are deleted from the API server will be revoked

Service accounts are usually created automatically by the API server and associated with pods running in the cluster through the

ServiceAccount
Admission Controller.

Bearer tokens are mounted into pods at well-known locations and allow in-cluster processes to talk to the API server. Accounts may be explicitly associated with pods using the 

serviceAccountName
 field of a 
PodSpec
.

Note, 

serviceAccountName
 is usually omitted because this is done automatically.

Exercise

Working with ServiceAccount Tokens

The following command may be used to create a 

ServiceAccount
:

kubectl create serviceaccount testuser

The created secret holds the public CA of the API server and a signed 

JSON Web Token (JWT)
. To display the 
yaml
 revealing the associated secret:

kubectl get serviceaccount testuser -o yaml

The command to display available tokens is:

kubectl get secrets

To obtain the encoded token data, you may enter:

kubectl get secret testuser-token-mgtnp -o yaml

You can take the encoded token data and copy-and-paste it at https://jwt.io/ to see the payload. To run a pod, use the editor of your choice to input the following 

yaml
 file (
test-pod.yaml
).

apiVersion: v1
kind: pod
metadata:
  name: test-pod
spec:
  serviceAccountName: testuser
  container:
  - name: alpine:3.7
    command:
    - "sh"
    - "-c"
    - "sleep 100"

Then launch the pod with the following command:

kubectl apply -f test-pod.yaml

Use the 

describe
 verb to look at it more closely:

kubectl describe test-pod

Now, that we have a running pod named 

test-pod
, let's get into the interactive mode and run a shell:

kubectl exec -it test-pod -- sh

This is similar to a docker command if you want to run a shell within a docker container. At that point, we are going to have a prompt and we are inside our Alpine Linux system that is running in a container that is within our pod. In order to open the Token that was copied into the container you have to run the following command:

cat /var/run/sercrets/kubernetes.io/serviceaccount/token

Copy the output and paste that token in the Encoded side on https://jwt.io/. On another side you will get the type of token, namespace, ServiceAccount name, Secret name, etc.

This pretty much illustrates to you in a very visual way how Kubernetes is carrying the identification and authentication payload in the token.

About the author - Sudip is a Solution Architect with more than 15 years of working experience, and is the founder of Javelynn. He likes sharing his knowledge by regularly writing for Hackernoon, DZone, Appfleet and many more. And while he is not doing that, he must be fishing or playing chess.

Previously posted at https://appfleet.com/.