[MUSIC PLAYING]
EMILY YE: Developers looking for a way
to store secrets for their applications
like credentials often turn to the popular secret management
tool HashiCorp Vault. In this video,
we'll cover how to authenticate the HashiCorp Vault using
Google Cloud Credentials.
I'm Emily, an engineer working on Google Cloud
Platform and open source integrations between Cloud
and HashiCorp Vault.
ANDY MANOSKE: And I'm Andy, a product manager at HashiCorp
and the Vault team.
Vault is a secrets management tool
that enables organizations to essentially secure, store,
and access control secrets across distributed
infrastructure and applications.
EMILY YE: In the last video, we deployed our '80s video game
application Hyperspace on Google Cloud Platform using Terraform.
Today we'll be changing gears a bit and talking about security.
Let's say we launched Hyperspace a year ago to great success,
and now we're looking to monetize our game by letting
players buy extra lives.
In order to do that, we need to accept payments.
However, the API key to our payment gateway
is very sensitive.
If we were to lose it, someone malicious
could possibly steal our money.
This payments API key is what many developers
refer to as a secret.
We hear this use case a lot from customers.
How should I securely store secrets
that my applications need at build or runtime?
Developers working in public cloud or multicloud
environments need a way to store credentials, configuration
files, and many other secrets for both their applications
and themselves.
Andy's going to show us how to solve this on GCP
using Vault, an open source tool by HashiCorp.
ANDY MANOSKE: Yes, I am.
HashiCorp Vault manages storing, encrypting, and managing access
to secrets.
It has multiple authentication back ends,
which provide different options for using your own identities
to identify users in Vault. Vault
also has many secret back ends for managing
different kinds of secrets, like the payments API key.
EMILY YE: Can you explain what an authentication back end
is, Andy?
ANDY MANOSKE: Great question.
So Vault behaves conceptually similar to a website
with multiple authentication methods.
Just like you can log in with Google on a website,
administrators can configure Vault
to allow users or machines to log in and access other secrets
in Vault. Vault is also pluggable,
so you can use a built-in back end
or write your own authentication method if you need to.
EMILY YE: That's right.
The LDAP or GitHub auth methods are great options
for developers, since they allow users to log in with LDAP
or a GitHub API key.
In our case, our video game is running on GCE instances,
so the GCP auth back end is a great choice.
ANDY MANOSKE: That does sound perfect.
How does it work?
EMILY YE: Well, using this back end,
developers or applications can authenticate to Vault using
two types of GCP credentials.
The IAM option lets you use your IAM service account,
and the Google Compute Engine, or GCE, metadata option
allows your GCE instances to use signed VM metadata
tokens to authenticate.
ANDY MANOSKE: So the video game GCE service
can either use their GCE metadata
or their associated IAM service account
to authenticate to Vault?
EMILY YE: Yeah.
I think the GCE method is especially cool.
Since a metadata token can be obtained on startup
without additional authorization,
you will need to hardcode any initial secrets into a startup
script or set super secret environment variables.
Yay, no hardcoding!
ANDY MANOSKE: Should we show how the authentication back end
works?
EMILY YE: Let's do it.
All right, so for this demo, we've
already got a Vault server up and running on a separate GCE
instance, and someone has already
stored our payments API key, as you can see.
In this terminal, we first shelled into the instance
that our Vault server is running on.
ANDY MANOSKE: First, an admin for your Vault server
will need to enable the authentication back end.
EMILY YE: Next, the back end treats
GCP as a trusted third party, so it
needs credentials to make calls to GCP APIs
to confirm identity.
The admin can set these credentials using the config
endpoint.
Next, the admin needs to add roles.
Vault has the concept of policies, which determine
what secrets a user can access.
Roles bind these predefined policies
to generated auth tokens to restrict what secrets
can be accessed by a user.
On our server, we've already added the payments policy that
allows access to our API key.
So let's add a GCE role.
ANDY MANOSKE: We mentioned that the back end allows either GCE
instances or IAM service accounts to authenticate.
Is that what the GCE type argument means?
EMILY YE: That's correct.
It means the back end will expect GCE metadata when
authenticating under this role.
We've also added a project ID and bound zone
to only authorized any GCE instances
in this project and zone.
We can also use things like instance groups, labels,
or associated service accounts to limit what instances
can log in under this role.
ANDY MANOSKE: So now the GCP back end is set up.
How do we actually authenticate to Vault?
EMILY YE: Let's switch terminals.
We've shelled into one of our game's front-end VMs here.
The GCE authentication method requires an instance
to present an identity metadata token.
So let's actually get this from the metadata server.
Note that this request doesn't require
any further authentication.
The metadata is returned on the JSON Web Token, or JWT,
signed by Google.
This is what the raw metadata contained in the token looks
like.
Note it includes the VM's identifying information,
as well as an expiration time.
This JWT expires within an hour, so we
don't have to worry that it will be stolen and reused.
ANDY MANOSKE: Great.
Now that you have this metadata JWT,
you can just pass into Vault and request an authentication token
under the role that we created earlier.
EMILY YE: Let's do that.
ANDY MANOSKE: Vault will confirm the VM's identity
and return an auth token and lease information showing
how long this token is valid.
EMILY YE: Now that we have this token, we
can use it to get our payments API key from Vault.
And now we have our API key.
So with that, we have Vault up and running on GCP with a GCP
back end for authentication, and our developers
can keep their payments API key safe.
Andy, if other developers have questions when setting this up,
where can they get more information?
ANDY MANOSKE: So check out vaultproject.io and look up
documentation on the GCP auth back end.
It's been great to work with Google Cloud on Vault.
EMILY YE: Thank you, Andy.
I agree.
You can also check out our blog post linked below that details
all of your authentication options and other HashiCorp
and Google collaborations.
See the link in the description below.
EMILY YE AND ANDY MANOSKE: Bye.
EMILY YE: Thanks, everyone, for watching.
We hope you found this series on using HashiCorp Vault with GCP
helpful.
Check out the links in the description
below, and don't forget to subscribe to the channel.