[MUSIC PLAYING]
GLEN MESSENGER: Hello.
My name is Glen.
And today, Victor and I will be introducing you
to several new security features available on GKE.
Google Kubernetes Engine, or GKE,
is a fully managed service from Google Cloud,
providing you with a simplified and optimized Kubernetes
experience.
And GKE comes in two distinct modes.
There's Autopilot, which is a fully automated, highly
optimized managed Kubernetes platform, and GKE Standard,
for power users wanting a higher degree of control
in their managed Kubernetes.
When we think about GKE security,
we first think about security at scale and empowering GKE users
by making security easy.
We focus heavily on managed patching, hardening,
and compliance.
We have some of the best security
experts in the industry building these best
practices into our offerings.
And we have powerful tools, allowing
for easy identification, segmentation, and isolation
of services and workloads.
When you're running on GKE, we've
basically taken the responsibility for most
of the technology stack.
We handle patching and hardening in many layers, all the way
from the hardware right up to the Kubernetes system
components.
Right at the top of that stack are your application
containers, and that's what's left for you to patch
and secure.
This effectively reduces your responsibility when using GKE.
But what about securing your container workloads?
This comes with its own challenges--
having access to skilled resources that
know Kubernetes security can be difficult,
the complexity of security topics and multitude
of third-party tools and the steep learning curves
associated with them, and the heightened overhead that
comes with implementing, managing, and using
some of these security tools.
Google Kubernetes Engine provides many ways
to help secure your workloads.
Now, we are happy to introduce several new GKE security
capabilities to make this easier to secure those workloads--
a Kubernetes Security experience that makes security posture
awareness easier.
GKE security posture management provides you with
out-of-the-box security guidance and recommendations.
This gives you visibility and awareness
of container workload misconfigurations and container
OS-layer vulnerabilities.
And this is delivered natively as a part of GKE
using built-in tools, included in both GKE Autopilot
and Standard as a part of the underlying
platform at no charge.
GKE security posture management assesses your workloads
for misconfigurations using open-security standards,
starting with CNCF Pod Security Standards.
It also scans your container images for known,
fixable CVE vulnerabilities found in the OS layers.
These findings are surfaced to you via a dedicated dashboard,
as well as logging Google Cloud Operations.
This allows easy integration with other security tools,
such as SIEMs.
Finally, GKE security posture provides severity ratings
as well as remediation advice to aid in triaging tasks.
Victor, can you walk us through a demonstration of GKE security
posture management?
VICTOR SZALVAY: Thanks, Glen.
I would be happy to.
We are going to experience GKE security posture
management using a fictitious microservices application.
We'll start by enabling security posture analysis.
We'll then use the dashboard to get
an overall sense for our security posture,
and then drill down into specific security concerns
using filters and views.
Last, we'll see security posture concerns in Cloud Logging
and publish those concerns as events to Pub/Sub.
Let's get started.
OK, let's jump right in and start
by taking a look at our sample application.
Now, this is an online boutique.
It's got wonderful items, like these loafers,
for your shopping needs.
This is an application that's actually
comprised of multiple microservices, all of which
are hosted within GKE.
They're spread across a variety of clusters and namespaces.
And our team here, they're pretty new to security.
So they're looking for the GKE team
to provide posture management for them.
And so GKE's new security posture management is just--
just the ticket.
So to get started, we're going to be selecting
the clusters we want to enable.
So we'll go ahead and select all three of these,
get them started.
Now, once we've turned this on, it's
going to take a few minutes for auditing to happen.
During this time, our clusters are actually
being analyzed for security problems.
And let's fast-forward to a time when the audit is over.
And you can see that there are several concerns identified
in it.
In fact, about 131 concerns here spread across a variety
of severity levels.
So we try to categorize these into severities.
They're spread across all three clusters and all 37 workloads.
Now, these are both configuration concerns,
so dealing with the Pod spec and comparing
against things like Pod spec security standards,
as well as vulnerabilities.
And these are OS-level vulnerabilities.
So if we're going to take the next step here,
we're going to dive in and drill down and take
a look at those concerns in more detail.
So the drill-down view here offers a lot of ways to slice
and dice the data.
I can go by concern.
I can go by, of course, the namespace that I have defined
here-- so you can see my services
under those namespaces-- or I can go by workload.
And so here you can see the actual workloads
at the top level and the various namespaces and clusters
in which they work.
I can filter on a variety of fronts like, for example,
the concern type.
I can also look at severity, of course.
And if we're prioritizing, maybe that's
the way to go because let's start with the most
critical and high concerns.
So drilling down into this particular service,
I can see that there are specific problems related
to configuration.
And in this case, you can see that I have some specifications
allowing for host access.
And I'm given specific remediation instructions,
specific allowed values.
And what's nice about this is that it ties it directly
to the running workload, the cluster
it's on, the location of those clusters, and so forth.
So I'm really given concrete next steps
into how to fix those.
Now, let's take a look at a vulnerability.
In this case, there is a vulnerability
in zlib, which is an OS package.
And I can see it's giving me specific instructions
on a fixed version.
So if I know where to find this workload, I can go ahead
and patch it.
And, of course, we do that as well.
So we're given very specific instructions
on where it sits-- the namespace, the cluster,
the location, and even the images that are affected.
So you can see the affected images up there.
So if we were to now go ahead and try
to fix some of these things, we could do that, right?
So we can go and look at the specific problems that
are being outlined and make changes directly to our spec,
as we're doing here.
Let's talk about logging now.
So the security posture featured logs to Cloud Logging.
And I can go in and run a query here
and find all of the specific problems that
have popped up with respect to security posture management.
And what's nice about this is I can create a log sync
and, of course, publish those to Pub/Sub for external event
consumption.
And that's our demo.
So to sum it up, GKE now provides
foundational Kubernetes Security right out of the box,
adding security to the long list of things that makes GKE
the most automated and scalable managed Kubernetes experience.
So we invite you to try GKE Autopilot to experience
the ease, speed, and scale for yourself.
Up next, my colleague, John, is going
to talk about what's new with Anthos.
JOHN MURRAY: Thanks, Victor.
Since it debuted in 2019, we've continued
to expand the capabilities of Anthos
to help Google Cloud customers deploy
their modern applications wherever they need to run.
Let's take a look at the latest developments with Anthos,
which include significant expansions
to our multicluster automation and platform features.
One of the biggest new developments
is our new set of cloud services for managing cluster life
cycle.
Anthos customers run clusters everywhere,
from GCP and other public clouds to on-prem data centers
and edge sites.
We're pleased to announce that Anthos now
includes a fully-hosted set of cloud services
for managing all these clusters directly from Google Cloud.
These services provide the cloud experience
you're used to, with full UIs and support for common clients
like GCloud, while enabling you to manage
distributed infrastructure in a consistent and convenient way.
Our cluster life cycle APIs and UIs
are generally available for Anthos
on VMware, Anthos on AWS, Anthos on Azure,
and with a public preview for Anthos
on bare metal coming later this fall.
We're also happy to announce a number of features
that make it easier for you to manage
your hybrid fleets of clusters.
Over the next few weeks, we'll be rolling out updates
to our UI to provide enhanced overview
information on the status of your compliance policies,
along with CPU, memory, and disk utilization across your fleet,
giving you a single place to view
the health of your infrastructure at a glance.
And as always, all of your fleet's data
is collected in Cloud Ops, where you can search and filter
to examine any problems you see with any of your clusters.
We're also making it easier than ever
to connect your clusters with the Connect Gateway, a fully
hosted cloud endpoint that enables
authorized clients to reach out to any registered cluster,
using a persistent and encrypted connection.
Connect Gateway's integration with Cloud Identity and Google
Groups is now generally available,
allowing users and service accounts
to easily authenticate when managing your distributed
infrastructure.
Policy Controller is expanding its capabilities
to help you ensure your hybrid environments meet
the compliance and governance standards you
need to run your applications.
We're adding new experiences in the UI
to help visualize the compliance status of your fleet
and highlight violations that need attention.
We're also expanding the policy bundles included with Anthos,
with packages for policy essentials, service mesh
controls, CIS benchmarks, and pod security available now,
with a PCI DSS bundle coming soon.
And finally, we're happy to announce
that VM support in Anthos is now generally available.
Anthos for VMs provides a unified, cloud-backed
management plan for VMs running on Anthos bare metal.
We've extended the Anthos management configuration
and policy capabilities to give you
a consistent interface for running your VM
workloads alongside containers.
Anthos for VMs includes a VM runtime
based on the open-source KubeVirt
technology that we've made easier
to install, upgrade, and use.
It also includes VM logging and monitoring out
of the box, along with significant improvements
to networking, making it easier than ever
to move VMs between nodes and apply the same network
policies and services across both VMs and containers.
We're really excited to show you all the new stuff we're
bringing to Anthos.
Let's open up Cloud Console and take a look
at some of the highlights.
Today, we're going to take a quick look
at a few of the new developments in Anthos
by exploring the fleet of clusters
and making some changes to our hybrid environment.
Here, we see the updated Overview page of the Anthos UI.
It allows us to see the overall compute, memory,
and disk utilization of our fleet,
and view the status of our policy coverage.
Each tile provides a quick overview,
with links that allow you to dig in further.
It looks like our Anthos on VMware clusters
are using a lot of compute.
Now might be a good time to expand our fleet with more
clusters in that data center.
Let's take a look.
Here, we're looking at a list of all the clusters
in our fleet, which includes GKE, bare metal, and Anthos
on VMware clusters.
Today, we're going to expand that environment
to create some redundancy for our workloads.
We've added new cluster management capabilities
to Anthos that allow direct management of infrastructure
in other public clouds and on-prem right from Google
Cloud.
So let's try it out by creating another Anthos
on VMware cluster.
In addition to supporting direct API clients,
like GCloud, our cluster management service
provides a simple UI experience for getting started.
Here, we can check that we've got all the prerequisites
for setup fulfilled and then get started by configuring
our clusters' basic settings.
We'll give it a name and then designate the on-prem admin
cluster to associate it with.
Now, let's configure the networking.
We're going to use Anthos on VMware's DHCP support
to automatically retrieve node IP addresses.
We'll also allocate some CIDR ranges
for our pods and services from our on-premises private
network.
Setting up a load balancer for our cluster
is simple since we're using MetalLB bundled directly
into Anthos.
We'll allocate a range of IP addresses,
then configure MetalLB to automatically assign services
to the IP addresses in that range.
Lastly, we'll set our control plane and ingress VIPs.
Next, we'll allocate compute and memory on the admin cluster
to ensure our cluster's local control
plane will have the dedicated resources it
needs to run on-prem.
We'll accept the default settings
for logging, monitoring, and the vSphere storage driver,
and turn off anti-affinity groups,
since they aren't required in this architecture.
And finally, we'll configure our node pool
by giving it a new name and choosing our OS image--
in this case, Ubuntu Containerd.
And with that, we're ready to create our cluster.
While our cluster is being created,
we can view the status in the Details page.
Since this process is going to take a few minutes,
let's give that a little bit.
Our node pools are just about to finish coming up.
And there it is, a fresh cluster running
in our data center, created by our new cloud-based cluster
management service.
Let's go take a look at the workloads
running on our cluster.
It looks good so far, but now let's
add a few more of our own.
Anthos makes it super simple to connect
to any of your clusters, no matter where you are,
with a persistent cloud-hosted endpoint called
Connect Gateway, which is now generally
available with full support for Cloud Identity and Google
Groups.
Here, we're accessing it through Cloud Shell.
With a single gcloud command, I can get a kubecutl connection
to any cluster in the fleet and start deploying applications.
It's very convenient for automating processes
like continuous delivery, too.
Now that I have a connection, I can view the nodes
and retrieve the namespaces on the cluster I just created.
I can also view the status of the Connect agent
that makes this connection possible.
It creates a persistent encrypted gRPC tunnel
between my cluster and Google.
Now, we'll deploy our online store application
by creating a namespace, adding it to the service mesh,
and deploying our manifest.
When we return to our workload list,
you can see our application is now up and running.
Let's check out the frontend service.
If we dive into one of the pods, we can take a look at the logs
and get a quick glance at the most recent messages.
Now, as we return to our newly created cluster,
you can see it's just as easy to edit and upgrade
the cluster via the new cluster management service
as it was to create it.
Let's go ahead and scale out the node pool to ensure our app
has plenty of room to handle new traffic.
We'll select the node pool, click Resize,
and bump the number of nodes from 3 to 4.
So our new cluster is scaling out in the background,
and we're ready to handle more traffic.
Looks like our work is done for now.
There's lots more new stuff to explore in Anthos, including
our new, generally available support
for running VMs and our expanded library of policy bundles.
I hope you'll head over to cloud.google.com
to check it out for yourself.
On behalf of Glen and Victor, we hope
you enjoyed this presentation.
And thanks for joining us today.
[MUSIC PLAYING]