►
From YouTube: Shh, It’s a Secret: Managing Your Secrets in a GitOps Way - Jake Wernette & Josh Kayani, IBM
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Shh, It’s a Secret: Managing Your Secrets in a GitOps Way - Jake Wernette & Josh Kayani, IBM
How do you handle secrets? That is the first question that is asked whenever you are talking about GitOps. And it is a valid question! Do you put secrets directly in Git? Do you inject them in runtime? This is something that is trying to be answered across the community and in many different ways. Jake and his team at IBM looked at the landscape of GitOps specifically with Argo CD and could not find something that fit their needs. This talk will showcase how they were able to build and adopt argocd-vault-plugin and how it was able to simplify their secret management while allowing them to manage it in a GitOps way. Hopefully this talk will help you along in your GitOps journey and bridge the secrets gap that we are seeing so often in the community.
A
Yeah
thanks
for
the
intro,
like
you
said,
I'm
jake.
This
is
josh,
we're
so
reliability,
engineers
at
ibm
and
today
we're
going
to
talk
about
how
we
are
managing
our
secrets
via
githubs.
So
I
already
got
a
good
intro,
but
just
a
little
bit
more
background,
I'm
from
michigan
a
very
small
town
in
michigan,
and
I
graduated
from
central
michigan
university
with
a
computer
science
degree.
A
A
So
a
little
bit
of
background
just
to
talk
about
our
journey
into
kubernetes,
so
the
team
that
we
are
on,
we
started
out
managing
just
supporting
just
one
development
team.
That
was
that
had
this
big
monolith
that
was
deployed
to
websphere.
Now
sorry
about
that
and
everything
was
being
done
manual.
You
know
when
the
time
was
right.
A
We
had
these
jars
and
we
just
manually
deployed
them
to
the
server
so
and
all
that
setup
was
done
manually
just
by
a
small
team
of
just
a
few,
but
that
monolith
started
to
grow
and
started
to
get
slow
performance
started
to
suffer.
So
we
decided.
Let's
look
at
you,
know,
breaking
this
up
into
microservices
and
look
for
a
platform
as
a
service.
A
That's
where
we
went
into
public
cloud
with
cloud
foundry,
and
this
worked
really
nice
because
we
were
able
to
you
know,
break
up
the
monolith,
but
being
a
small
team,
it
did
become
a
little
cumbersome,
especially
as
we
got
more
developers
under
our
support.
So
it
went
from
just
you
know:
one
application
with
these
microservices
to
two
three
four:
five
applications
and
all
their
separate
micro
services,
and
so
it
was
becoming
hard
to
orchestrate
them
right.
So
that
is
where
kubernetes
came
into.
A
We
wanted
to
use
kubernetes
to
help
simplify
this
process
which
simplify
and
not
simplify,
but
you
know
it
helped
orchestrate
these
and
these
different
applications
and
helped
us.
You
know
to
be
a
small
team
and
manage
multiple
developer
teams,
but
with
that
we
did
notice.
You
know
a
lot
more
resources,
there's
a
lot
more
managing
with
these
clusters.
You
know
a
lot
of
these
resources
that
were
necessary
to
be
there
for
these
applications,
full
secrets,
rbac
all
these
different
resources
that
we
didn't
really
have
to
manage
with
cloud
foundry.
A
A
We
even
had
problems
where
we'd
deploy
and
oh
the
pull
secret.
Wasn't
there
and
nothing
was
pulling
in
production,
so
a
lot
of
these
problems,
and
so
we
tried
to
look.
How
can
we
solve
this
problem?
How
could
we
have
this
observability?
How
could
we
be
able
to
check
these
things
into
code
and
to
get
right?
You
know
and
get
these
things
into
our
cluster
in
a
stable
and
reliable
way,
and
so
that
leads
us
to
get
ups
right,
I'm
not
going
to.
C
A
Into
get
ops,
I
know
there's
a
lot
of
you
know
there
was
get
out
of
con
yesterday
and
there's
a
lot
more
going
on
with
get
offs
earlier
and
then
later,
but
just
I
just
want
to
talk
about
the
like
the
four
main
principles
that
were
developed
by
the
get
ops
working
group,
starting
with
the
declarative
state
right.
This
is
this
is
where
like
something
like,
kubernetes
is
really
great
because
right
you
have
these
manifest
they're
declarative
by
nature.
A
You
can
check
these
into
source
code
and
it's
telling
you
exactly
what
you
want
kubernetes
to
do,
which
is
really
nice
and
it
doesn't
have
to
be
kubernetes
right.
It
can
be
any
sort
of
any
sort
of
system
that
you
are
having
this
declarative
state
defined
and
then
second,
the
immutable
desired
state.
This
is
right.
This
is
git
right.
This
is
the
git
part
of
it
and
again
it
doesn't
necessarily
have
to
be
git.
It
can
be
some
sort
of
other
version
control,
but
you
know
having
this,
you
know
these.
A
The
third
part,
this
is
the
part
that,
to
me
differentiates
from
something
like
infrastructure
as
code.
It's
the
reconciliation
having
something
like
a
controller
that
is
watching
your
git.
It's
watching
your
cluster
or
your
other
set
your
system,
and
it's
it's
constantly
checking.
Is
there
something
new
and
git?
Do
I
need
to
put
that
in
a
cluster?
Is
there
something
new
in
the
cluster?
That's
not
in
git.
What
do
I
do
with
those
and
it's
constantly
checking
and
doing
that
that
reconciliation?
A
So
that's,
you
know
a
really
big
part
of
git
ops
and
then
the
last
part
is
the
operations
through
declaration.
This
is
like
to
me
the
something
that
really
like
resonates
with
me
here.
It's
it's
that,
if
you're
doing
something
like
in
order
to
like
be
doing
git,
ops,
right,
you're
you're,
going
through
the
principles
of
get
ops
to
do
git.
Ups
right,
it's
you're
not
applying
things
directly
into
a
cluster.
A
You
are
always
following
these
principles
so
that,
if
someone
is
manually
applying
into
a
cluster,
get
ops
is
able
to
with
your
reconciliations,
be
able
to
detect.
That
say
this
is
not
supposed
to
be
here
and
it
can
remove
it.
If
you
have
the
correct
policies
in
place
and
for
me,
that's
pretty
powerful
okay,
so
I
went
a
little
faster
there,
but
so
we
have
these
clusters
that
we
want
to
manage
these
resources
via
git
ops.
A
We
did
some,
you
know
experimenting
some
searching
trying
to
understand
what
a
tool
for
us
would
work
and
for
us,
argo
cd
was
that
solution.
With
this
we
chose
argo,
because
you
know
we
did
like
the
user
interface
aspect
of
it.
You
know
it's
really
nice
and
clean
being
able
to
kind
of
see
these
things
without
having
to
maybe
do
a
little
bit
of
guesswork
the
we
wanted
to
because
we're
a
small
team.
A
A
You
know
within
our
ocd,
which
is
nice
cncf
incubating.
You
know
we
that's
something
that
when
I
was
looking
at
doing
this,
I
wanted
to
make
sure
as
trying
to
push
toward
that
cncf.
You
know
tooling,
so
that
was
really
important
and
also
we
were
looking
to
move
from
something
like
a
plain
yaml
to
helm,
to
be
able
to
template
out
our
resources
so
that.
A
Very
important
for
us
so
yeah
jake
are
we
gonna
talk
about
secrets,
yeah,
we're
gonna
talk
about
secrets,
just
a
little
bit
of
background.
So
the
biggest
question
I
always
get
when
I
talk
about
get
ops
is
what
do
we
do
about
secrets?
It's
a
valid
question
right
because
we
have
right
everything
in
git
and
I'm
telling
you
to
put
everything
you
get,
but
you
know
we've
always
been
told
not
to
put
our
secrets
in
yet
so
you
know
so
we
that's
something
we
had
had
to
try
and
solve.
A
We
wanted
to
do
these
resources,
we
want
to
urgo
cd,
but
how
do
we
do
secrets
and
argo
cd
doesn't
necessarily
have
a
native
secret
solution?
They
kind
of
go
with
the
mentality
of
you
know.
However,
you
want
to
do
it
right.
There
there's
different
solutions.
It's
not
our
we're,
not
opinionated
opinionated
about
it.
So
you
know
you
can
you
can
kind
of
do
what
makes
sense
for
you.
So
with
that
in
mind,
we
had
a
certain
set
of
requirements
that
we
were
going
to
need
for
this
secret
solution.
A
You
know.
Obviously
we
talked
about
argo,
so
we
wanted
to
be
able
to
work
with
argo
cd.
Our
our
secret
manager
solution
was
to
use
hashicorp
vault
because
that's
you
know
what
we
had
internally
and
also
you
know
open
source
products.
So
we
wanted
to
continue
to
to
work
with
that,
as
well
as
ibm
cloud
was
building
a
secret
manager
solution
based
off
vault,
so
we
figured
that
was
the
way,
so
we
wanted
to
continue
with
fall.
A
We
wanted
to
be.
We
wanted
this
to
be
able
to
work
with
all
resources,
so
we
had
a
couple
use
cases
internally
that
we
were.
We
were
putting
things
in
the
vault.
That
would
then
be
added
into
something
like
a
config
map
or
a
custom
resource
in
a
lot
of
solutions
that
we
were
looking
for
looking
at.
They
were
just
about
the
secrets
themselves,
so
we
just
decided
okay,
so
we
just
decided,
let's
just
make
it
work
for
all
resources.
We
didn't
want
to
have
an
operator
to
install
this.
A
So
the
idea
was
very
simple:
we
wanted
to
have
a
yaml
resource
in
a
git
repository
where
the
value
where
the
value
would
normally
go.
We
would
template
it
out
with
this,
this
kind
of,
like
placeholder
syntax,
something
that
we
had
used
on
a
legacy
system.
So
we
wanted
to
continue
using
this
because
it
would
also
allow
us
to
use
our
already
defined
ammos.
A
We
wanted
then
argo
cd
to
be
able
to
pull
this,
do
something
apply
it
in
a
cluster
and
then
we
get
our
value
when
it
applies
it.
So
very
simple
idea:
right,
yam1
git
with
a
placeholder,
argo,
cd
and
then
the
cluster
we
get
our
you
know
secret
and
the
way
we
were
able
to
do
this.
You
know
talking
about
that
argo
cd
extensibility
was
the
custom
tools,
ability
that
argo
cd
has
so
argo
cd
right.
A
They
have
their
native
like
transformation
tools
like
helm,
customized
plain
animals,
but
they
also
allow
you
to
define
your
tool.
So
this
is
really
nice,
because
you
can
basically
just
either
you
know,
run
an
init
container
with
the
argo
cd
repo
server
or
you
can
just
bake
it
into
your
repost
server
image,
and
then
you
put
it
in
a
certain
directory
which
argo
cd
will
look
into
for
these
custom
tools.
A
We
started
off
with
just
hashicorp
vault
and
the
ibm
cloud
secret
manager
again,
which
is
based
off
the
hashicorp
vault.
But
then
we
realized
there's
much
more
secret
managers.
You
know
that
are
not
hashcorp
vault-based,
so
we
wanted
to
do
some
of
the
other
main
ones.
So
we
then
built
in
support
for
aws
secret
manager
and
then
gcp
and
azure
were
actually
added
via
the
community,
which
was
really
nice.
A
So
that's
something
that
we
didn't
actually
have
to
do.
So.
Thank
you,
community
and
with
this
with
this
tool,
some
of
the
features
is
we
we
do
versioning.
We
have
multiple
different
ways
of
defining
where
you
want
to
like,
where
you
want
to
tell
argo
cd
or
I'm
sorry,
where
you
want
to
tell
the
plugin
to
go,
look
for
the
secrets,
so
you
can
either
add
an
annotation
or
you
can
build
it
right
into
the
the
placeholder
itself.
A
We
call
inline
path
to
tell
you
know
to
tell
the
plugin
where
to
go,
find
these
secrets.
It
can
be
used
with
helm
and
customize
and
there's
different
authentication
methods.
Josh
is
going
to
show
you
I'm
using
the
kubernetes
auth
within
hashicorp
vault
and
how
you
can
get
that
set
up
so
just
a
high
level
to
try
and
kind
of
paint
this
full
picture.
A
So
and-
and
hopefully
you
can
see
this
in
the
back,
but
so
in
git
we
put
our
yaml
with
the
annotation
and
our
placeholder.
So
the
annotation
is
our
path
to
vault
and
the
placeholder
is
the
the
key
right.
So
while
you
have
your
key
value,
so
that's
the
key
from
vault
that
you
put
in
the
placeholder.
We
have
argo
cd,
which
is
watching
that
repo
and
when
it
detects
a
new
change
right,
argo
cd
does
its
thing:
it
pulls
it
in.
A
We
you
specify
that
you
want
to
use
the
argo
cd
vault
plugin
as
the
custom
tool,
so
it
knows
to
run
the
binary
that
you've
set
up
in
your
in
the
argo
cd
custom
tool
plugins.
It
then
makes
the
call
out
to
vault
based
on
your
path
returns.
The
values
does
the
replacement,
outputs,
the
ammo
back
to
argo
cd
and
then
argo
cd
will
apply
it
into
your
cluster.
A
B
Okay.
So
today
I'm
basically
going
to
go
through
this,
so
I'm
going
to
show
you
how
we
can
use
the
argos
with
evolve.
Plugin
I'll
call
I'll
probably
refer
to
it
as
adp.
At
some
point
shorter.
This
repo
is
publicly
available.
The
link
will
be
on
the
last
slide.
I'll
show
later
it'll
show
everything
here
in
good
detail
and
there's
readme's
all
over.
So
you
can
follow
along
what
we're
talking
about
so
to
get
started.
Let
me
zoom
in
here
so
we
can
see.
B
We
need
to
get
argo
cd
deployed
with
avp
installed
right,
so
jake
pretty
much
explained
how
that's
done,
but
I'm
going
to
show
you
in
a
little
more
detail.
What
I'll
show
you
is
doing
it
with
customize,
I'm
basically
going
to
use
a
customized
bundle,
make
a
few
changes
so
that
we
have
the
repo
server
plug-in
and
then
I'll.
Have
that
I'll
show
you
how
you
know
that
works
out.
B
So
to
show
you
what
that
looks
like
if
we
go
over
here
to
the
repo
server
yaml
we'll
see.
Basically,
what
we're
doing
is
we
just
have
this?
You
know
empty
directory,
kubernetes
volume
that
we're
creating
ephemeral
volume.
We
have
our
init
container
in
this
case.
What
we're
doing
is
we're
basically
downloading
the
latest
release
of
the
plugin
from
github
releases.
So
that's
version
140
here
and
we're
basically
putting
it
in
this
custom
tools
volume.
What
we'll
then
do
is
we'll
take
our
repost
server
container,
which
again
is
the
actual
thing.
B
B
So
at
this
point
we
have
adb
downloaded
installed.
It's
just
a
matter
of
configuring.
It
right
and
there
are
multiple
ways
to
actually
configure
abp
to
be
able
to
communicate
with
your
secret
manager.
Like
jake
mentioned
what
we're
going
to
do
today,
because
it's
kubecon
is
we're
going
to
show
kubernetes
off.
So
what
that
means
here
is
basically
we're
going
to
have
a
vault
instance
running
in
our
kubernetes
cluster
here
and
we're
going
to
have
the
two
communicate
to
each
other
using
kubernetes
off.
B
B
So
it's
just
going
to
be
here
in
our
cluster,
I'm
going
to
make
that
we're
going
to
use
kubernetes
auth
to
be
able
to
authenticate
to
it
and
we're
going
to
use
the
argo
cd,
vault
rule
and
I'm
going
to
show
you
how
we
set
up
the
roles
in
vault
so
that
kubernetes
auth
works
and
then,
finally,
because
the
repo
server
doesn't
usually
have
the
service
account
token
mounted
and
you
need
a
service
account
token.
So
you
actually
do
keep
grenades
off.
We
just
you
know,
make
sure
you
have
one
mounted.
B
So
all
that
to
say
you
have
this
cus!
Oh
sorry,
one
more
thing
I
just
showed
you
the
replay
server.
I
didn't
show
you
the
config
map,
so
the
last
thing
is
just
actually
being
able
to
register
it
as
an
argo
plugin.
What
you'll
see
here
is.
I
have
two
different
plugins
sort
of
described
here.
I'll
talk
about
the
helm,
one
in
a
second
or
a
little
bit
later,
but
the
simple
one
here
is
just
called
argos,
3d
volt
and
what
you'll
see
is
all
it
does.
B
Is
it
just
runs
our
vault
plugin
binary
generate
command
on
dot.
Slash
dot,
slash
beating
the
yamls
that
you
have
of
the
argo
app
that
you're
trying
to
deploy
so
it'll
run.
You
know
the
plug-in
through
those
ammos,
replace
the
placeholders
and
send
the
rest
to
standard
out
so
that
argo
can
apply
them.
B
Yep
and
I've
got
you
know
credentials,
so
I
can
actually
pull
from
get
cool.
So
now
I
think
I've
shown
you
everything.
I
think
I've
already
gone
ahead
and
set
up
port
forward,
so
I
can
actually
show
you
the
argo
cd
ui
looks
like
we're
good.
I
have
this
vault
instance
deployed
we'll
talk
about
that
in
a
second,
but
just
to
show
you
that
the
plugin
has
been
installed
correctly.
B
B
B
So
I
have
vault,
I'm
using
the
vault
helm
chart
to
keep
my
life
simple
here
and
if
you
look
at
how
I've
deployed
the
vault
helm
chart
here
in
the
parameter
section,
what
you'll
basically
see
is
that
I'm
going
to
run
the
dev
server,
which
you
should
not
do
in
production,
and
I
have
this
postcard
script
and
what
this
postcard
script
is
doing.
Is
it's
basically
waiting
for
vault
to
start
up?
B
We
are
creating
a
vault
policy
that
allows
reading
secrets
at
the
secret
path,
we're
basically
so
we're
creating
that
policy
in
vault
right
and
then
we're
going
to
enable
kubernetes
off
and
we're
going
to
tell
vault
where
our
kubernetes
host
is
so.
We
can
actually
talk
to
the
cube,
randy's
master
and,
most
importantly,
maybe
I
have
to
zoom
out
so
I
can
show
all
this
yeah.
B
We
are
creating
that
argo
cd
role,
so
this
is
the
role
that
we
configured
avp
with
earlier
right,
so
we
could
tell
avp,
you
know
log
in
with
fault
and
use
this
role
and
we're
granting
that
role
to
the
default
service
account
in
the
default
namespace,
because
in
this
case
this
is
where
the
repo
server
is
running
and,
most
importantly,
we
are
granting
that
demo
policy
that
was
created
up
here
for
that
service
account.
So
we
have
everything
we
need.
We
have
the
repo
server
and
we
have
vaults
again.
B
B
So
just
a
collection
manifest
and
get
what
we're
going
to
do
is
we're
going
to
deploy
an
nginx
instance,
and
what
we're
going
to
do
with
this
engine
x
instance
is
we're
just
going
to
have
it
basically
print
out
the
value
of
a
secret
that
we've
deployed
through
avp,
so
I've
got
a
bunch
of
yml's
here
first
off.
This
is
config
map
that
basically
contains
an
enginex
configuration
file.
B
Don't
fret,
if
you're
not
familiar
with
nginx,
just
know
that,
basically,
what
this
says
is
we
listen
on
8080
and
for
all
requests
we're
going
to
return
a
200
with
the
value
of
this,
my
secret
environment
variable
very
straightforward.
So
that's
that
right,
that's
the
nginx!
Where
does
the
secret
come
from?
Well,
it's
going
to
come
from
this
kubernetes
secret
and
this
kubernetes
secret
is
what's
going
to
be
created
through
abp,
and
what
you'll
notice
here
is
that
the
secret
has
a
special
annotation.
B
This
is
the
annotation
jake
was
referring
to
earlier,
where
we
tell
abp
where
to
look
in
vault
for
our
secrets.
The
way
you
read
this
example
is
there
is
a
my
nginx
secret
at
this
path:
secret
data,
because
this
is
a
vault
using
kv
the
kv
v2
engine
and
inside
of
the
secret
there's
a
password
key,
and
I
want
to
interpolate
the
value
of
that
password
key
as
part
of
the
my
genex
secret
for
this
variable.
That's
how
you
read
the
syntax
here
and
that's
what
we're
doing
so.
We
have
our
config
map.
B
We
have
our
secret
and
then
we
just
need
an
actual
nginx
image,
so
we
can
run
this
and
actually
you
know
make
this
work
right.
So
we've
got
a
little
open,
rusty
image
here
using
a
port
8080
like
we
said
earlier,
we're
going
to
mount
our
secrets
through
environment
variables
in
this
engine
x
instance
and
we're
going
to
mount
the
config
file
where
nginx
expects
it
to
be
in
this
image.
B
So
I've
put
all
this
stuff
in
get
already.
You
can
see
them
here
in
the
apps.
Slash
get
slash,
nginx
manifest
folder,
so
these
are
all
the
files
that
we're
going
to
be
deploying
here.
So
I've
already
created
them.
So
we
have
the
code
and
get
great
that's
the
first
step
for
githubs.
Now
we
just
need
to
make
our
secret
not
in
get
we're
going
to
put
that
in
the
secret
manager.
B
So
let's
go
ahead
and
do
that
so
first,
what
I'm
going
to
do
is
I'm
going
to
port
forward
to
the
vault
service
that
I
showed
you.
I
was
running
already,
so
let's
go
ahead
and
do
that
I'll,
just
zoom
in
so
you
can
see
here.
We
are
so
we've
got
vault
next,
I'm
going
to
basically
set
some
vault
variables
so
that
I
can
talk
to
my
vault
instance.
You
should
never
use
the
vault.
The
root
vault
token
should
probably
be
disabled
in
any
production
deployment
of
vault.
But
again
this
is
just
a
demo.
B
So,
okay,
we
should
have
everything
we
need.
I'm
going
to
create
a
secret
called
my
nginx,
because
that's
what
you
know
we
said
we're
going
to
do
in
our
secret
yaml
with
this
key
password
and
a
value
secret
password.
So
here
it
is
all
right:
we've
created
a
secret
and
I'm
going
to
read
it
back
just
so.
We
can
all
agree
that
yep
I
put
secret
password.
Okay,
now,
there's
a
way
you
can
create
argo
apps.
B
You
know,
because
argo
cd
comes
with
the
custom
resource
definition,
you
can
create
custom
or
you
can
create
apps
through
yaml,
but
I'm
going
to
show
it
to
you
in
the
ui.
You
know
just
to
make
it
hit
home
a
bit
better,
but
you
can
easily
do
the
just
yaml.
So
here
we
are
we're
going
to
make
an
app
called
my
genex.
How
fitting
I'm?
B
Just
going
to
put
it
in
the
default
project,
I'm
not
going
to
changing
the
sync
policies
here,
I'm
going
to
use
the
one
repo,
this
very
repo
that
I
have
configured
here.
The
path
that
contains
my
manifest
is
going
to
be
this.
This
one
here,
apps
get
nginx,
manifests,
appskit
nginx
manifests
and
I'm
going
to
deploy
to
my
local
cluster
and
my
default
namespace
and
the
most
important
thing
here
is.
I
got
to
tell
argo
cd.
I
want
to
use
our
plug-in
to
deploy
this
so
argo,
cd
vault,
so
I've
got
everything
right
here.
B
B
So
that's
the
yellow
here,
so
we
can
easily
go
ahead
and
just
synchronize
these,
and
what's
this
going
to
do,
is
that's
actually
going
to
run
our
plugin
actually
interpolate
the
secrets
create
the
resulting
secret
in
our
cluster
and
deploy
an
engine
x
instance
that's
configured
to
read
from
it.
So
why
don't?
B
We
make
sure
that
we
did
this
right
yeah,
let's
actually
try
to
talk
to
our
nginx
and
see
if
it's
returning
the
right
values,
so
I'm
going
to
port
forward
to
this
engine
x
instance
I
have
deployed,
and
if
I
go
over
to
localhost
8081,
which
is
where
I'm
running
it
great
you
see
here,
we've
got
secret
password
great,
so
we've
enabled
show
that
we
can
deploy
secrets
and
we
can
deploy
apps
that
use
them
with
argo
and
avp.
Now
we
just
need
to
actually
try
modifying
the
secret
in
our
secret
manager.
B
Right
because
you
know
I
can
show
you
how
to
create
one,
but
a
big
part
of
secret
management
is
rotating
them.
You
know
for
reasons
and
it's
an
important
use
case
to
be
able
to
handle.
So
what
I'm
to
do
is
I'm
going
to
simulate
a
secret
rotation
by
just
doing
a
vault
kb
put
so
I'm
going
to
put
a
new
value
for
the
secret
in
this
case.
We're
just
going
to
put
the
phrase
edited
at
the
end.
B
Just
read
it
back
out
for
us
real,
quick
and
now
the
question
is:
how
do
we
tell
argo
cd?
That's
that
the
secret
changed,
and
this
is
where
the
concept
of
a
hard
refresh
comes
in
during
a
hard
refresh
of
our
an
argo
app
argo
cd
will
take
any
custom
plugins
that
you're
using
to
deploy
the
app
do
a
dry
run
of
those
plugins
and
compare
the
output
to
what's
in
cluster.
If
there's
a
difference,
then
you'll
be
out
of
sync
and
you
have
the
opportunity
to
resync
once
we
do
that.
B
We'll
also
need
to
restart
deployment
since
we're
using
environment
variables
on
a
pod,
and
they
only
get
refreshed
when
you
restart
those
pods.
So
I'm
going
to
zoom
out
here
real
quick,
I'm
going
to
do
that
hard
refresh
all
right.
Our
secrets
have
out
of
sync
because
we
change
it
in
volt
the
plugin
ran.
B
We
realized
that,
what's
in
cluster,
does
not
match
what
we
want
it
to
be
and
we
can
easily
remedy
that
by
syncing,
so
we've
gone
ahead
and
synchronized
and
we
need
to
restart
the
deployment
like
I
said,
and
we're
going
to
have
a
new
nginx
starting
up
here
soon
and
now.
If
I
just
report
forward
back
to
our
app
we'll
be
able
to
then
refresh-
and
we
see
here-
secret
password
edited
so
great,
we
did
a
secret
rotation.
B
Thank
you,
yeah.
You
can
okay,
yeah
thanks
a
lot,
I'm
glad
it
worked
too
cool.
So
that
was
just
a
simple
example
of
you
know
a
bundle
of
manifesting
git,
but
you
can
also
use
this
tool
with
pretty
much
any
sort
of
yaml
json
templating
thing.
It's
really
just
a
matter
of
having
the
placeholders
in
the
first
sort
of
tool
have
something
rendered
than
to
have
abp
run
through
that.
B
B
So,
first
I'm
going
to
create
a
redis,
a
secret
for
my
redis
instance,
I'm
going
to
set
the
global
password
to
sh
with
three
h's.
So
let
me
go
ahead
and
do
that
here
and
I'll
just
read
it
back
just
to
be
sure
I
did
that
right
cool.
So
we
have
that
and
now
it's
just
a
matter
of
creating
the
argo
app-
and
this
is
a
very
simple
example.
I
wouldn't
recommend
actually
doing
this
for
any
real
reason.
B
B
B
You
know
our
templates
or
our
customized
things
or
json
or
whatever,
and
then
run
abp
on
the
result
to
get
yaml
with
secrets,
and
so
what
we're
doing
is
we're
basically
just
adding
our
helm,
repo
and
downloading
the
yamls
that
comprise
the
redis
chart
and
then
we're
just
going
to
run
helm
template
filling
in
some
stuff
with
argument
variables
and
then
actually
generate
the
manifest
with
avp
and
you'll,
see
this
little
hallmarks
thing.
This
is
basically
our
way
of
passing
things.
B
We
want
to
pass
to
helm
the
command
line
invocation,
since
you
know
we
have
to
do
this
because
it's
a
custom
plug-in.
So
this
is
just
our
way
being
we'll
pass
special
flags
to
helm
and
we're
taking
advantage
of
that
here,
so
that
we
can
basically
require
auth
on
our
redis
and
use
the
inline
path
placeholder.
That
jake
was
talking
about.
So
this
is
the
path
and
we're
going
to
use
the
password
key
and
that
secret
we
created
and
we're
going
to
use
that
to
set
this
global
redis
password
so
real
quickly.
B
B
B
One
more
thing:
this
is
the
slide
with
the
links,
so
we've
got
the
repo
link
there.
We've
got
documentation,
you
know
as
part
of
our
repo,
our
github
pages
and
there's
a
demo
repository
where,
if
you
don't
take
my
word
for
it,
you
can
be
sure
the
reddest
example
works
so
and
some
blogs
that
have
been
written
on
this.
So
thanks
so
so.
D
B
Good
question
so
because
it
was
a
secret
that
changed
the
argo
ui
will
always
redact
the
values
of
secrets.
You
won't
actually
be
able
to
see.
Oh,
the
secret
was
previously
secret
password
and
now
it's
secret
password
edited
like
I
don't
know
what
the
difference
is.
You
won't
be
able
to
do
that.
Really.
I
guess
in
that
case,
what
I'd
recommend
is
just
going
into
the
secret
manager.
C
B
A
A
Yeah,
so
what
you
can
do
is
because
it's
based
off
environment
variables,
jesus
sorry,
you
can
go
into
the
like
when
you're
setting
them
up.
You
can
set
the
specific
environment
variables
for
each.
You
know
deployment,
and
so
you
can
like
you,
can
have
certain
applications
use
certain
environment
variables
that
point
to
the
different
service
accounts
that
you
set
up
and
that
way
you
don't
have
like
one
set
of
credentials.
B
That's
a
good
question,
so
you
know
argo
cd
does
have
a
rest
api.
So
if
you
do
have
a
way
of
like
I
don't
know,
you
change
a
secret
and
then
you
have
that
call
some
sort
of
web
hook
right.
You
could
tell
argo
cd,
hey
do
a
hard
refresh
for
this
app
and
that
if
you
have
automated
sync,
then
you
could
have
an
automatic,
complete
rotation.
F
F
B
So
that's
a
fair!
So
if
I
understand
correctly,
you
are
talking
about
the
when
we
register
the
config
when
we
actually
register
the
plugin
in
the
argo
city
config
map
and
how
we
have
to
have
that
bash
stuff
to
be
able
to
tell
how
it
works.
So
that
is
fair.
I
will
say
that
is
a
one-time
thing
right,
because
once
you
have
once
you
have
this
set,
I
mean
you:
have
it
forever?
You
don't!
You
know
once
you
have
an
argo
cd
that
is
using
this
config
map,
it's
it's
good
to
go.