ADIN SCANNELL: Welcome to the Google Cloud Security showcase,
a special VIP series where we'll focus on security use cases
that customers can solve with Google Cloud.
My name is Adin, and I'm a software engineer
at Google Cloud.
Today, we'll be walking through one of the top questions we
get from customers.
How can I isolate my containerized workloads?
Containers are a great way to deploy and manage applications,
but they don't always provide the level of isolation
that we need.
GKE Sandbox is a feature that can help provide defense
in depth for untrusted workloads.
It provides an isolated execution environment
for each container, similar to a virtual machine,
in order to help prevent privilege escalations
and container breakouts.
In this demo, I'll use GKE Sandbox and other features
like network policy to isolate some container workloads.
To get started, let's create a new GKE cluster.
When creating our cluster, we're going
to ensure that we have network policy enabled.
Network policy allows us to control what network resources
pods have access to.
While GKE Sandbox can provide defense in depth,
a good network policy is critical for isolating
workloads on the same cluster.
We'll also enable workload identity,
which is the security best practice for authenticating GKE
workloads to Google services.
Workload identity helps us implement
the principle of least privilege across all our containers.
This will take a couple of minutes,
and we'll come back when it's ready.
Once the cluster is created, we can now
create a GKE Sandbox node pool.
To do this, we first select the container Optimized
OS with containerd image, and then check the Enable Sandbox
with gVisor box.
gVisor is an open source isolation technology
used by GKE Sandbox.
It provides a user space kernel to intercept system calls,
reducing a container's interaction
with the node and the attack service.
This node pool can be used to run regular pods,
as well as sandbox pods, but regular pods
will only be scheduled on these nodes
with an explicit annotation.
This will take a minute or two.
When the node pool is ready, we'll
drop down to the command line to create some Kubernetes
resources.
I'll be using Google Cloud Shell.
The first thing I'll do is create a separate namespace
for the sandboxed applications.
Namespaces are a great way to organize related services
and can provide some security benefits.
I'll call this namespace, Sandbox.
Next, I'll define a restricted network policy by default,
preventing anything inside this namespace
from initiating network connections.
Now, let's deploy a sandbox pod.
To do this, we'll deploy a pod in our namespace
with the runtime class name set to gVisor.
This pod will be automatically scheduled
to the node pool above that we created.
I'm also providing explicit limits in the resource spec,
otherwise this pod may be able to consume arbitrary resources,
and negatively affect other containers.
To validate that he pod is sandboxed,
I'm going to run kubectl exec to start a shell in the pod,
and inspect the execution environment.
We can see here that the pod is interacting
with a synthetic environment, and not the host kernel.
This layer of isolation makes container breakouts
more difficult. We can also validate
that the network policy has been applied appropriately.
Attempting to reach an external service
fails, as does attempting to reach the Google metadata
service.
Finally, I'll expose a sandbox service via an ingress.
Here, I'm deploying and auto scaled engine X group
with an ingress configuration.
These will be scheduled onto the new node pool,
and can be accessed publicly, just like normal pods.
In summary, GKE Sandbox is a great way
to add defense and depth for container isolation,
and supplements critical features like network policy.
Check out the link to learn more.
Thank you for tuning in.
Please visit cloud.google.com/security
for more content from Google Cloud experts.
[MUSIC PLAYING]