- [Instructor] Authentication and authorization are
two of the most common topics that arise when folks
are trying to integrate Kubernetes
into their infrastructure.
In this section, I'll go over what these features are,
and give you a working understanding of how authentication
and authorization work.
From an architecture perspective,
users who are trying to access the Kubernetes API,
via the kubectl command,
first have to be authenticated to access the API.
And then authorized to run specific actions.
Occasionally, users will also need to
have admission control to approve or reject a request.
First off, we need to understand what a user means
from a Kubernetes context.
There are actually two kinds of users.
Normal users, like you and me,
and service accounts which are internal users to the system.
We typically think of normal users as users who are in an
LDAP or an SSO system in our enterprises.
From a Kubernetes perspective, these users are
managed outside of Kubernetes.
Service accounts are managed by the Kube API server,
bound to a specific namespace,
and tied to credentials managed in secrets.
There are four pieces of information that define a user.
The username, which is basically a string.
For example, Karthik or Karthik@example.com.
A UID, or a unique ID, which is an identifier
that is more consistent and unique than the username.
A group, which is a string that associates users with a set
of commonly grouped users.
These are used later on the by authorization model.
And extra fields which is basically a map of strings
that holds additional information used by the
authorization system.
Authentication in Kubernetes defines whether a user
has access to communicate with the Kube API server.
And authorization defines whether a user has
actual permissions to perform specific actions.
There are a number of ways you can authenticate.
The entire list can be found in the Kubernetes documentation
but we'll look at the four most popular modules that
enterprises use today.
Client certs,
static tokens,
OpenID connect,
or the webhook mode.
Client cert authentication is enabled by passing the
client ca file option to the API server.
The reference file must contain certificate authorities
to validate client certificates passed to the API server.
If a client cert is presented and verified,
the common name of the client certificate is used
as the username for the request.
This is a straight forward way to manage Kubernetes
if you're comfortable with handling certificate managements
in your org.
The API server reads the bare tokens from a file when
given the dash dash token auth file
option on the command line.
The token auth file is a CSV file with four columns:
token,
username,
user UID,
followed by optional group names as shown in the example.
The caveat to this method is that these tokens last
indefinitely and you're required to restart the API
server for any changes in tokens to take place.
The static password file is similar to this method
but the values are passed as basic auth parameters.
The benefit of this method, is that it's very simple
and easy to manage a small batch of users this way.
For larger organizations that already have oAuth,
such as Google, or Azure Active Directory,
you can configure the OpenID connect tokens to authenticate
against Kubernetes.
The details of this are complex and I'd recommend
reading the docs for this method.
And finally, there's authentication using webhook tokens.
This is one of the most common methods that's used by
a number of organizations who want to have the users
interacting with Kubernetes but also manage tokens in
an easier way.
Using this method, the Kube API server makes a request
to an API that's defined by you to authenticate.
The remote API decides whether a token passed to it
is a valid token or not, and then responds
back to the server.
On the authorization front,
there are three common ways to perform authorizations.
ABAC,
RBAC,
or Webhook.
Let's see what these are.
ABAC, or attribute based access control,
defines an access control paradigm whereby access rights
are granted to users through the use of policies
that combine attributes together.
The ABAC file defines what access a specific user might
have to all resources.
In the example config shown, Karthik has master access
to all attributes, whereas the user Carisa only has
read access to all the repos and name spaces.
RBAC is role based access control.
This is the most common authorization mechanism
used in Kubernetes and a lot of applications end up
using RBAC to authorize their service accounts.
I would recommend that you turn on this functionality
on your KubeAPI server even if you're using another
authorization mechanism, because you'll end up using
something that will require RBAC being installed.
RBAC depends on roles and cluster roles.
These are rules that represent a set of permissions.
A role can be defined within the namespace with a role
or a clusterwide with a cluster role.
In this example, we see that a role is in the
default namespace that allows read access to all pods.
Role bindings grant permissions defined in a role to users.
They hold the users or group as a reference to the role
being granted.
Permissions can then be granted within a namespace
with a role binding or cluster wide with a
cluster role binding.
In the example shown, the user Karthik can read pods
in the default namespace.
The webhook mode for authorization, like the authentication
webhook mode, allows you to define what permissions
are allowed for a specified user.
The Kube API server will send a request with the user
and resource attribute data to a remote server
that you define, that interprets the request and defines
whether a request is allowed or not.
This method works really well if you're trying to integrate
with a third party authorization system,
or if you want a complex set of rules.