►
Description
Presented by Rosemary Wang, Developer Advocate, HashiCorp
You’ve set up your infrastructure as code in GitHub Actions to securely test and deploy to production. One year later, you discover the account keys you used for automation have been compromised! In a panic, you scramble around multiple repositories looking for where you used the account keys and throw together a script to rotate them. You start to wonder, “is there a better way I could have managed my secret?” In this talk, you’ll learn how to manage secrets in your infrastructure pipeline using HashiCorp Vault and Terraform with GitHub Actions. By using Vault’s dynamic secrets engines, you can rotate, audit, and manage the lifecycle of your infrastructure account keys and API tokens. In addition to managing service account keys for Terraform automation, we’ll cover how Vault can generate secrets such as database passwords for creating infrastructure resources.
For more from GitHub Universe 2020, visit https://githubuniverse.com
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
Thanks
for
the
introduction,
welcome
to
the
jungle,
I'm
rosemary
wong
and
today
I'm
going
to
be
talking
about
keeping
secrets
in
your
infrastructure
pipeline.
So
before
I
even
talk
about
keeping
secrets,
because
keeping
secrets
really
isn't
all
that
fun
infrastructure
pipelines
are
continuous
integration
pipelines
for
infrastructure
as
code.
A
When
you're
using
infrastructure's
code,
you
tend
to
have
a
couple
different
steps
in
this
kind
of
pipeline
or
workflow.
The
first
is
that
you
tend
to
unit
test
the
configurations
you
have
make
sure
the
configurations
are
what
you
expect
them
to
be.
You
might
taste
test
them
to
make
sure
your
configurations
don't
have
something
misconfigured.
This
could
be
an
open
security
group
rule.
It
could
be
a
different
network
policy,
then
you'll
build
and
deploy
this
to
some
kind
of
production
environments
and
then
you'll
integration
test
that
to
make
sure
it
functionally
works.
A
Today,
we're
talking
about
infrastructure's
code
using
hashicorp,
terraform
hashicorp
terraform
is
an
open
source
project
that
you
can
use
to
deploy
infrastructure
to
pretty
much
any
provider.
That's
supported,
including,
but
not
limited
to
pizza.
You
can
actually
provision
pizza
using
terraform,
and
someone
did
write
a
plug-in
for
that
so
check
out
terraform
as
an
open
source
project.
A
I've
done
a
lot
of
these
infrastructure
pipelines
before
and
they
usually
follow.
This
general
approach,
which
is
plan
security
test,
apply
and
then
check
if
everything
is
working
but
there's
kind
of
a
problem
when
I
use
these
pipelines,
for
example,
sometimes
I'll
go
back
to
pipelines
and
realize
that
some
of
the
secrets
I
was
using
were
actually
about
a
year
old
and
I
never
touched
them.
The
pipeline
had
continued
running
on
its
merry
way,
but
I
had
never
changed
that
set
of
secrets
or
that
of
information.
A
This
is
actually
a
view
of
my
pipeline
that
I
had
not
run
for
about
a
year
and
it
had
some
azure
credentials
that
were
about
a
year
old.
So,
basically,
I
was
deploying
to
azure
and
I
could
continue
to
deploy
to
azure
with
the
same
username,
effectively
username,
passwords
and
tokens
that
I
had
done
for
about
a
year.
A
The
other
problem
is
that
sometimes
my
security
tests
fail
or
I'll
review
some
pull
requests
and
realize
in
horror
that
I
committed
the
database
password
in
a
previous
session.
You
probably
learned
a
little
bit
about
how
you
can
scan
for
secrets
in
your
github
pipeline
github
actions
workflow.
However,
in
this
particular
situation,
I
didn't
catch
it
before
I
went
to
production.
Instead,
I
sort
of
caught
it
when
I
had
already
done
it
and
and
actually
recently
I
printed
out
my
database
password
in
a
pull
request
by
accident,
so
either
way.
A
A
So
after
this
situation
happens,
I
usually
invoke
plan
r
plan
r
has
a
couple
of
steps
to
it.
The
first
step
is
regret.
Everything
regret
that
you
became
an
engineer,
regret
that
you
started
to
do
devops
and
all
of
these
things
regret
that
you
started
to
learn
infrastructure
as
code
and
dare
to
touch
cloud
infrastructure.
A
So
after
you
get
over
that
step,
the
next
step
that
you
think
about
is
revoking
the
password
or
the
token
that
you
were
using
in
the
case
of
my
long-lived
credentials.
I
would
revoke
it
and
then
I
would
rotate
it
with
the
new
one,
so
this
happens
with
a
number
of
sensitive
sort
of
variables
that
you
might
have
in
your
pipelines.
A
The
next
thing
you
do
is
find
all
references.
This
could
mean
that
your
database
password
was
referenced
by
multiple
applications.
It
could
mean
that
it
was
referenced
by
one
or
two
other
repositories.
You
don't
know
where
it
was
referenced,
but
you
have
to
find
them,
and
the
next
is
to
replace
so
basically
steps.
Four
and
five
tend
to
relate
to
a
control,
f
and
control
r.
A
That
is
our
automation
for
referencing
and
replacing
any
instance
of
that
sensitive
variable
that
we've
compromised,
and
then
we
rerun
everything
at
one
time
that
I
committed
a
database
password
and
had
to
rotate
it
rotate
it.
I
think
it
took
10
or
15
pipelines,
re-triggering
and
running
and
basically
redeploying
so
plan
r
is
an
extensive
plan.
Sometimes
it
can
take
two
days
other
times
it
can
take
seven
weeks.
You
never
know
what
it
will
take
all
right.
A
A
Actually,
this
subset
of
things
is
kind
of
the
stuff
that
you
would
put
in
your
pipeline.
If
you
think
about
the
secrets
in
your
pipeline,
they
usually
fall
into
one
of
these
three
buckets
so
things
that
you
need
to
log
into
an
infrastructure
provider.
These
are
api,
tokens
or
service
account
keys.
You
also
have
resource
attributes.
These
are
database,
passwords
or
certificates.
So
you
might
pass
an
admin
password
to
a
resource
to
make
sure
you
start
up
a
database
with
the
right
login,
and
then
you
also
have
generated
secrets.
A
So
these
are
things
that
the
pipeline
itself
creates.
These
could
be
random,
passwords
or
tokens.
We're
only
going
to
talk
about
the
first
two,
which
is
service
accounts
and
resource
attributes,
because
generating
secrets
tends
to
be
an
output.
Securing
output
is
a
whole
other
talk,
and
so
what
we're
going
to
do
is
focus
on
the
first
part
of
this
talk,
which
is
keeping
your
secrets,
indeed,
a
secret
as
inputs.
A
So
when
you
use
a
secrets
manager,
what
do
you
do
and
why
do
you
bother
using
it?
Well,
a
secrets
manager
actually
takes
away
a
couple
of
steps.
The
first
thing
is
regret.
You
might
push
a
password
and
regret
that
you
pushed
it
in
the
first
place,
but
you
actually
get
the
simplification
of
the
revocation
and
the
rotation
of
secrets
with
the
secrets
manager.
So
if
you
need
to
change
the
secret,
it's
no
big
deal.
A
The
next
is
actually
the
reference
step.
You
still
have
to
find
pipelines
that
are
referencing
it.
You
still
have
to
find
applications
that
are
referencing
it,
but
at
the
end
of
the
day,
the
bulk
of
the
revocation
and
the
rotation
are
handled
by
secrets
manager,
and
then
you
follow
the
rerun
command.
So
sometimes
you
have
to
rerun
it
other
times.
You
don't
depends
on
what
your
automation
supports.
A
At
the
end
of
the
day,
you
kind
of
remove
the
regret
and
the
replace
step
for
the
most
part
vault
as
a
secrets
manager
will
handle
that,
for
you
and
for
the
most
part
you
can
go
and
use
the
new
database
password
or
service
account
without
any
other
thoughts,
all
right.
So
the
way
that
secrets
get
into
a
pipeline
in
the
first
place,
specifically
an
infrastructure
pipeline,
is
this
process
of
secrets
injection.
A
The
first
step
is
to
authenticate
to
said
sequence
manager.
You
can't
just
get
a
secret.
You
need
to
authenticate
to
your
secrets,
manager
first
and
then
the
second
step
is
to
actually
introduce
the
secret
or
get
the
secret
from
it.
After
that,
you
can
pass
it
to
your
pipeline
for
usage
in
the
case
of
vault.
A
What
we
can
do
is
consolidate
these
two
steps,
so
we
would
first
authenticate
to
vault,
and
then
we
would
get
the
secrets
at
a
specific
api
path
in
the
secrets
manager-
and
we
passed
this
through
the
consolidation
of
these
two
steps
actually
is
done
by
the
vault
github
action.
It's
an
open
source,
github
action.
A
A
It's
going
to
get
a
little
complicated,
but
I'm
going
to
try
to
articulate
some
of
the
design
elements
in
this
particular
demo.
The
first
thing
is
that
I
have
an
infrastructure
pipeline
using
github
actions.
So
it's
a
repository
that
has
some
terraform
configuration
in
it
and
I
expect
to
deploy
it
to
amazon
web
services
today.
A
What
I'll
do
is
I'll
tell
this
infrastructure
pipeline
to
authenticate
to
vaults.
First
after
it's
authenticated
to
vault,
the
github
action
for
vault
will
retrieve
the
secrets
that
I
want
so
I'll
tell
it
to
retrieve
a
static
secret
with
an
admin
token.
The
reason
why
I
wanted
a
static
secret
for
my
database
and
not
just
a
dynamic
credential
to
start
is
that
well,
my
database
doesn't
actually
exist
yet,
so
I
can't
really
create
a
database
password
and
username
without
the
database
existing
first.
A
A
The
next
step
is
to
basically
tell
aws,
hey
I
want
to
log
in
and
aws
will
tell
me:
okay,
here's
a
token
after
I
get
that
token.
I
can
create
that
managed
database
and
after
I've
created
that
managed
database.
I
can
continue
to
configure
vault
to
basically
get
a
set
of
read-only
credentials
for
the
application.
A
Something
important
to
understand
about
this
workflow
is
that
some
of
these
things
are
over
public
internet.
You
can
put
everything
over
a
private
connection
if
you
actually
create
self-hosted
runners
or
you
put
them
in
the
same
virtual
peering
connection
or
you
peer
together
with
a
virtual
appearing
vpc
with
the
peering
connection
between
them.
A
In
the
case
of
the
vault
instance,
the
vault
instance
actually
is
privately
connecting
to
the
database,
so
the
database
itself
doesn't
have
any
public
connection,
but
the
vaults
instance
that
I'm
using
is
a
manage
vault
instance
and
it
is
publicly
available.
So
the
github
action
is
actually
connecting
to
my
secrets
manager
over
public.
Again,
you
can
configure
this
all
private
from
a
security
standpoint,
but
for
today's
demo,
I'll
just
demonstrate
it
over
the
public
internet
all
right.
So
this
is
the
workflow
at
a
very
high
level.
A
Sure
all
right,
so,
unfortunately,
you
will
not
have
my
view
face
of
my
face
on
your
view.
Unfortunately,
but
what
I
have
is
actually
the
code
base.
If
you
would
like
to
see
more
of
this
code
base,
you
can
take
a
look
on
github.
It's
at
my
handle
there.
So
the
first
thing
we're
going
to
actually
take
a
look
at
is
the
workflow
itself.
A
The
first
thing
that
I
did
was
add
the
vault
github
action,
the
vault
github
action
has
a
set
of
parameters
that
take
in
the
url
of
the
vault
instance.
For
me,
I
use
it
as
a
github
secret,
so
the
address
role
and
secret,
as
well
as
the
name
space,
and
it
will
actually
go
and
authenticate
to
vault
without
me
needing
to
do
anything
else.
The
next
important
thing
that
it
will
do
is
retrieve
secrets
from
my
vault
database
or
my
vault
secrets
engines.
A
So
vault
has
a
set
of
plugins
that
will
rotate
all
of
these
kinds
of
secrets
for
you,
you
can
enable
them
selectively.
So
I,
for
example,
have
enabled
a
static
key
value
store.
This
stores
my
static
database
login
and
database
password.
I
also
enabled
the
aws
secrets
engine
the
aws
secrets
engine
will
actually
handle
the
rotation
of
aws
tokens
and
access
keys
and
secret
access
keys,
depending
on
how
you
configure
it.
A
I
also
have
a
token
just
to
store
my
terraform
state
if
you're
familiar
with
terraform
terraform
creates
infrastructure
and
it
needs
to
store
the
state
of
that
infrastructure
somewhere.
So
this
is
for
me
to
securely
store
that
state.
If
I
actually
examine
this
rough
api
path
in
vault,
the
api
path
in
vault
sort
of
looks
like
this.
You
have
an
aws
api
path
here,
which
is
the
infrastructure
pipeline,
slash
aws.
A
I
also
have
the
aws
of
the
static
section
for
specifically
database
passwords
and
user
names.
All
of
this
is
available
all
right,
so
what
I've
done
is
actually
pre-staged
the
database.
The
reason
why
I
pre-staged
the
database
is
that
sometimes
databases
take
a
little
bit
of
time
to
provision
the
database
is
up
and
running
already
in
aws.
A
What
I'm
going
to
do
is
actually
configure
the
second
part
of
this
with
a
pull
request
using
the
terraform
github
action.
I
can
actually,
I
can
plan
the
terraform
that
I
expect
to
to
use
so,
for
example,
this
terraform
is
going
to
configure
vault.
For
me
it
will
actually
add
a
new
secret
backend
for
my
postgres
database
that
I've
provisioned
in
aws.
A
When
I
actually
run
the
plan,
it
will
funnel
this
back
to
my
poll
request.
So
you
can
see
all
of
the
plan
information
you
can
verify
from
a
team
standpoint.
Sometimes
you
want
to
check
if
these
connections
are
are
correct
or
if
you
maybe
misconfigured
something.
Another
neat
important
feature
that
happened
in
terraform
or
dot
14
soros
recently
released
is
actually
the
market
mark
of
sensitive
variables,
so
it
will
actually
redact
certain
sensitive
variables
if
you
mark
them
in
sort
of
your
terraform
configuration
in
the
first
place.
A
So
all
of
this
is
actually
planning
to
put
a
new
database
secret
engine
and
basically
this
will
handle
the
rotation
of
database
passwords.
So
while
this
actually
runs,
I'm
going
to
confirm
and
merge
a
request
all
right,
while
that
runs
I'll,
actually
show
the
aws
portion.
So
remember.
I
said
that
the
pipeline
has
to
connect
to
aws
the
important
way
that
it
connects
to
aws
is
through
the
revocation
and
rotation
of
an
sts
token.
A
This
token
for
aws
only
lives
for
about
30
minutes,
and
this
is
important
to
understand
because
I'm
keeping
it
a
secret
through
ephemerality,
I'm
not
letting
it
stick
around.
So
remember,
in
my
previous
example,
I
put
in
one
year
for
a
secret
and
I
never
touched
it
in
this
case.
My
secret
only
lasts
for
30
minutes.
I've
run
this
pipeline
about
four
times
in
the
past
hour
and
the
three
times
that
I
had
run.
It
already
expired.
A
A
I
tune
the
kind
of
configuration
I
want
for
the
time
to
live
of
that
secret.
If
I
don't
need
that
eriebus
credential
for
more
than
an
hour,
I
don't
need
it
for
more
than
an
hour.
My
recommendation
is
tune,
the
credentials
that
you
need
for
the
amount
of
time
based
on
how
long
your
pipeline
runs
right
in
the
case
of
infrastructure
pipelines,
some
of
them
can
be
very
long
running.
A
But
in
this
case
I
have
a
set
of
one
credential,
because
I've
only
run
this
pipeline
once
you
also
notice
that
I've
printed
the
vault,
credential
vault
generation
of
database
credentials-
and
it
says,
there's
no
value.
Basically,
I
haven't
generated
any
database
credentials,
yet
I'm
using
a
static
database
password
for
the
admin.
I
can
always
change
that
all
right.
So,
let's
see
if
this
is
done
running,
hopefully
it's
done
running
still
running
all
right,
so
this
is
done
in
this
github
actions.
Workflow
I've
set
up
a
couple
steps
again
importing
the
secrets.
A
I
verify
to
make
sure
that
they've
been
injected
into
the
pipeline.
Remember
this
is
the
aws
secret
and
the
static
database
password
I'll,
also
set
up
terraform
as
well
as
format
and
initialize,
and
apply
everything
so
now.
This
is
actually
a
database
that
I
can
run
and
try
to
log
into
all
right.
So,
finally,
the
second
portion
of
this
and
I
think
the
most
interesting
portion
remember
the
database
password-
can
be
used
by
a
lot
of
different
applications.
It
can
be
used
by
many
different.
You
know
people
for
even
just
verification,
debugging
and
tracking.
A
What
I
can
do
is
now
create
a
database
credential
on
demand.
So
if
I
am
going
to
go-
and
let's
say
log
into
this
database-
read
only-
I
just
want
to
have
my
application
pull
some
information
from
it.
I
can
actually
request
to
vault
and
say:
hey.
Can
you
just
give
me
a
database
credential?
So
that's
actually,
what
I'm
going
to
do,
I'm
going
to
get
a
database
credential
and
hopefully
I'm
typing
the
right
command,
because
I
didn't
feel
like
copying
and
pasting
today.
A
A
This
is
read
only
by
configuration,
myvault
administrator,
which
is
me
configure
this
to
be
read
only
and
now
we've
got
a
vault
list.
So
when
I
list
the
number
the
credentials
that
I've
generated,
I
only
have
one
set
of
database
credentials
which
is
really
powerful.
If
I
issue
and
try
to
get
another
set
of
database
credentials,
I'll
actually
see
two
database
credentials
issued,
I
did
not
print
out
the
password
by
the
way
I
was
told,
do
not
print
out
passwords
during
live
demos.
This
is
a
username,
so
don't
fear
this
is
a
username.
A
It
will
get
revoked
in
about
20
minutes.
I've
set
the
time
to
live
for
the
database
credentials
specifically
to
20
minutes,
and
the
database
itself
is
not
publicly
accessible.
So
unless
you
can
find
the
database
and
access
it,
there's
not
much,
you
could
do,
but
basically
the
whole
workflow
that
I've
demonstrated
here
allows
you
to
retrieve
secrets
on
demand,
no
matter
what
kind
of
application
you
have,
no
matter,
what
kind
of
you
know
information
you're,
trying
to
store.
The
idea
is
that
you
can
go
to
a
secrets
manager.
A
A
Some
of
this
workflow,
especially
if
you've
got
different
methods
and
different
databases,
for
example
in
the
high
level
architecture
that
I
have
here,
I'm
using
some
specific
authentication
methods.
You
can
use
authentication
methods
to
vault
for
github,
for
example,
and
you
will
have
to
configure
that
as
part
of
your
github
action,
but
all
of
it
is
open
source
and
all
of
it
is
supported.
So
you're
welcome
to
go
dig
into
the
documentation
and
if
you
have
any
questions,
you're
more
than
welcome
to
reach
out
to
me
or
any
of
the
team
at
hashicorp.
A
Finally,
next,
please
all
right.
Finally,
if
you
want
to
reference
this
pipeline,
I'm
putting
the
url
here
for
additional
reference,
and
if
you
are
curious,
you
want
to
take
it
and
reverse
engineer
it
and
try
to
do
it
yourself
and
the
other
thing
is
like
if
you
have
little
knowledge
on
vault
or
you're,
trying
to
get
more
familiar
with
terraform
and
vault
I'll
have
a
list
of
references
here,
as
well
as
the
session
resources.
Take
a
look
at
some
of
the
links
we
have
tutorials.