GREG KUELGEN: Hello, my name is Greg Kuelgen.
I'm an architect with the Apigee team at Google Cloud.
I'm very excited to be here today
with my friend and colleague Debora Elkin, who
will join us a little later on to give us
an amazing demo of some of this functionality
that we talk about today.
So let's get into it.
I'm not going to read this agenda slide,
but there's a key takeaway.
How you can use Anthos and Apigee as a means
for deploying secure APIs while allowing developers
to focus on delivering business value.
Let's set this up just a little bit.
At my company, there is an App Innovation Day.
I built a killer app, Jellybean Auto Count.
We all want to win jelly bean guessing contests.
The app I built utilized some sick machine learning models
to quickly and accurately provide
a count of the jelly beans in any jar
just by processing a photo.
Everyone agreed that this app was amazing
and we needed to make it available to all our employees.
I've got this great code, but how should I deploy it?
I went to my colleague Maria, as I
knew she was a wizard on our ops team.
Maria said, I have just the thing.
We've been doing Kubernetes for a while now
and had learned that it was difficult to manage
multiple clusters, particularly across different regions.
There was a new technology that the company was trying
called Anthos GKE.
It promised to simplify management of Kubernetes,
creating a consistent experience for developers
while doing so securely.
It sounded fantastic to me, so we went ahead and deployed
my app to Kubernetes.
My app was pretty basic.
But outside of following secure coding practices,
I didn't have to concern myself with security, scaling, et
cetera.
People loved the app.
Usage was through the roof.
I used this as an opportunity to recruit some team members.
We were getting lots of enhancement requests
and began working through the backlog.
Since our architecture was based on microservices,
we saw a proliferation of services.
We quickly realized that we needed a way
to help us manage and secure all of these services.
Back to Maria.
Maria had an answer again.
There is a reason I keep going to her.
In this case, we can use a service mesh
to help us secure the services, understand the interactions,
and help us generally manage the traffic.
The great news is that we have a fully managed service
mesh offering already available as part of Anthos
called Anthos Service Mesh.
This was, again, a great relief, because we had enough backlog
to get through without worrying about managing all of the TLS
and certificates and access control and routing,
and just all of that junk.
As you can see, we simply layered in Anthos Service Mesh
and kept going on our merry way.
With just a little help from us, the operators on Maria's team
added all of the policies into the Anthos Service Mesh
to secure the communication between all of our services.
All of a sudden, other teams in the enterprise
caught wind and wanted access to these services
we were building.
Before now, it was just a couple of us,
and we all worked very closely together.
We wanted to let other teams use our services,
but we didn't want to take a bunch of our time
onboarding these teams.
Back to Maria.
I'm sure no one is surprised to learn
that she had another solution.
This time, Apigee hybrid.
It runs on top of Anthos GKE, and the runtime
can be co-located with our services.
It provides a way for us to make our documentation discoverable
and allow internal teams to gain access
to our APIs via self-service.
No need to talk to anyone on my team.
So as you can see, we layered in Apigee
to help manage these APIs that we
were exposing to other teams.
More success.
At this point, Teresa, one of the execs took notice.
She saw the popularity of this app
and knew we had to make it available
to external developers.
Turns out we already had all of the pieces
in place to make that happen.
We simply needed to add a few more Apigee capabilities,
such as threat protection, rate limiting, and OIDC.
We also needed to ensure that we could handle the load.
We simply deployed another cluster
of GKE and Apigee hybrid in GCP to ensure that we could scale.
So that's all great.
But as I stated, I'm just a developer
that wants to deliver business value.
I don't know anything about exposing APIs to third parties.
How can this be made as simple as possible for me?
With that, I'm going to turn things over to Debora
to walk us through how we might be
able to enable someone like me.
DEBORA ELKIN: Thanks, Greg.
Let's explore this with a demo.
In the demo, we will see how we can leverage
CI/CD pipelines to make it very easy to expose services
through secure APIs.
It is standard practice when working with services
to use CI/CD pipelines to automatically build and deploy
whenever changes are committed.
This not only increases developer productivity
and software quality, but also makes
it easy to ensure best practices are followed
when developing services.
In the demo, the CI/CD pipeline is governed by Cloud Build.
When new code is checked into a repository managed
by Cloud Source Repositories, Cloud Build
triggers a new build.
This will generate a new container image,
check it into Cloud Container Registry,
and deploy this container into a service cluster.
We can use a similar approach for making it very easy
to build an API from a service.
When the service developer tags the source code,
Cloud Builder will orchestrate the generation of a new API
proxy and deploy it to an Apigee hybrid runtime.
Cloud Builder will test the API is successfully working
and check the newly generated API configuration back
into Cloud Source Repository.
Even without having a deep knowledge of API development,
a service developer can easily generate
an API that incorporates the best practices adopted
by their company.
Once the API is deployed, clients can access this API.
All external access is mediated by Apigee,
providing a secure layer and eliminating the need
to expose the Service Cluster externally.
The demo we are going to see is from the point
of view of a service developer, well
versed in software development, but not
necessarily an expert in API management.
Cloud Source Repository is useful code source control.
Typically, the developer will also use a local editor
on their workstation to work on the source code,
check to their local repository, and push the changes
to the remote repository.
Cloud Container Registry is used to store all the container
images that are generated during the development process.
The services are deployed to an Anthos [? ASM ?] cluster.
In this case, it is a development cluster.
Additionally, there's another GKE cluster
in which an instance of Apigee hybrid runtime
has been deployed.
Let's have a look in Cloud Source Repository.
In mature teams, the structure of the repository
is generated automatically when the project is created,
and it [INAUDIBLE] templates that encourage best practices
in software development.
It even enforces them sometimes.
A very common practice is to have CI/CD pipelines-- that
is Continuous Integration, Continued Development
pipelines-- that are triggered when code is checked.
The pipeline triggers the build of a new container image
and deployment of this newly built image
into a service cluster.
Let's see this in action.
The developer will work on their local visual editor.
They will make changes to their code.
And once they are ready, they will commit it
to their local repository.
They will then push those changes
to the remote repository.
When the changes reach the remote repository,
a new build is started.
This is managed by Cloud Build.
Let's have a look at what happens during the build.
The first step builds the new container image.
It then pushes it to container registry.
After that, it is deployed to the Anthos Cluster.
The last step verifies that all the artifacts
have been deployed and that they are successfully working.
Let's go back to Cloud Source Repositories
and have a look in more detail to the structure
of the repository.
We can see that there is an API folder.
In there, there is a readme file that
explains the steps necessary to expose
this service as an Apigee API.
Namely, we need to provide a couple of API configuration
data and also tag the repository.
That's all the developer needs to know in order to expose
the service as an API.
The developer decides to go ahead and do this.
So once again, we switch to the local editor
and edit the configuration for the API.
We need to provide a proxy base, [? but ?] this is where
the API will be reachable.
And we also need to provide the back-end
it will be connected to, in our case, our Hello World service.
Once again, the developer commits their changes,
pushes the changes to the remote repository, creates a new tag,
and finally pushes the changes, including the new tag,
to the remote repository.
Once again, this triggers another pipeline
that's managed by Cloud Build.
This pipeline, in its first step,
generates an Apigee API proxy based on a template.
It then deploys this API into the Apigee environment
and also generates all the associated artifacts
required for the API to run.
It also shows an API key that is required
in order to test this API.
The next step tests that the API has been successfully deployed.
It [? simply ?] invokes a couple of very simple requests,
one without an API key, and the other one with an API key.
The next few steps check the code generated for the API back
into the source code repository.
It is worth mentioning that the API that's generated
incorporates all the best practices
that a centralized API team deems as necessary.
For instance, verifying API keys, checking for threats,
et cetera.
Typically, this centralized API team
will be in charge of managing the templates used and will
continually update them with best practices
as their security posture changes.
Let's now take a look under the hood
and explore what the API does.
For that, we will switch to the Apigee user interface.
When we look at the API proxies that have been defined,
we can see that now we have a new one related
to our Hello service.
When we look into the details of the proxy,
we can see that it is connected to our Hello service, which
is available on the Hello endpoint in the Anthos cluster
ingress.
Let's have a look at the policies implemented
by this proxy.
Remember that these have all been auto generated.
So first, it will add a correlation ID to the request
if one doesn't exist.
If one exists, it'll just make sure to remember it
so that it can inject it back in the response.
It'll then apply some threat protection policies
to ensure that no attacks are sent, in the headers,
for instance.
It will then verify that an API key is provided
and that it is valid.
It will then enforce quota limits on the number of calls,
and finally will apply JSON threat protection policies
on the payload of the API.
Before the checks pass successfully,
it will forward the request to our Hello World Service.
On the way back, it will inject a correlation ID
into the Hello World Service [INAUDIBLE]
preserve the one that was sent in the request.
Let's now see the API in action.
In order to do that, we will start a very handy feature
that Apigee has that allows you to trace every request that
comes into the API proxy.
For that, we'll use some pre-prepared requests
that we have.
The first one sends a request without an API key.
As expected, we get a 401 unauthorized response,
because there was no API key included in the request.
Our second test doesn't include an API key either,
but it does include a malicious header.
Let's test it out.
As expected, we get an error, because the API has detected
a threat in one of the headers.
Our next test, it's a valid request.
It is a request that does include an API key.
As expected, we get a successful response.
And by the way, this is the new version
of the service that was deployed at the beginning of the demo.
It also includes a correlation ID
that was automatically generated because our request didn't
include one.
Our next test does include a correlation ID in the request.
When we execute it, we can see that the response
does include that correlation ID played back.
Let's now send a few more requests.
If we send them in quick succession,
we will, at some point, hit our quota limit.
And that's when the API will return an error.
Let's see how Apigee handled all of these requests.
The first one is the one that returned a 401.
That's when we didn't have an API key.
The verify API key policy failed in this case
and stopped any further processing.
The second case, it's when the threat protections failed.
Again, [? all ?] for the processing is stopped.
The next few requests are the ones that were successful.
We can see that all of the policies
were successfully executed and then their request
was sent to the target server.
When their response was received,
it was forwarded back to the client invoking the API,
including the newly generated correlation ID.
The last request, it's the one that
failed because we had exceeded our quota limit.
And, again, any further processing was stopped.
In this demo, we have seen modern software development
practices that are commonly adopted
by the developer community when building
services, such as CI/CD.
And we have also seen how we can leverage
these practices to easily solve the problem of exposing
these services to external consumers in a secure way.
The service developer does not need to be an API guru in order
to build APIs that incorporate all of the required
best practices.
I hope you have enjoyed the demo.
Thank you for watching it.
GREG KUELGEN: Thanks, Debora.
That all made good sense.
And I think it's something even I could understand.
But I have a question.
When do you generally see customers
set something like this up?
DEBORA ELKIN: Well, generally customers
with larger enterprises and mature programs
are the ones who have set this up in order to enable
a truly federated model.
By that I mean a model in which API creation is not
concentrated in a small team of API experts,
but rather distributed all along the developer community.
GREG KUELGEN: OK, got it.
But we all know the security requirements
are going to evolve, sometimes quite quickly.
How do teams manage the security of their APIs
across these distributed areas?
DEBORA ELKIN: That's when we generally
see a centralized team that is responsible,
not just for the creation of these automated templates,
but also of the shared flows that they use.
With a shared flow, you can build reusable units of logic
that are invoked by the APIs.
In mature organizations, security measures
are normally implemented using shared flows.
If the centralized team sees the need
to update some of these security measures,
they will update the shared flow.
All APIs making use of this shared flow
will automatically apply the latest and greatest security
measures.
GREG KUELGEN: Yeah, I think that's a good plan.
So with that, I think it's time to wrap up.
Today we talked about how you can use Anthos an Apigee hybrid
together to secure APIs.
With Debora's demo, you could see
how easy it was for a developer to expose an API using
best practices set up for them by an API Center for Enablement
or similar team, allowing the developer to concentrate
on delivering business value.
I want to thank you for watching this session
and offer to continue the conversation.
Both Debora and I have set up some expert one-on-one sessions
over the next couple of weeks.
We will also be answering your questions
in the question and answer session for this session.