►
From YouTube: JWT token in GitLab CI
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
we
have
like
a
couple
of
options,
and
one
of
them
is
just
to
use
the
secret
keyword
which
brad
suggested,
but
I
know
marshall.
You
had
some
comments
on
that.
The
other
one
is
to
configure
the
token
within
the
secret
block
itself,
and
this
is
what
marshall
you've
suggested.
If
you
want
to
like
both
of
you
like
verbalize,
and
explain
like
the
thought
process
here,
and
so
we
can
try
to
resolve
this
discussion
quickly.
C
I
think
sorry,
so
my
understanding
of
of
why,
like
the
thought
process
behind
that,
was
that
we
were
trying
to
come
up
with
something
that
was
clever
and
and
would
avoid
users
having
to
specify
anything
but
basically
like
avoiding
a
a
breaking
change
like
making
the
default
template
work.
The
way
that
it
does
today,
essentially.
C
C
You
you
want
to
that
to
be
explicit,
and
so
anything
that
is
going
to
result
with
a
token
being
implicitly
injected
into
one
or
all
jobs
by
default.
I
think,
is
not
what
we
ideally
want
right
and
then
the
the
second
big
thing
is
that
the
proposal
specifically
is
talking
about
extending
secrets,
with
top
level
keywords
that
have
behavior.
That
is
specifically
related
to
the
injection
of
the
jdt
token
two
problems
with
that
one,
the
this
this
block
of
the
emel
syntax.
C
It
already
has
key
value
pairs
where
key
is
our
environment,
variables
and
and
the
value
is
the
configuration
for
how
to
inject
that
that
secret
right.
So
I
think,
breaking
that
convention
is
not
a
good
idea,
because
you'd
expect
all
top
level
keys
to
be
environment,
variables
and
environment
variables
can
be
lower
case
right,
so
that
that
doesn't
make
a
lot
of
sense
and
then
two
there's
nothing.
That's
specific
to
jdbt's,
necessarily
with
secret
injection
right
so
having
top-level
keywords
under
secrets
that
are
specifically
related
to
jdbts.
C
So
I
that
being
said
like,
I
think
it
does
make
sense
to
consolidate
and
not
have
a
separate
top
level.
Like
token
keyword
necessarily,
I
think
I
think
there
is
an
opportunity
to
have
all
this
functionality
exist
within
the
secrets
keyword,
but
the
what
was
proposed,
I
think
is,
is
is
not
the
right
solution
and-
and
I
tried
to
come
up
with
something
that
I
think
might
fit
the
bill
and
I'll
I'll
paste
it
in
the
zoom.
C
The
link
in
the
zoom
chat,
if
other
folks
aren't
already
looking
at
the
issue
thread,
but
you
know
similar
to
how
the
vault
keyword
within
secrets
works
today
like
we
could
also
have
a
id
token
keyword
that
would
generate
a
jbt
and
then
set
it.
As
you
know,
whatever
environment
variable
key,
you
specify.
A
C
C
D
Is
not
a
global,
true
global,
it
is
per
job
and
in
fact
I
ran
into
it
and
I
I
wished
it
was.
I
wish
there
was
a
global
version
of
it
just
like
variables
right,
but
variables
act
differently
than
secret,
so
secrets
have
to
be
specific
or
or
you
have
to
use
like
a
yemel
anchor
on
every
job,
which
is
basically
the
same
thing,
but.
B
A
D
D
Stanza
was
more
around
simplification
and
not
yet
another
area
for
configuration
right
and
it
you
know
what
other,
what
other
expansion
is
there?
So
there's
there's
jwt
token,
but
there's
also
ci,
there's
also
the
ci
token.
That's
been
around
a
lot
longer
and
has
a
kind
of
a
very
different
behavior
right,
that's
automatically
injected
into
every
job.
That's
not
opt
in.
D
Those
are
those
are
things
that
I
was
I
was
thinking
of
in
that
and
then
also
giving
a
path
towards
linking
jwt
and
secrets
together
because
they
provide
similar
functionality.
But
not
the
same
right
like
one
is
a
premium
feature,
the
other
one
is
in
core.
You
have
to
roll
your
own.
You
know
secrets
man,
you
know
secrets
access
with
jwt,
which
gives
us
expanded
use
cases
around
like
aws,
whereas
we
don't
have
that
in
c.
We
only
started
with
vault.
D
C
D
D
D
That
would
actually
be
good
and
I
think
clarifying
that,
if
you
had
you
know
instead
of
ci
job
jwt,
you
know
any
variable,
1
id
token
any
variable,
2
id
token
different
audience.
You
know
those
kind
of
things.
I
think
that's
that
works
out
well,
because
people
you
know
could
probably
put
that
into
an
existing
an
existing
script
or
substitute
an
existing
variable
where
they
may
have
had
a
static
token
before
or
something.
C
Yeah
and-
and
I
think
like
to
your
point
about
the
fact
that,
like
other
tokens
are
injected
by
default,
I
think
that's
also
problematic.
I
think
that
we
also
shouldn't
have
done
that,
and
I
think
that,
like
again
those
use
cases
where
tokens
are
automatically
injected,
we
can
move
those
to
the
secrets
keyword
over
time
as
well
like,
for
example,
I
think
currently,
every
job
in
the
pipeline
has
the
same
level
of
access
to
the
container
registry
right.
That's
that's
not
good!
C
A
Yeah,
I
I
I
agree,
but
I
I
really
want
us
to
focus
on
that
specific
subject
and
not
open
it
broadly
to
like
all
the
the
tokens
that
we
have.
I
mean
we
can
roll
out
like
different
breaking
changes
like
if
we
think
that
this
is
like
the
right
behavior,
we
can
definitely
mitigate
those,
and
if
it's
like
a
if
it's
a
security
risk,
we
can
even
do
it
in
the
middle
of
from
ourselves.
We
don't
need
to
for
in
order
to
introduce
like
a
security
enhancement.
A
So
it
doesn't
need
to
wait
for
like
next
year.
But
for
this
specific
scenario
I
I
would
like
to
have
it
ready
for
for
15-0,
because
users
expect
to
have
a
breaking
change
in
50-0
and
if
we'll
be
able
to
come
up
with
the
right
convention
and
the
syntax,
then
we
might
have
like
a
window
of
opportunity
to
implement
it
in
15-0.
A
So
I
just
want
to
understand
the
the
the
idea
here
is
that
secret
will
be
nested
underneath
a
job
right
like
when
you
want
to
opt.
In
a
token
you
specified
up,
you
specify
secret,
and
then
we
have
like
the
ci
job
jwt,
and
you
mentioned
that
it
could
be
like
any
variable
or
any
secret
variable.
I
guess,
but
my
concern
here
is
that
again
we
are.
A
We
are
making
like
this
feature,
bigger
than
that
we
will
be
able
to
handle
for
this
iteration,
and
this
will
require
like
additional
discussion,
because
basically,
what
we
are
doing
here,
if
I
understand
correctly,
is
that
we
are
creating
our
own
secret
in
gate.
Lab
like
you,
can
define
any
secret.
You
want.
A
You
can
add,
like
any
idea
to
that
to
the
secret,
and
basically,
you
will
create
like
a
handful
of
secrets,
which
is
something
that
we
can
definitely
discuss,
but
I
think
this
needs
to
discuss
in
a
broader
level,
with
the
product
organization
make
sure
to
have
like
the
right
allocation,
and
you
know
the
whole
process
that
we
need
to
do
in
order
to
introduce
a
new,
a
new
feature
in
this
size,
and
I
think
for
now.
We
really
need
to
contain
it
too
right
now
we
have
a
problem.
A
The
jwt
token
is,
by
default
opt-in
to
any
job.
Let's
try
to
come
up
with
a
syntax
just
for
that
talking
for
now
to
to
mitigate
this
problem,
because
we
have
an
opportunity
and
we
can
take
the
discussion
about
like
the,
and
I
think
we
have
an
epic
on
secret.
We
can
take
this
discussion
and
we
can
create
a
business
case
so
we'll
be
able
to
get
like
the
right
funding,
and
you
know
the
right
engineers
to
build
that
kind
of
solution.
D
So
go
ahead:
if
you
only
want
to
solve
the
opt-in
problem,
inclusion
of
secrets,
you
know
blank
or
not
blank
right,
nothing
underneath
it
that
could
work,
but
the
the
two
other
requirements
around
a
customizable
audience
field.
We
gotta
have
a
place
for
that
like
where
do
we?
Where?
Where,
where
does
that
go
from
because
that'll
that'll
live
for
a
long
time
too,.
A
I
agree
again.
We
definitely
need
this,
but
that's
the
second
question
that
I
have
do.
We
need
it
in
the
first
iteration
because
right
now
today,
users
cannot
customize
the
audit.
It's
not
the
desirable
experience
that
we
want.
I
agree
we
want
to
fix
that,
but
what
I'm
suggesting
is
like
just
use.
The
secret
stands
out
the
secret
keyword
to
opt
in
and
then
in
the
next
iteration,
we'll
tell
user
hey
in
15-0.
C
And
yeah,
the
the
reason
I
think
that,
like
both
are
important,
is
because
like
leaving
either
either
one
of
them,
as
is
compromises
the
like
security
of
the
user's
setup,
so
so
the
the
implication
with
not
making
the
audience
claim
configurable
is
that
whatever
provider,
the
user
is
trying
to
use
that
token
with
that,
they
have
to
disable
audience,
claim
validation
on.
On
that
end,
right,
like
and
for
context,
the
audience
claim
in
the
jdt
spec
it
it's
intended
for
consumers
of
jwts
to
validate
that.
C
This
token
was
issued
for
that
service
and
the
reason
you
want.
That
is
because
otherwise
services
can
pass
the
same
token
around.
You
know
basically
replay
it
to
to
to
other
systems,
and
those
systems
have
have
no
way
to
know.
They
have
no
way
to
verify
that
that
that
the
token
was
intended
for
them.
C
Because
I
think
it's,
I
think,
it's
better
for
the
end
user
to
have
their.
You
know
whatever
they're,
using
these
tokens
for
whether
it's
vault
or
exchanging
for
cloud
provider
credentials
or
using
with
a
certificate
transparency
service
like
folkio
or
whatever
it's
important
that
we
lead
by
default.
We
lead
users
down
a
path
that
results
in
them,
setting
up
a
secure
system
and
so
like
I'd
hate
to
like
continue
down
this
path.
C
Where,
like
audience,
claims
are
hard-coded
and
users
configure
their
systems
to
disable
audience,
claim
verification,
and
then
we
introduce
the
ability
to
to
customize
the
audience
claim.
But
people
already
have
these
systems
that
they're
not
going
to
change
out
there
that
that
are
less
secure
than
they
they
should
be.
A
A
This
is
why
we
have
mark
here
is
that
if
this
is
something
that
we
are
capable
of
doing,
and
if
not
the
then
we'll
need
to
default
to
not
having
this
in
15-0
and
have
it
in
15
15
one,
although
it's
not
a
desirable
experience
now
you
mentioned
that
okay,
this
means
that
will
tell
users.
Okay,
you
need
to
disable
the
audience
claim
in
your
system,
but
I
mean
we
are
aiming
here
for
you
know,
for
for
the
long
term,
we
will
have
way
more
users
in
a
year
than
we
have
today.
A
Today
we
don't
have
with
really
like
few
thousands
of
users,
and
I
believe
that,
like
in
the
year,
would
the
double
so
anything
that
we'll
do
now
does
not
mean
that
it
will
dictate
the
way
users
will
behave
like
most
of
ours
will
behave
in
the
future.
But
I'm
not
I'm
not
saying.
Let's
not
do
that.
I'm
just
saying,
let's
see
if
we
are
capable
of
doing
that
in
15-0,
and
if
not,
then
we
need
to
rely
on
like
secrets
and
like
hardcore
the
audience
and
in
15-1
we'll
introduce
like
the
ordinance
claim.
A
D
C
It's
kind
of
hard
to
yeah,
like
look
looking
at
your
implementation
of
the
ci
job,
gdt
v2.
I
think
the
the
the
difference
between
making
the
audience
claim
configurable
and
not
is
like
so
trivial
from
like
a
code
perspective
that
there's
no
reason
not
to
just
make
it
configurable
from
from
day
one,
and
I
think,
like
you
know,
we
already
have
the
secrets
stands
up
like
we
already
have
the
plumbing
for,
like
you,
know,
mapping
like
this
provider
to
generating
this
thing
and
then
injecting
it
as
this
environment.
C
C
If
we're
all
bought
into
doing
going
down
that
path,
then
the
additional
configuration
option
of
having
the
audience
claim,
I
think,
is
a
and
using
that.
In
the
token,
it
is
trivial
because
we're
not
even
talking
about
implementing
any
of
the
logic
for
actually
generating
jvts
right,
like
all
of
that
stuff
exists,
it's
just
pulling
this
configuration
value
into
that
audience
claim
and
then
passing
it
along
to
the
thing
that
automatically
generates
quts
so
like.
I
think
this
whole
thing
is
like
a
two-day
effort.
You
know
not
including
testing
and
roll-out
and.
A
Yeah
I
mean
I
mean
we
cannot,
I
mean
again,
we
there
is
a
I
like,
I'm,
not
an
engineer.
Okay
and
I
I
don't
want
to
put
myself
in
a
commitment
for
for
for
the
for
the
engineers
here
again.
This
is
why
we
have
mark-
and
we
can
definitely
looking
to
see
if
it
makes
sense
we
need
to
have
tests
in
place.
We
need
to
make
sure
we
have
the
right
documentation
for
all
of
our
users,
because
it's
going
to
be
like
a
bigger
breaking
change
that
what
what
we've
expected.
A
So
we
need
to
test
and
make
sure
that
you
know
use
cases
are
working
and
by
the
way,
I
would
need
your
support
with
that,
like
whoever
use
that,
because
we
don't
use
it,
we
don't
have
like.
We
have
testing
environment
to
check
the
integration
works,
and
then
you
know
make
the
right
like
announcement
for
our
users.
So
again
it
will
go
to
that
path.
We'll
definitely
need
your
your
support
in
those
areas.
A
D
Yes-
and
I
think
you
would
have
a
you,
the
question
is:
do
you
have
a
default
value
or
not?
So,
for
example,
github
has
a
default
value.
It's
I
think
it's
the
project,
the
full
project
url
or
something
which
is
not
the
most
ideal
audience
value,
but
it's
probably
a
good
default,
but
yeah
it
would.
It
would
always
be
included.
A
D
D
C
D
C
D
C
But
what
you're
pointing
out
is
valid
that
there
needs
to
be
some
relationship
between
what
at
least
optionally,
like
the
token
that
you're
explicitly
specifying
and
the
subsequent
secrets
that
are
being
injected
right.
I
think
that's
what
you're
getting
at,
because
if
I
call
it
like
my
custom,
jbt
or
my
vault
jwt,
I
have
to
make
the
vault
integration
aware
that
that's
the
token
that
I
want
to
use
right.
D
C
Yeah
so,
and
this
example
is
not
great
looking
back
at
it
because
like
it,
would
it
would
it's
it's
more
compelling
if
you're,
if
you
have
one
jbt,
that's
for
vault
and
then
another
jbt,
that
is
for,
like
the
google
provider
right
so
like
imagine
that
you
are
generating
you're,
injecting
two
separate
tokens
right.
One
is
because
you
want
to
generate
google
application
credentials
and
the
other
is
because
you
want
to
inject
some
database
password
from
bulb.
D
D
D
D
C
D
C
Token
here
could
could
could
be
something
that's
coming
from
from
a
environment
like
a
like
a
ci
environment.
Variable
that's
configured
in
the
project
right
like,
I
think
we
need
to
not
be
opinionated
about
where
that's
coming
from
it
just
happens
to
be
something
that's
getting
defined,
also
in
a
secret.
D
C
D
D
So
you
define
your
jwt
for
vault,
you
define
it
for
google
and
then
you
consume
it
in
the
individual
providers
yeah.
You
know
any
other
job
that
needed
it,
but
it
like.
This
is
a
this.
This
is
a
premium
feature.
This
doesn't
exist
but
you're
just
saying
for
a
future,
that's
possible
right.
We
could
have
other
providers
and
then
somewhere
else
we
would
potentially
consume.
C
Yeah
because
they
can
be
consumed
in
the
pipeline
itself,
right,
like
all
the
google
application
credentials.
Example
in
the
vault
example
are,
are
both
like
nice
to
haves
that
that
that
are
embedded
in
in
the
runner
right,
but
you
can
do
everything
that
those
things
are
doing
in
a
pipeline
too,
like
in
a
script
and
so
making
it
possible
to
to
do
it
either
way
is
what
you
want
to
end
up
with.
I
think.
C
So
I
guess
the
only
question
is
like
whether
we
like
have
some
default
value
for
token
right,
so
that
that
can
be
skipped.
But
I
don't
know
it's
a
little
bit
clunky
if
you're
injecting
multiple
secrets
from
bolt
right
to
have
to
specify
that
token
again
and
again
and
again-
but
you
know
I
don't-
have
a
good
good
solve
for
that.
Nor
do
I
think
it's
like
something
that
we
absolutely
need
to
solve.
D
C
B
D
Yeah
we
have
otherwise
we're
down
to
a
single
single
default
value
and
then
you're
turning
off
validation
well
you're
still
validating
the
default
value,
but
it
doesn't
prevent
the
replay
attack
provider
replay
exactly
like
if
aws
were
to
send
it
over
to
google.
Google
potentially
could
could
accept
that.
C
And
like
by
by
default,
google,
you
see
the
workload
identity
provider
part
there.
This
is
this
is
the
default
value
that
google
requires
the
audience
claim
be
set
to
so
like
right
now,
if
users
want
to
use
jdbt's
the
way
that
we
support.
Currently
they
have
to
go
and
disable
or
like
manually,
override
the.
D
Yeah
they
have
a
default
value
of
what
they
could
expect
or
you
could
you
got
to
set
it
on
one
side
or
the
other
right
like
it.
Just
has
to
match
and-
and
I've
got
an
example
project
where
I
set
it
up
in
google,
and
we
tell
google
expect
the
I
think
it's
the
default
value
we're
using
and
v2
is
like
the
server
name
or
something.
C
D
D
D
A
I
think
I
think
that
for
this,
for
this
requirement,
as
I
mentioned,
it's
like
you
are
creating
like
a
secret
management
system
within
within
gitlab
in
in
our
syntax,
and
that
requires,
as
as
I
mentioned
in
the
beginning,
it
required
the
right,
the
right
research
and
the
rise
in
the
right
business
case
in
order
to
to
go
ahead
and
build
that.
I
know
there
is
an
epic
on
that
by
the
way
and
I'm
planning
to
do
something
about
it
this
year.
A
But
it's
not
something.
It's
definitely
not
something
that
we'll
be
able
to
achieve
at
the
moment
and
yeah.
So
I
think,
for
now
we
need
we
need
again
to
default
back
to
like
using
like
a
single,
the
jwt
token
that
we
have
today
opt
in
and
if
we
can
configure
the
audience
and
configure
the
objects.
We
need
to
be
very
humble
in
like
what
we
are
aiming
for
a
single
iteration,
because
there
are
always
like
false
prioritization.
B
I
think,
as
it
relates
to
that
opt-in,
I
know
we're
at
time
so
I'll
just
say
for
that
opt-in
issue.
I
think
the
only
touch-up
that
dove
if
you're
gonna
make
this
change
is
to
remove
that
future
enhancement
reference
in
the
description
area
to
include
that
in
and
then,
if
that's
the
approach
that
we're
going
to
try
to
kind
of
estimate
out.
C
I
I
think
the
only
thing,
the
only
path
forward
that
I
see
that
doesn't
involve
going,
that
extra
mile
is
to
have
a
new
new
keyword.
I
don't
see
how
we
can
reconcile
leveraging
the
existing
secrets,
keyword
for
controlling
gdp,
token
injection
and
not
like
that
extra
step
that
that
brad,
just
laid
out
of
specifying
which
token
gets
used
for
each
of
the
different
secret
injection
providers.
A
Yeah
I
mean
we
can
we
can
we
can
introduce
that
keyword,
I
mean
if
we
wanted
to
be
nested
under
this
secret,
so
we'll
have
like
secrets,
and
then
we
have
like
your
example.
You
had
like
the
ci
job,
jwt
or
maybe
jwt,
took
it
or
like.
We
need
to
have
a
preserved
keyword
for
now
and
and
then
specify
the
audience
plan
for
that
and,
for
the
token,
will
be
our
path
forward,
at
least
for
this
specific
issue
I
mean
we
can.
A
Or
maybe
we
can
use
like
maybe
ci
job
jwt,
because
it
is
the
the
actual
value
of
the
variable
can
be
confusing
for
users,
because
they
would
think
okay,
I'm
using
the
ci
job
jwt
I
can
use
like
any
other
token.
So
maybe
maybe
we
can
brainstorm
a
bit
without
technical
writer
about
what
would
be
like,
maybe
just
gwd.
D
C
A
Yeah
I
mean
the
the
variable
that
we
will
be
injected
will
be
v2,
but
we
won't
call
it
v2.
It
will
be
like
the
the
jwt
token
like
the
default
one.
So
that's
where
we
are
flipping
this
is
this
is
done.
I
mean
this
is
like
already
scheduled
for
15-0.
This
is
like
an
enhancement
on
top
of
it,
and
the
idea
is
to
have
like
a
single
breaking
change
that
will
change
this
for
for
our
users
and
that's
that's.
C
C
D
A
A
You
know
this
all
url
yeah
with
this
change.
They
need
to
do
this
and
update
those
syntax.
Those
will
be
like
two
changes
that
they
they'll
need
to
do.
The
first
one
that
I
mentioned
is
already
scheduled
and
weighted,
and
our
engineers
start
already
looking
it.
So
it
is
like
for
me
this
is
done.
This
is
going
to
happen.
This
is
bound
to
happen.
This
is
our
now
an
extension
on
top
of
that.
So
we
don't
need
to
worry
about
now.
They
want
to
go
back.
No,
we
won't
allow
them
to
go
back.
A
The
issue
with
with
this
proposal
we
can
take
another
round
of
you-
know
feedback
on
just
like
the
name
of
the
token,
maybe
maybe
maybe
tweak
it
a
bit
but
introducing
a
new
keyword
and
then
configure
the
audience
claim
and
see.
If
you
know
what
a
lot
of
the
engineers
are
saying
about,
you
know
the
probability
of
getting
this
in
15-0.