KASLIN FIELDS: Hello.
I'm Kaslin Fields, and I'm a developer advocate
at Google Cloud focused on GKE--
Google Kubernetes Engine-- as well as open-source Kubernetes.
In this episode of "GKE Essentials,"
we'll take a look at a key element of your GKE security
posture--
authorization or access management, specifically with
regard to workloads.
For a broader look at GKE security,
be sure to check out our "Introduction to Securing
Cluster" access video.
[MUSIC PLAYING]
When it comes to GKE, there are two distinct types or levels
of authorization that you should be familiar with--
Google Cloud IAM and Kubernetes Role-Based
Access Control, or RBAC.
The IAM in Google Cloud IAM stands for Identity and Access
Management.
Basically, IAM tools are what you
use to set up rules for who can do what to which resources.
The who in identity and access management
is going to be some form of account,
and IAM allows you to set limits on what that account can do
and with which resources in Google Cloud.
You can design your own custom IAM roles.
But, for GKE, there are also several predefined Cloud IAM
roles to quickly and relatively easily
provide granular access to Kubernetes Engine resources.
The GKE Viewer role gives read-only access,
as might be needed for auditing.
The GKE Developer role is suited to developers and release
engineers.
It grants full control to all resources within a cluster.
The GKE Admin role gives full access
to clusters and the Kubernetes Engine
resources inside the clusters.
Example users are project owners, system administrators,
and on-call engineers.
The GKE Cluster Admin role is used to create, delete, update,
and view clusters, but provides no access to Kubernetes
resources within the cluster.
You can also create a custom role in Google Cloud IAM
to create a role with a more minimal set of permissions
than those that are predefined.
So Google Cloud IAM can be used to control Google Cloud users'
access to the GKE cluster and its related resources.
For managing access to resources within the cluster,
Kubernetes has its own similar concept--
Role-Based Access Controls, or RBAC.
Separate accounts are needed within the cluster
to control cluster users' access.
Just like with Cloud IAM, RBAC is the tool
for configuring who can do what with which
resources within the cluster.
So Cloud IAM lets you manage who can do what to which
resources at the Cloud level, controlling access
to the Google Cloud project, GKE cluster, and other resources,
like Cloud Storage.
Kubernetes Role-Based Access Control, or RBAC,
manages who can do what with which
resources within the cluster on Kubernetes resources
like deployments, persistent volumes, et cetera.
But what if the thing you want to give permissions to you
isn't a user, but a workload running within Kubernetes?
For cases where the who is a workload, both Google Cloud
IAM and Kubernetes RBAC have a concept
called a service account.
At this point, it can get a bit confusing.
There's something called a service account at both
the Cloud and Kubernetes level.
A Kubernetes service account is part of your Kubernetes
cluster, and it can be used to give a workload running
within the cluster access to other parts of the cluster.
Its scope is contained within the Kubernetes cluster.
A Google Cloud service account is part of your Google Cloud
project.
The who of a Google Cloud service account
can be a Google Cloud resource, like a GKE cluster, which
can be given permissions via IAM to access other Cloud
resources.
So what if you have a situation where
a workload running within GKE needs access
to some other Google Cloud resource, like BigQuery?
To get permissions all the way from a workload
within Kubernetes to other resources running
in Google Cloud in the most granular way possible,
another concept is needed to tie the two service account
concepts together.
That concept is Workload Identity.
Workload Identity can be used to automatically connect
a Google Cloud service account to a Kubernetes service account
so that any workloads represented by the Kubernetes
service account will have the access described by the GCP
service account in order to use any Google Cloud
APIs, products, or services that workload might need.
Workload Identity provides granular control,
offering just the right permissions
to a particular workload rather than to,
for example, a whole compute node or a whole cluster,
which may have multiple workloads running
on them that don't need the same level of access.
You would configure Workload Identity
using something similar to the two commands shown here.
The first command at the top uses the gcloud tool
to make a call to the GCP APIs to create a policy binding,
granting the Kubernetes service account
access to act as the associated Google Cloud service account.
The second command, at the bottom,
uses the kubectl tool to use Kubernetes APIs to annotate
the Kubernetes service account with the name of the Google
Cloud service account it will act as.
These concepts can be a little confusing at first,
but Workload Identity can help make
access management for workloads running within your GKE
clusters much smoother and easier to manage.
In this episode, we talked about managing access
to resources at the Cloud and cluster levels
and about simplifying access management
for Kubernetes workloads via Google Cloud Workload Identity.
With the concepts discussed in this video,
we're confident you'll be on your way
to building a GKE cluster that suits your needs.
You can get started with GKE by visiting the Google Cloud
Console and checking out the links below.
And stay tuned for our next videos, where we dive deeper
into GKE topics.
[MUSIC PLAYING]