Maintain Control Over Hybrid Workloads With Devops Best Practices from Google Cloud (Cloud Next ’19)


Written by:

and welcome, everyone. As you know, hybrid
and multicloud are big themes
this year at Next. Today, we want to put ourselves
in the shoes of a cloud administrator to understand
the challenges of managing large cloud workloads in
a context where hybrid and multicloud are the norm. We will see how you can
leverage devops tooling and best practices to manage your
cloud workloads consistently across environments– how
you can improve your security posture, how you can establish
governance, and make compliance easier at scale. Yesterday we announced Anthos. And we showed our Anthos
conflict management allows you to manage
your Kubernetes environments on premise and
in the cloud through code. Today, we will walk you
through a live demo that shows how you can use Anthos
to manage your traditional GCP resources and policies as code. My name is Marco Cavalli,
and I’m a product manager in Google Cloud. And today, Alex and
Zhuzeng will join us. They are also from Google. And Alex will talk about
the config validator. And Zhuzeng will walk
us through the demo. So we said we want
to put ourselves in the customer administrator or
the cloud administrator shoes. And I use the term
cloud administrator broadly to refer to the most
common administrative functions in Google Cloud. You can think of it as the
person or the team that is responsible for security and
compliance for your company. Now the cloud administrator
is at the center of a complex ecosystem. On one side, you have
requirements that your company needs to meet. There are security,
compliance, governance, auditability requirements. And these are top of mind
for pretty much all companies across any industry. And then you have stakeholders
that rely on the administrator to do their job. There are developers
that need to move fast but also want to know that
there are guardrails in place to protect them. There are auditors that need to
have access to logs and change history so that they can
sign off on your compliance requirements with confidence. And there are
financial controllers who want to be able to set
budgets for quarters and track usage so that when the
cloud bill comes in, they are not surprised. To support your stakeholders
and to meet your requirements as the cloud administrator, you
have a large set of controls. You have authorization and
authentication policies that control who can
use your resources and how they can
use your resources and which resources
they can use. You have organization
policies that allow you to set
guardrails to make sure that your users stay within
the compliance boundaries. You have firewall
rules that control traffic between
different services or different resources. All of these have different
interfaces, different best practices, different syntaxes. These are knobs that you
use to control resources. And resources can
be in Google Cloud, but can be also in
your data center. Maybe you’re running
traditional VMs or you’re running Kubernetes. Probably you have other
cloud providers too. So complexity can easily
become overwhelming, especially if you’re managing
everything manually, moving from one UI to the other,
calling individual APIs. This is non-scalable
and error prone. It also leads to
some challenges. One of the challenges
is visibility. So how do you make
sure that you maintain a comprehensive overview of
what’s going on in your cloud environments if you have to
deal with different interfaces and different syntax is and
different best practices? How do you ensure that loopholes
are not created somewhere without you realizing? Or how do you ensure that
your resources don’t drift after compliance over time? And related to this
is auditability. How do you keep track of changes
and how do you report them in a way that is
easily consumable by non-technical stakeholders? And then as your business grows,
how do you make sure that you don’t become the bottleneck? You said we want to enable
developers to move fast. So how do you do that
in a scalable way to sustain a business growth
without slowing it down? So again, doing things
manually is a problem. So standardization
and automation are key to enable scalability. And finally, how do
you discover when new features or new
configurations or policies become available? With cloud providers rolling out
new features at an increasing pace, how do you keep
up and how do you ensure that your environments
are up to date all the time? Well, you can go through
pages of documentations. Or you can read blog posts. Or you can reach out
to your cloud support. But again, this is not scalable. How can we help you make it
simpler and more immediate? And this, again, is in a world
where hybrid and multicloud are just standard. So complexity is, in itself,
an issue and a challenge. But the more important
part is that complexity may lead to an increased
vulnerability for your company. It is surprisingly easy to open
up a VM with sensitive data through the internet, or to
give access to a storage bucket [INAUDIBLE] data to
the entire world. These are examples
of misconfigurations. And we know that
misconfigurations are, in many cases, the root
cause of vulnerability or data breaches and leaks. And misconfigurations
are, for the majority, caused by human error. So how do we improve
your security? And how do we reduce the
risk of misconfiguration? Again, doing things manually,
pressing buttons in UIs is dangerous, is not
easily trackable, and is not controllable. So again, automation and
standardization are critical. So as I was learning about
this space a while ago, I was trying to understand
the separation of concern between the administrator
and the developer. And my friend Ray came up
with an interesting analogy. So he told me, you
know when a company moves to the cloud it’s like
buying a large apartment building with the goal of
renting out apartments. And I was like, oh,
that sounds interesting. But tell me more. And he said, think about it. The building has
an administrator. That’s the building
administrator. And that is equivalent to
the cloud administrator. And tenants or
prospective tenants are like your
developers in the cloud. So as the building
administrator, you want to provide
apartments to your tenants so that they can move
in and live there. And in the cloud, as
the cloud administrator, you want to provision resources
that are like the apartments. You want to provision
them to your developers so that they can go on and
build their own application. And you want to do that within
the law in the apartment building and within compliance
requirements in the cloud. So your goal is to
maximize your utilization, free up your developers,
but stay within compliance. And before you start
renting out apartments as the administrator,
you probably want to set up some rules to
create a healthy environment. For example, you want
to set access rules and make sure that every tenant
has a key to enter the building or make sure that when
there are visitors, they check in at the front desk. And then you can use said rules
to control how the building itself is used. There are rules that, for
example, say there shouldn’t be parties after 10:00 PM,
or another rule that says, tenants shouldn’t
set up a machine shop in their apartment, or they
shouldn’t be tearing down walls like randomly. So these are like the basic
rules for a happy cohabitation. And in the cloud, the
equivalent of those rules are the policies. You have policies that apply
to users, like authentication and authorization. You can enforce, for
example, that all your users use a second factor
authentication to sign in. And when they are
in, you can control which resources they
can access to do what. And then there are policies
that apply to resources. You may want, for example,
to organize resources in a way that
creates separations between the different tenants. And you can do that
in GCP using folders. Or you can use the
namespaces in Kubernetes. And then you can use policies
like organization policies to set guardrails in
compliance and governance. Or you can use billing
and quota to control usage, or networking
and monitoring, and so on and so forth. Now to wrap up this
analogy, before you rent out the apartments,
you probably want to establish a process that is
easily scalable, repeatable, and as automated as possible. And you can do that
by, for example, providing a few options. You can say that you have
a few sizes of apartments. And they are like the
quota in the cloud. Or you can have some
furnished apartment and some that are non-furnished. And then you can provide or
prepare different templates for different contracts. So when a new tenant
shows up, they give you their requirements. You take the
corresponding contract. They sign it. And they are off to the races. And of course, you
want to make sure that you control what’s going
on so that things run smoothly and nothing crazy happens. Now in the cloud, Anthos
Configuration Management allows you to do that. It allows you to streamline
management of your environments across cloud or on-premise
using code as the way to do it. And it uses the Kubernetes
declarative style to ensure that there is
a consistent experience across different environments. Because it uses code,
it stores that code in a unified source
of truth, which is stored in a GIT repository. And the GIT repository
is the user experience around managing
your configurations and your infrastructure
across cyber environment. And again, because
we use code, then you can leverage things
like presubmit checks to prevent bad
configuration from being pushed into production. Or you can ensure that
whenever a change is submitted and merged, it gets
automatically picked up by the CI/CD pipeline
and automatically deployed to the
corresponding infrastructure. Now let’s look at
the config management stack a little bit
in more detail. There is an authoring
layer that is where you define your configurations. And we said we rely on code. We use a GIT repository. And we use the Kubernetes
declarative style. And we’ll look at that a
little bit in a moment. The second key step
is the the validation. And again, it’s a
way for you to define rules that prevent bad
configurations from being pushed into production. And this helps you in
two ways, primarily. One is that allows you
to establish governance. You can codify rules that
represents your requirement. And those rules need to
be met before anything is pushed and merged
into the master branch. And the second level
is it helps reduce toil for the administrator. It does that because,
as the administrator, you know that whenever a pull
request reaches your inbox, it’s already gone
through all your checks. So you can focus on the
real important things, what needs to have human attention. You don’t need to check
every single thing. And you could use
automation, in fact, to limit the pull requests that
need to be reviewed manually. And I was talking to
a customer recently. And they have two
security administrators for the entire company. And for them, being
able to set those rules and automate those
checks is critical. Because otherwise,
as today, they have to review every
single pull request, which is obviously non-scalable. Now once the pull request has
been reviewed and submitted and approved, then
it gets picked up. It’s merged into
the master branch. And is picked up
and actuated into the corresponding platform. And this is where
things become real. On one side, you
have your intent. And the actuation layer
picks up your intent and translates it
into API calls that call the corresponding
settings and policy systems in the different platforms. And finally, intelligence
gives you a recommendation. It uses machine learning to
look at your user pattern to improve your
security posture. Let’s look at this layer
a little in more detail. So we say that the authoring
layer is done through code. And it’s done in GIT. Now we are not prescriptive
as to where you should host your GIT repository. But we are prescriptive on the
structure of the repository. The structure as
semantics and it represents how your resources
are organized in the cloud. So we use folders to represent
projects and folders in GCP, or namespaces in Kubernetes. And files are YAML files. And they represent resources
and their policy bindings. And as we see in a moment, we
use the Kubernetes declarative style, again, to represent your
resources and your policies. Because GIT is your source of
truth, then you can use easily devops tooling and
best practices. You can build pre-submit checks,
like we said a moment ago. But you can also leverage things
like pull requests and approval workflows so that changes
don’t get merged automatically into your master branch. But it has to be
reviewed and approved by another administrator
before they become effective. And then, you can use
things like rollbacks or gradual rollout so that
you don’t immediately affect all your users in one second. Now, if you are an
existing customer and you have a number of
resources already deployed and you’re managing
them manually, you probably wonder,
how am I going to start. Well, we provide you
with an importer tool. And Zhuzeng will
show how that works. And this importer
takes everything you have in your
GCP environments and dumps it into
a brand new repo. And you can then hit the
road running very quickly. And finally, because
everything is as code, you can use templates. And templates are
like the contract that we talked about
earlier for your developer. So you can build
your own templates. But you can also access
templates from public library or open source libraries. And Alex will talk
about that in a moment. We are also working to
provide an extensive library of templates with best
practices for different industry verticals. There was a session yesterday
that talked about templates for financial services. And over the course of
2019, we will extend those to other industrial
verticals too. So just a second on the
Kubernetes resource model. It provides two benefits. One is that it is declarative
and it represents your desired state. So the advantage here is
that you express your intent and you store it in
a GIT repository. And then you can use
tooling to make sure that your intent is deployed
and it is consistently refreshed and mapped into your resources. So that your resources
always reflect your intent. And the second
benefit is that it allows you to extract the
infrastructure using CRDs, so Customer Resource Definitions. You can create a
logical extraction of your infrastructure. And you can use that to express
configurations and settings in a consistent way across
different environments, in a way that is infrastructure
agnostic so that it can easily be mapped onto different
platform seamlessly. Now the validation is
something that Alex will talk about in more detail. So I won’t spend much time. But just two quick notes. The validation, we said, helps
you prevent bad configuration from being pushed. And you can do that by
defining your own rules. And those rules are like
two levels of controls. One is like basic limiters. You can use them to prevent
things like syntax errors. Or if you are trying to
create a resource that’s already existent, it
will give you an error. Those errors are
caught immediately. So they don’t even get
pushed into anything. They are caught and
stopped automatically. And the second level
of control, you can actually express rules
that represent your governance intent and your
governance requirements. So that whenever a
push goes through them, it only passes if it meets
your compliance requirements. We said the actuation is
where things become real. So after somebody has
submitted a pull request, that pull request
has been verified through all the
automated checks, and then has gone through
the administrator who has approved it, then it
is picked up automatically by the CI/CD
pipeline and deployed to the corresponding
infrastructure. And in the demo, we will
focus on the actuation for GCP resources specifically. Now, intelligence
is the last layer. And intelligence,
we said it helps you optimize your security posture. And you can do that
in different levels. And we can use an analogy
from the car industry to make it more clear. So the first level is it helps
you understand what is going on in your deployments. It helps you understand
which resources do you have and what is the status
of those resources and what the history
behind those resources. It’s like the
dashboard in a car. You have the speedometer. You have the fuel gauge. You have the temperature. But then decisions are
left to the driver. This is information that you can
use to make your own decision. But the tool is not
giving you more than that. But then the second layer
is actually the validator. And that helps you
prevent mistakes. It’s like the blind spot sensor
in a car in the rear view mirror of the car. So before you commit
to changing lane, you make sure that
nobody is coming so you can do that safely. The third layer is
the troubleshooter. The troubleshooter
is Alpha for IM. And it helps you understand
when things are going wrong, why they are going wrong. For example, if I try
to spin up a new VM and I get a
permission denied, it helps you understand
which permissions you need so that you
can do it correctly or you can submit a pull request
to request those permissions. And it’s like the diagnostic
system in the car. It helps you understand
why the car is not working. And finally, the more
intelligence part, it uses machine learning
to analyze your usage. And it gives you
a recommendation on how you can improve
your security posture. And the IAM recommender
is also available today. And the IAM recommender
looks at, let’s say, Marco, he has 25 IAM rules. But over the last six
months, he’s only used two. So you may want to
reduce that, which brings you closer to the
principle of least [INAUDIBLE] privilege. And it generally reduces
your [INAUDIBLE].. And this is like maps in a car
that help you go somewhere. So let’s bring it
all together now. We said we have a
source of truth. It’s in a GIT repository. We are prescriptive about the
structure of the repository. But you can host
it in any solution. So we support GitHub or
GitLab or Cloud Source repo. And everything is
stored as code. And then, you can plug
into any CI/CD pipeline. And then the validator
integrates with them. So in the demo, we will show
GitHub and Google Cloud Build, but you can also use Travis, or
Jenkins, or Bamboo, and others. The actuation picks
up the changes and deploys them
to the platform. That can be GCP or it can
be Kubernetes on premise. And then the intelligence part. And the intelligence part
has the analysis part that is for [INAUDIBLE]
is an open source tool. But you also have Cloud Asset
Inventory as I mentioned. And then the intelligence that
gives you a recommendation. And those recommendations are
represented as pull requests. And those pull requests
come from the tooling, not from a human. And they are fed back
into the GIT repository. So you can review them. And you can decide which
ones make sense to you, where do they impact
your resources, and whether you want
to accept them or not. And with this, I would like
to invite Alex on stage. Alex will walk you
through the validator and will introduce the demo. ALEX SUNG: Thank you, Marco. Hello, ladies and gentlemen. So I’m Alex, a fellow
product manager working here on GCP and CSP. As Marco mentioned,
earlier today we talked a lot about validator. I’m going to dive a
little bit deeper today. At the same time, I’m also going
to be introducing our sample customer over here,
Chili Oregano. So Chili Oregano is
an e-commerce service where with one tap you can
order the freshest, spiciest, and most organic chilies
to your doorsteps. Now Chili Oregano recently
faced a data breach issue. For some reason, somehow inside,
some of of their developers got gmail access into their
restricted and sensitive data. This essentially spun into
a breakout headline section where, hey, Chili
Oregano is not keeping their customers’ data safe. These things happen. They sound like
exaggerated situations. But they are real scenarios
that can happen to you. So we want to explore,
how can Chili Oregano stop these type of incidences from
happening in the first place. Now let’s introduce
some of the players that we’ll be talking about
very soon within our demo. The first is meet Alice. Alice is our cloud
administrator. And going back to
the building analogy that Marco mentioned
earlier, she is similar to the
building administrator. Alice cares deeply
about setting guardrails around keeping the
environment safe and secure. And at the same
time, though, Alice does care about her developers,
one of their key stakeholders. She wants to make
sure that they are free to go build the best
applications and services possible. Today, Alice is managing all
of her resources manually. Tomorrow though,
Alice is looking to onboard into Anthos
Config Management and be able to leverage
the powers of scalability and automation. The second key player
we want to meet is Bob. Now Bob is one of Chili
Oregano’s top developers. As I mentioned before, Bob
cares about moving fast. He doesn’t really
care about policies. He just wants to build cool
services and applications. But at the same time, Bob
knows about the dangers of having insecure code. He doesn’t want to
be the perpetrator of a deathly sort of headline. So Bob cares about
his code being secure, safe before it rolls
into production. And with that, let
me talk a little bit about validator, a solution
for a custom security and governance guardrails. How can validator help solve
both Alice the administrator and Bob the developer’s goals? Validator comes as a
two-pronged solution. The first side is during
pre-deployment checks. How can we check whether
a configuration has any violations before
we even provision it or actuate it into
our platforms? In short, how do we stop
these misconfigurations before they happen? The second is going to
be on ongoing monitoring. And this acts sort of
as a checks and balance. If a violation does enter your
platform, how do we find it? How do we identify it? And here, when I talk
about violations, there are two key
ones that we have to keep on top of our mind. The first is break
glass violations. So as we mentioned, this
is an infrastructure as code solution. Everything is
being done as code. But developers, knowing
how smart they are, sometimes they find things
around just to get things done. What if a developer goes
directly into the cloud console, uses G Cloud,
or maybe even writes up their own script in order
to make some changes within your platform? Now, for developers,
they may feel happy. But as Alice the administrator,
we want to keep things secure. So with ongoing
monitoring, we’re able to identify
these violations so that way Alice
the administrator can decide what to do with them. The second type of
violation that we care about are retroactive violations. So initially, your platform
has all of its resources in a current state. But as you employ new
constraints or new policies or new rules, some of
these old resources may now be in violation. How do we find and
identify these violations? So that way, Alice can
choose whether to remediate or to keep it as an exception. Now the glue that ties both
of these sides together and the key to
validator is actually this single source
of truth, this repo of validator constraints. Imagine these constraints
as the ability to write your governance, best
practice, and security rules one time and have
it run everywhere across tools, both in
the provisioning side and in the monitoring side. From audit
perspective, this also makes it simple for you to
have one source of truth for you to showcase, hey, here’s
all of the actual governance rules that are applied
within my company. Diving a little bit
deeper, as Marco mentioned, everything is going to be
defined as Kubernetes style YAML. So Alice the administrator
can very simply configure one of
these to instantiate a new policy or a new rule. Now there is a little
bit of business logic in the back end, which I’ll
get to in a few slides. But at the front,
very simply, if Alice wants to create one of
these new constraints, such as to stop the access
from a gmail account or other outside domain,
how can she do that today? So here we have a sample with
domain restriction constraint. And let me walk you through a
few of the different parameters we have here. Starting at the top, we
have the template kind. So this defines
the type of check that is going to be done in
the background to enforce. And as I mentioned
already, this is going to be the domain
restriction constraint. The second is a free form
text for the company’s name. So over here, Alice simply
names it a Chile Oregano domain restriction. The third is a piece
of metadata that’s going to be very
critical, and no pun intended, during your
remediation stages. Alice wants to be able to
set whether a certain policy or whether certain
constraint is going to be low, medium, or high. When this information is surface
to the ongoing monitoring tools, the tool
will then know, hey, is this something
of low severity. So that way maybe we
should kick it off to some sort of internal
workflow for ticketing approval. Or is it so severe,
such as giving access to a gmail account on
our PII restrictive data that we want to do
autoremediation? We want to either remove
access immediately or we may even want to lock down
the resource in some other way. The fourth of these
is the target. What’s the scope
of where you want this constraint to take place? So over here, based on
GCP’s research hierarchy, you could define it as the
organization, the folder, or the project level. In addition, you can
also set exceptions. For example, it should only
apply to a set of projects while excluding some other ones. And very lastly, we actually
get to the parameters. And this is what
Alice will care most about when she’s configuring
one of these constraints. These parameters will tie
directly back to the constraint kind that we defined earlier. So in this scenario, since we
are limiting or restricting only a set of allowed
domains, Alice has set the gservice accounts,
so only Google service accounts is allowed, as well as
her own company Chili Oregano. Now you may be wondering,
OK, we talked a little bit about these constraint
kinds and templates. Where do I actually get them? Well, this is
where Google, we’re going with the open
source strategy. The policy library is already
public and live today. It is, again, open source,
community generated, and it’s going to be a single
location where we can imagine different large players
across different industries– whether it’s health
care, retail, finance– to be able to
contribute and build different types of
constraints for their niche or their industry
specific needs over time. At the same time
though, Google also will be a key contributor
to this policy library. We will be looking
at our best practices from a security perspective,
product perspective, and even from our own professional
services teams. These will be Google’s
opinionated constraints, as we slowly push these
into the policy library. Starting today, though,
just for you to play with, we will have a handful
of these constraints. I’ve already talked about
the IAM domain restriction. We will also have restriction
of VM instances with public IPs, enforcement of network
routing, and enforcement of storage logging. Now, I alluded to this
a little bit earlier. For the simple
use case for Alice where she just wants to use some
sort of preexisting constraint template, she just has to
instantiate the YAML file we showed earlier. But what if Alice
wants to do more? What if she wants to
customize something? What if she wants to have the
agility to constrain something, but Google or other players
within the community has not provided inside
that policy library yet? Well, this is where we want
to empower the infrastructure architects, cloud admin
teams [INAUDIBLE] to roll out and build their own custom
constraint templates. I won’t go through the
exact details here. But these templates
will be written in Rego. It is a dynamic and
popular policy language. And the example I have here
is for the actual enforcement of storage logging. So as you can see, it’s
only a small number of code to do something that’s
very, very critical. Circling back, let’s
revisit what Alice and Bob will be doing today
now that we’ve talked a little bit about
the validator solution. So in our demo, we’re
going to show Alice first initializing that GIT
repo, as we call it, the source of truth, with
the importer service. She will then be checking
out the policy library to get all of those constraint
templates we talked about and configure the domain
restriction constraint. Next, we will swap
over to Bob, again, our top developer
who is now looking to create a new project. Let’s call this the
Fulfillment Project where he will also be
binding some IAM policies. Now, Bob may be doing
something a little bit naughty. So I won’t be go into
details on exactly what. You could probably guess though. But as he’s going through this
process of checking his code, trying to roll out
his new project, he’ll be diagnosing
some of the violations that validator captures. Eventually, though,
he’ll be able to pull successful and
healthy pull requests. And circling back to Alice,
who will get this pull request, she will review, approve
before eventually merging this into their master branch. Afterwards, with Anthos
Config Management, we will see the actualization
into the platform itself. And to bring this all
together, as Marco alluded to earlier, how does this
all fit into different stages lifecycles? So again, Alice,
she will be doing the authoring step
with the import into the source of truth. Bob will be doing the
publishing and working against this source of truth
before passing it back to Alice to do the automation around
validation and actualization into GCP. So with that, I would like to
invite Zhuzeng, my colleague, to actually run us through
a live demo of what Anthos plus validator will look like. ZHUZENG LU: Thanks, Alex. Hello, everyone. My name is Zhuzeng. I’m a server engineer
from Google Cloud. So next, I’m going to
run the simple life demo about Anthos Config Management. So let’s get started. So now imagine I’m Alice,
the cloud administrator from Chili Oregano. So my company has
resources in GCP there we are currently
managing manually. So the resource hierarchy
is organized as follows. It’s quite simple. We have two folders under
our organization, Engineering and PeopleOps. And each has two projects. We have Check Out Service
project, the Shopping Cart Service product under
the Engineering folder. And the HR System and Payroll
projects under PeopleOps. So that’s pretty simple. Now I decided to adopt the
Anthos Config Management to avoid a disaster that
my colleague Alex just mentioned about. So I have created a GIT
repository on GitHub. As you can see, this
repository is currently empty without resources. And I have already turned
on Anthos Config Management for this repo. So next, I’m going to translate
my organization into this repo so that Anthos can
start managing. I’m going to do that using
the importer service. So I go to my cloud shell. I reclone this repo
in my environment. As you can see, it’s
currently empty. So for this demo, I
put all the commands I need to run in the demo script
to just run the demo script. So first, I’m going to
run the importer service. So what importer service does
is pretty straightforward. It’s going to translate
my organization, specify it by the ID,
encoding all the resources and IAM policies into this repo. So we can start managing. So now let’s open
the cloud editor. Now we see that it creates
a hierarchy directory. So the hierarchy directory
here maps exactly to the GCP hierarchy
we just saw. And my colleague
Marco already briefly explained the structure here. So let’s go over them with
a little bit more details. So each director here represents
a single GCP resource. At the top level, we
see there’s a GCP. There’s an organization
Chile Oregano. And there’s the
gcp-organization.yaml, indicating that this is
an organization resource. And this file contains all the
metadata for this resource, for example, its ID
and its GCP name. And there’s also a
gcp-iampolicy.yaml which contains all the IAM
policies for this resource. And we see that there
are two directories under the organization,
Folder Engineering and Folder PeopleOps, representing
the two folders under this organization. Further down, we can see that
there are two directories under the Folder Engineering– Project Check Out service and
Project Shopping Cart service, representing the two projects
under the folder Engineering. So in addition to this
resource and IAM policies, I also want to keep my company’s
environment safe with security best practices, such as
restricting my company’s resource access to only the
members from my company’s domain. So I’m going to create
such a domain restriction constraint in this repo. So how do I do that? So my colleague Alex has already
mentioned this in his slides that we have the open
source policy library. So normally, I will just need to
clone the library into my repo. And I can modify
the policy template to create my custom
policy constraints. So in this demo, I’m just
going to copy over some policy constraints that I already
put in my local repo. So I’m going to check
out the policy library. As you can see, now there is one
more directory called Policies. There are constraints
and templates. Let’s open this file. So this is a domain
restriction constraint over IAM members,
which Alex already explained in a lot details. So here, I’m going to
whitelist my company’s domain. I’m going to add Chili Oregano. So now, with resources,
IAM policies, and policy constraints I’m OK. So I feel ready. I will submit all these changes. Add everything, come in,
and push to [INAUDIBLE].. So now let’s do a quick recap. As a code administrator, I
decide to adopt Anthos Config Management. So I create a GIT repository
to be the central source of truth for my organization. I use the importer service
to automatically translate my organization into this
repo to start managing. I then put policy constraint
files in this repo to keep my company’s
environment safe and secure. Now, this repo is
fully instantiated and is ready to be used. So now, imagine I’m Bob, the
developer from Chile Oregano. So I’m going to work on the new
fulfillment service project. And I am going to create this
project under the Engineering folder. So as right now, my company is
moving towards Anthos Config Management. So, as a developer, I
don’t have direct access to cloud console anymore. I cannot go to console
and create my project here and manually specify
the IAM policies there. Instead, I’ll be doing all
of that through the repo by going through the
code review process. With that, I’m going
to my cloud shell. And I’m also going
to run the script. So as a developer, the
first thing I need to do is I’m going to clone
my company’s repository into my local environment. As we can see, all
the data is here. So open the cloud shell editor. Now the repo is here
containing everything that me and Alice just pushed. So I’m going to create this
project under the folder Engineering. How am I going to do that? So just like the two other
existing projects, Checkout Service and Shopping
Cart Service, I’m going to do that by creating
a new directory for my project. So I’m going to navigate
to this directory. And in this demo, I’m going
to just copy over the files that I prepared beforehand. So now, you see I have created
a new directory under the folder Engineering. It’s called Project Fulfillment. And I have created a
gcp-project.yaml which contains the [INAUDIBLE]
of my new project. I named my project
Fulfillment Service. And in the gcp-iampolicy.yaml,
I specified Bob from as a project editor. Now as a developer, I’m going
to create a pull request. So now, the pull
request gets created. And you see that Cloud
Build runs immediately. So Cloud Build, in
this case, performed as our [INAUDIBLE] check. It runs our config
validator, which does a bunch of [INAUDIBLE]
checks against or repo. For example, it checks for
project ID duplication. It cannot have two projects
having the same ID. It also checks for GCP
hierarchy violations. For example, you cannot have to
create a GCP product and then another GCP product. In addition to
that, it also checks for IAM policy violations
against the rules, the policy constraints that we
put into this repo. Actually in this case, we
see that Cloud Build actually has failed. So let’s go to Cloud Build page. So this is the one we just run. Open it. So from the log,
we see that it’s reporting two errors, one from
duplicate project ID, Shopping Cart Service. So if we circle back,
this is basically complaining that I’m using
a duplicated project ID. So this ID already
exists today on GCP. And second error complains,
found a constraint violation. So contains member
from unexpected domain, [email protected] So
this is basically because Bob has specified
his personal gmail account as a project editor, which
clearly violates the policy constraints or violates
the company’s compliance. So with these two
errors, as a developer I’ve realized that
I should really be running the config
validator locally before I even create this pull request. So I go back to my repo. I’m going to run the
config validator through. It takes a while. So indeed, it’s reporting
these two violations– the domain violation and
the project ID violation. So let’s fix these two errors. First, let’s not use gmail,
which violates the rule. Let’s use Chili Oregano. And let’s give the new
project a unique ID. Now let’s run the config
validator through again. See this time there’s no errors. So I’m going to update
the pull request. Now Cloud Build runs again. Let’s open the logs. So while Cloud Build is running,
let’s do another quick recap. So as a developer, I propose
config changes through the repo by creating new pull request. And the config validator
will capture and report any errors that are introduced
by my config changes. I will be able to fix these
errors before the bad changes get pushed on the [INAUDIBLE]. So now in this case, we see
that Cloud Build is happy. So now, imagine I’m Alice,
the cloud administrator again. So I receive a notification
of a new pull request. So I go to my GitHub account,
open this pull request. Actually, I notice
that all checks are passed for these pull
requests, which is great. I go inspect the code changes. I see that Bob is going to
create a fulfillment service project. And Bob has specified
his corporate account as the project editor. So the code looks fine to me. I’m going to merge this
pull request directly. So now the pull
request gets merged. So what happens next? So this repo is already being
enabled with Anthos Config Management. And the master
branch is currently being actively monitored
by the service. So if it detects
any new changes, it will automatically
pick them up and apply to the underlying GCP platform. That means the new project
Fulfillment Service project will get created
automatically on GCP. And Bob will be specified
as the project editor. So now let’s go to the
console and verify. Let’s refresh. So now we see that fulfillment
service project appears right under the Engineering folder. If we look at IAM policies,
now [email protected] is now specified as
a project editor. So, yeah, that’s pretty much
the demo I have for today. With that, I’m going
to hand over to Marco. MARCO CAVALLI: So
thank you Zhuzeng. And let’s recap what we saw
today and let’s summarize. We started and we
took the perspective of a cloud administrator. And we saw the challenges that
as an administrator you have when you have to manage
workloads and configurations across hybrid environments. And then we saw how Anthos
Config Management helps you with that. It helps you improve
your security posture by leveraging devops
tooling and devops workflows so that you can enforce
governance and improve security and compliance. And Zhuzeng showed how
that works in a live demo. So there are a number of
sessions that covered topics that are related to this one. Some have already happened. One is tomorrow morning
or tomorrow afternoon. But you’ll find them on YouTube. So I encourage you to
go and look for them. Because they are all very
interesting and related. And thank you so much. [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *