MING NG: Hi, everyone.
My name is Ming Ng.
I'm a Vice President in the Cloud Enablement
team at Goldman Sachs.
With me is my colleague, Karthik Ramamoorthy,
a Vice President in the Tech Risk Advisory team.
Today, we're going to talk about how we use Anthos Config
Management to secure and operate Google Cloud
resources at Goldman Sachs.
Before we dive in, we're going to start
by introducing our firm and our respective teams.
Then we'll go over the common challenges
with cloud provisioning with the current tool set
and how the new paradigms in Anthos Config Management
address those challenges.
We'll then share with you how and why we use Anthos Config
Management at Goldman Sachs.
And finally we'll close out by summarizing the key takeaways
of today's discussion.
For those who might not be familiar with our firm,
Goldman Sachs Group is a leading global investment bank
that provides a wide range of financial services
across investment banking, security, investment
management, and consumer banking to a large and diversified
client base that includes corporations,
financial institutions, governments, and individuals.
Founded in 1869, the firm is headquartered in New York
and maintains offices in all major financial centers
around the world.
Despite its long history, innovation
is at the heart of Goldman Sachs culture.
In fact, one in every four employees is an engineer.
I'm from the Cloud Enablement team at Goldman Sachs.
Our main focus is cloud governance at scale.
I think what really sets us apart from other car
engineering organizations is our shift-left security
posture, where we engage our colleagues in Tech Risk
Advisory team early on in the process
to ensure that our architecture is secure by design.
And we have been partnering with Google Cloud
for the past few years to provide scalable, agile,
and innovative business solutions to our clients.
Now I'm going to pass it on to Karthik
to first talk about the role of his team.
And then he'll frame today's discussions
by introducing the common challenges
of cloud provisioning and the new paradigm in Anthos Config
Management.
KARTHIK RAMAMOORTHY: Thanks, Ming.
Hello, everyone.
I am Karthis Ramamoorthy, part of Tech Risk
Advisory within Goldman Sachs.
Tech Risk Advisory is the agent of shift-left security.
We engage with the business unit within Goldman,
covering a wide range of technologies
to ensure security is prioritized early
in the SDLC process.
We provide risk-driven approach to treat the security gaps.
In this current context, we partner closely with Cloud
Enablement team to define and describe the governance
and security controls to prepare for the general availability
of Google Cloud before opening up for business.
We often collaborate with other security teams
within the firm to prioritize the requirements
and build up the security controls
based on MosCoW prioritization tactics.
As part of general availability within Goldman,
we partnered with Google account teams
to perform service assessments on the Google
services [INAUDIBLE].
This ensures Google operator access
and underlying architectures are intact to enforce
protection of our client.
We also perform threat modeling, design reviews,
and penetration testing to mitigate
security vulnerabilities in platforms and applications
in a timely manner.
Finally, we evangelize all of our learnings and security
findings to define security reference architectures,
patterns, and practices to accelerate the cloud adoption.
We also deliver security policies
as a code to enforce directive and preventive
controls to maintain the cloud security posture.
Securing the operations for production workload
is paramount for us.
Now let's zoom into some of the day
2 SecOps challenges with contemporary methods
of cloud provisioning.
Remains a friction point for cloud engineers
is the fragmented toolset for infrastructure and application
deployments.
Especially to deploy cloud-native workloads,
engineers need to constantly contact-switch
between IAC and deployment pipelines
to achieve the desired target state.
From the security perspective, supporting multiple variants
of IAC programming languages is a challenge.
It's hard for security teams to deliver policy as a code
without impacting developer productivity.
VUs often demand consistency with high release velocity.
And it's hard to get it right all the time at scale.
Another concern is the asynchronous nature
of contemporary cloud deployment models.
It means, except at the deployment time,
there is no strong contract or reconciliation between intent
defined in the source code versus actual target
state in the runtime.
This is evident especially when engineers use divergent sets
to deploy applications and infrastructure [INAUDIBLE]..
This often results in configuration groups.
Anthos Config Management, or ACM,
attempts to solve these challenges.
Now let's dig into some of the key concepts
and features of ACM.
ACM, or Anthos Config Management,
embraces Config as Data, where you can use any tool, language,
or APIs to manipulate the configuration data,
but the final state of configuration
always remains consistent.
This is nothing new in the world of Kubernetes.
You can use any tools or templating languages
such as Helm, Kustomize, or Ansible
to generate the config files.
However, the final data structure and resource model
always remains consistent in the Kubernetes API server.
This standardizes the application
of normalized security policies regardless
of the tool of choice.
Anthos Config Management adopts the same Kubernetes resource
model to standardize the Config as Data for both infrastructure
and application deployments.
Config Controller is a key component
in Anthos Config Management that binds non-Kubernetes resources
to the Kubernetes resource model.
Config Controller orchestrates Google Cloud resources
as Kubernetes resources and manages the entire lifecycle
through native Kubernetes APIs.
Config Sync, another component in ACM,
continuously reconciles the state of our source code
with Kubernetes resource model in real time.
This ensures the associated source code report
as a single source of code, thus eliminating the configuration
groups.
This allows consistent GitHub-style deployment
of infrastructure, applications, and cloud services.
Finally, with the latest ACM releases,
all these features are bundled and packaged
as a managed service offering called KCC as part of GKE,
or Google Kubernetes Engine.
Behind the scenes, the Config Controller
uses a GCP-native feature called Workload Identity to secure
the deployment networks.
Workload identity binds the Kubernetes service
accounts to act as a Google service account.
Thus, KCC inherits the associated IAM permissions
seamlessly without exporting any keys or passwords
into the clusters.
With Workload Identity, you can scope, project,
or product-specific service support
to the dedicated namespaces within KCC.
This provides a limited blast radius and prevents
the usage of overprivileged service networks
or deployments.
Continuing our philosophy of security policies as a code,
Azure Config Management enables defining the organization
policies, gatekeeper policies, or VPC Service Controls
as code.
Organization policies are governance controls
for Google Cloud resources that can
be deployed as KRM definitions at a granular level
within the GCP resource hierarchy
at the organization level, folder, or project levels.
The Policy Controller Component in ACM
enables defining of custom OPA, or Open Policy Agent, policies
to enforce custom application standards or constraints
for cloud service configurations and deployments.
Collectively, ACM offers a comprehensive feature
set to manage and deliver cloud governance
and security at scale.
Now I pass on to Ming to show how
we are utilizing Anthos Config Management within Goldman
Sachs.
Thank you.
MING NG: Thanks, Karthik.
Before I dive into how we operate our Google Cloud
environment with Anthos Config Management,
I'd like to go over our cloud governance tenets
so they can see why we choose Anthos Config
Management for the job.
There are four major cloud governance
tenets for Goldman Sachs.
First and foremost, everything should be cloud native.
We don't want to abstract away the power of the cloud.
And our engineers should experience
the cloud in its purest form.
If any customizations are needed,
we'll partner with a cloud provider
during the early product development cycle
to incorporate our requirements.
That's exactly what we have done as an active participant
in the private preview of Anthos Config Management.
Second, our cloud environment should be secure by design.
We want to have strong enterprise guardrails
for our cloud environment so that our engineers can operate
freely and efficiently within the pre-approved architecture
parents.
You'll see our emphasis on enterprise guardrails
in the next section of this presentation.
Third, we want a well-defined shared responsibility model.
This tenet goes beyond the typical shared responsibility
model between a cloud provider and its users.
This tenet extends the model to our internal Goldman teams
as well, especially between the Cloud Enablement
team and the Application teams.
Cloud resources are either owned by the Application teams
or the Cloud Enablement team.
There is no ambiguity.
As you'll see in the next few slides,
this separation is very important
to allow the enterprise guardrails and the applications
to evolve independently.
The fourth tenet is self service.
Our engineers should be able to build, deploy, and manage
their cloud services without ever needing
to go through another team, including
us, the Cloud Enablement team.
With those four tenets in mind, let
me give you an overview of our Google Cloud environment.
At a very high level, we have two separate GCP organizations.
On the left, we have our production organization.
That's where the different business
units will build, deploy, and manage
various business workloads.
In this organization, we have a folder hierarchy
that mirrors our businesses and team structure
for the ease of management.
Each application will have a GCP project
to house all the cloud resources it needs
to run the business workload.
To protect all the critical data and workloads,
we need to have strong enterprise guardrails that
include, number one, an all-encompassing VPC Service
Control perimeter to prevent data exfiltration.
And number two, a set of baseline organization policies
that are defined at the top of the organization
and inherited by the folder hierarchy.
Number three, a set of pipeline policies
that enforces consistent naming conventions and building
labels for all cloud resources.
In addition, we also want to limit the blast radius
so that each application can be insulated from the changes
by other teams.
Now, on the right, we have a separate Innovation
organization where our engineers can have elevated access
and can learn and experiment with Google services
in a safe environment isolated from the rest of the firm.
There's absolutely no business data in this organization.
There's also organization that we can test new enterprise
guardrails, such as custom organization policies,
before deploying to production.
As you can see, even in this highly simplified
version of our Google Cloud environment,
there are already many types of resources and controls
that need to be built, tested, deployed, and managed
over time in a consistent manner across both organizations.
How do we balance the need for security
with a need of our engineers for autonomy and flexibility
to innovate?
This is where Anthos Config Management truly shines.
First, we can describe our intent
for our Google Cloud environment using a single resource
model across the board.
This will include all the enterprise hierarchy
and guardrails I mentioned before, the GCP folders
hierarchy, the organization policies, and the VPC SC
perimeter.
Now that we have our intent in a single resource model,
we can manage our intent, which can evolve over time,
in our Git repository.
This gives us a clear audit trail and review process.
We can create feature branches and merge requests
to manage the lifecycle of our intents,
just like any other software product.
And to top it all off, our Google Cloud environment
will be reconciled continuously with the stated intent
in our Git repository to prevent configuration drift with Config
Sync.
And through Workload Identity, we
can bind each namespace to a GCP service
account that manages all cloud resources in a GCP project.
This way we can limit the blast radius of any changes made
by our service account.
And finally, we can enforce standards
such as naming convention and building labels for all Cloud
resources using gatekeeper policies with Policy
Controller.
This diagram shows how Anthos Config Management
manifests our intent into a reality for our Google Cloud
environment.
On the left, we have our central organization level Git repo
managed by the Cloud Enablement team that
expresses our intent for the enterprise hierarchy
and guardrails.
On the right, we have multiple project-level repositories,
each managed by an Application team
to build, test, and deploy cloud resources
within their respective GCP projects.
In the center, we have Anthos Config Management
reconciling the state of our Google Cloud environment
continuously with the stated intent from both repositories.
As you can see, Anthos Config Management
allows us to formalize the shared responsibility
model between the Cloud Enablement
team and the Application team.
The Cloud Enablement team manages all the enterprise
hierarchy and guardrails using the central and
organization-level Git repo so that our environment is
secure by design.
Whereas the Application teams build, deploy, and manage
all their project resources using
their respective project-level repository
so that their application lifecycle is self-service.
And for added efficiency, we can create Innovation branch
from the Production branch to test new enterprise guardrails
such as new org policies in a separate innovation
organization before we merge the new policy to production
to avoid any business disruption.
Some key takeaways.
With any adoption of new paradigms,
there will always be challenges along the way.
In our case, converting from Terraform
to Kubernetes resource model was challenging on multiple fronts,
both in the learning of a new model
and the incomplete coverage of some Google Cloud resources.
But thanks to the close partnership with the Anthos
Config Management Product team and the support
of our Google Account team.
We were able to overcome the steep learning
curve in the beginning and have most
of the feature gaps in the early preview version
of the product addressed.
Now, here's the list of our favorite features
in Anthos Config Management.
With Config Controller, we can use Kubernetes resource model
across applications and infrastructure deployments.
With Config Sync, the state of our cloud resources
are continuously reconciled with our intent
to prevent configuration drift.
With Workload Identity, we can limit
the blast radius of any change made by Application team.
And with Policy Controller, we can
enforce consistent standards across provisioning
of all cloud resources.
As a result, our Google Cloud environment
is cloud native, secure by design,
has a well-defined shared responsibility model,
and is self service for our engineers.
And that's why we choose Anthos Config
Management to secure and operate our Google Cloud environment.
I hope our discussion today shed some light
on the common challenges of cloud provisioning at scale
and how they can be addressed using Anthos Config Management.
Hope this has been helpful.
And thank you for joining us today.