ANTHONY BUSHONG: When getting started with GKE,
it's essential to think about how you can design for security
across multiple dimensions.
Today, let's review the first areas
you'll need to consider when securing access
to your GKE cluster.
[MUSIC PLAYING]
It's important to start with defining
what cluster access means.
With GKE, there are two dimensions
in which we access our cluster.
The first dimension is the GKE API.
This is where users can perform cluster operations.
Rather than creating Kubernetes resources,
we use the GKE API to create, read, update, and delete
GKE clusters.
The second dimension is the Kubernetes control plane.
This is how we create, read, update,
and delete Kubernetes resources in a GKE cluster.
Across both the GKE API and the Kubernetes control plane,
we want to ensure that users only have the access they need
and nothing more.
This is called the principle of least privilege.
Let's review the various knobs we have available in GKE
to develop a strategy to achieve this.
Accessing a GKE cluster starts with GCP Identity
and Access Management, or IAM.
Like most GCP services, GKE is tightly integrated
with GCP IAM.
In GKE, roles and permissions can
be assigned to individual users or an entire Google Group.
This can help greatly as the surface of your team changes
over time.
One of the quickest ways to get started
with accessing GKE is using GCP IAM's predefined roles.
In GKE, there are predefined roles,
such as admin, developer, viewer, all of which
can be assigned to user accounts or a Google Group
using GCP IAM.
It is important to note that the role will apply to all GKE
clusters in a GCP project.
Once assigned a predefined role, users
will have a set of permissions that authorize them
to interact with the GKE API.
This means that they can perform operations
that align with their role, whether it's
creating a cluster, adding a node pool,
or manually triggering a cluster upgrade.
These predefined roles also give users
authorization to perform various actions when interacting
with the Kubernetes API.
Again, it is important to note that not only does this
apply to all clusters in a project,
but all namespaces within a GKE cluster.
Now this can be really convenient,
especially if you're a team doing your own development
and your own operations.
GKE's integration with GCP IAM can
be a single method for configuring access
to both the GKE API and Kubernetes resources
within your GKE clusters.
However, if we need more granular control
to achieve the principle of least privilege,
we'll have to be a bit more intentional, configuring
GCP IAM and Kubernetes Role-Based Access
Control, or RBAC, in concert with one another.
We can start by looking at creating a custom GCP IAM role.
Rather than utilizing the predefined roles
that GKE provides, we can consider
creating a custom GCP IAM role with lesser permission.
We can then use Kubernetes RBAC to define user access when
interacting with the Kubernetes control plane in a GKE cluster.
Kubernetes RBAC allows us to enable granular control
over what namespaces and what Kubernetes resources
that users can interact with on a per-cluster basis.
An example of this in action would
be to define a GCP IAM custom role for users
that don't need to manage the GKE cluster lifecycle,
but do need to interact with the Kubernetes control
plane for various clusters in their project.
In this scenario, the custom role
would be minimal, only allowing the user
get permissions with the GKE API, which
enables them to get their credentials to access
the Kubernetes control plane.
But by default, this would not give them
permissions to actually perform any actions
against the Kubernetes control plane.
Instead any permissions when interacting with the Kubernetes
control plane would be defined in Kubernetes RBAC, which
can give us the granularity we need
to achieve the principle of least privilege.
Now once we have found the right balance of our GCP IAM roles
and utilizing Kubernetes RBAC, GKE
provides another layer for us to secure
cluster access, this time around a user's network identity.
Even if a user is already setup with GCP IAM and Kubernetes
RBAC correctly, we may also want to verify the network
from which they are running.
In GKE, authorized networks is a feature
that allows us to only enable communication
with the Kubernetes control plane in our GKE clusters
from a trusted set of IP addresses.
This adds an additional layer of security
to not only ensure that our user is authorized
to perform a certain set of actions,
but is also performing these actions from a trusted network
perimeter.
To recap, configuring GCP IAM, Kubernetes RBAC,
and GKE authorized networks is a great place
to start when building a GKE cluster that
adheres to your organization's security best practices.
Now that we've covered the essentials
for securing cluster access in GKE,
visit the links here to learn more.
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.
Stay tuned as we expand on other GKE topics in "GKE Essentials."