►
From YouTube: Pipeline Security team meeting APAC 2023-05-25
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
Hi
everyone:
this
is
pipeline
security
teams
meeting.
This
is
May
25th
and
a
couple
of
announcements
today.
So
just
a
heads
up
that
Jocelyn
will
be
on
PTO
early
June
and
tomorrow
is
a
family
and
friends
day
and
I.
Think
it's
also
a
public
holiday
in
Europe
for
most
of
the
folks
on
Monday
as
well.
So
it's
going
to
be
a
long
weekend
again.
A
Another
announcement
is
that
we
just
released
the
engagement
survey,
so
please
take
some
time
to
fill
this
up.
If,
if
you
can-
and
we
got
another
cure
for
Q2,
which
is
about
reading
or
documentation
regarding
self-manage,
so
we
can
refresh
ourselves
with
what's
the
expectation
when
we
deliver
future
self-managed
user.
A
A
A
Yeah
I'm,
already
trained
with
the
cat,
so
I
think
I'll
manage
it,
but
yeah
thanks.
Everyone
appreciate
it
and
last
point
is
from
Dimas
World,
which
is
also
long
weekend
for
him
because
of
public
holiday
on
Monday
and
family
and
friends
day
on
Friday,
okay,
so
to
jump
on
the
discussion
topic
for
this
week,
Jocelyn
open
NMR
to
kind
create
a
new
template
that
we
discussed
the
past
few
weeks
about
creating
our
own
issue
template.
So
we
can
bring
consistency
when
creating
issues
and
help
us
organize
our
work
better.
A
A
D
A
All
good
okay,
so
next
point
is
from
vitica
who
perform
a
great
competitor
evaluation,
looking
at
the
different
provider
out
there,
so
Azure
RC,
Corp
and
AWS,
and
she
recorded
a
video
explaining
briefly
how
all
the
tools
are
working.
So
she
can
have
a
better
understanding
of
what
we
want
to
build
for
users
and
from
that
it
looks
like
we
identified
the
work
being
in
like
three
different
parts,
which
is
first,
one
like
you
need
to
use
setup
default.
A
So
this
is
sometimes
complex
for
users
and
the
next
step
will
be
to
add,
like
a
user
policy
with
permission,
and
all
of
that
saying,
was
able
able
to
read
the
secrets
or
create
different
secrets,
and
the
last
step
is
to
create
the
secrets.
So
those
are
the
three
different
steps
that
we
identified
and
that
you
can
watch
on
the
video,
and
this
brought
up
more
question
for
Albert.
Do
you
want
to
correlate
them.
B
Yeah
so
I
looked
through
some
of
the
chips
recording
and
also
I
was
trying
out
gcp
secret
manager.
Is
it
what
is
called
so
I
have
a
question
about
encryption
requirement
from
the
customers
like
how
much
customization
in
terms
of
how
we
encrypt
the
secret,
while
in
storage,
is
because,
for
example,
do
we
I
will
be
our
customers?
Okay,
with
centralized
key,
that
gitlab
used
to
encrypt
all
secrets,
or
do
they
want
options
to
be
able
to
encrypt
their
own
secret
using
their
own
key
one
of
those
things
that
in
gitlab?
B
That
I
can
ask
Erica
again
in
in
that
issue:
okay,.
A
Yeah-
let's
do
that,
so
maybe
she
she
will
have
the
answer.
Otherwise,
that's
a
great
point
to
us
to
Jocelyn
and
vtk
if
she,
if
they
are
aware
of
it,
because
yeah
you're
right
like
this,
will
totally
change
the
solution
that
we
will
build.
So
we
need
to
get
that
answer.
First,.
B
Because
if
we
require
customers
to
bring
their
own
key-
or
rather,
if
we
give
options
for
that,
then
we
need
to
also
think
about
how
do
we
do
the
key
exchange
or
how
do
customers
provide
their
key.
A
No
okay,
so
next
point
is
from
Jocelyn
who
wants
to
encourage
Community
contribution
for
build
artifact,
because
we
still
have
a
couple
of
books
that
we
need
to
to
fix,
and
she
is
thinking
about
the
how
we
could
better
engage
with
the
community
here
to
help
us
Albert.
Do
you
want
to
verbalize
your
points.
B
Yeah
I
think
it's
a
good
idea
in
terms
of
process.
I
am
not
sure
what
is
the
label
to
use
I
think
it
used
to
be
accepting
much
requests,
but
they
might
have
been
changed
to
something
else.
So
we
should
ask
contributor
success
team
who
is
more
familiar
with
this
process.
A
I
think
Alberta
is
the
answer
for
you
Marshalls
right.
E
B
I
think
we
have
like
individual
issues
for
different
pattern-
child
reports,
so
maybe
we
can
apply
those
to
each
of
those
use
case
and
then
that
can
be
one
piece
of
work
for
a
hackathon
or
something.
A
Oh
good
next
point
is
again
from
Justin
who
wants
to
discuss
organization
and
filtering
of
our
labels.
So
right
now
we
have
two
labels
that
we're.
C
A
D
B
So,
for
a
I'm,
not
too
sure
whether
Justin
means
that
it
separates
Vault
Azure
versus
our
own
native
storage
plans,
or
is
it?
Is
she
saying
that
that
you.
B
C
B
More
inclined
to
keeping
secret
management
for
this
specific
purpose,
and
then
we
introduce
out
of
labels
for
things
that
are
not
secret
like
variables
get
rid
of
us
may
not
be
a
secret,
so
they
need
not
be
I,
don't
know,
but
some
some
people
might
argue
that
job
token,
when
we
put
them
as
a
variable,
then
that
becomes
a
secret
but
yeah.
So
what
is
Secret.
A
Yeah,
because
right
now
we're
using
the
two
category
labels
to
first
one
is
Secrets
management
and
the
other
one
is
CI
variables
and
we
have
other
labels
that
we
can
apply
to
issues
that
are
already
filtered
within
that
category
and
I.
Think
that's
what
we're
discussing
here,
like
the
other
label
at
okay.
A
No,
no,
we
will
keep
using
it.
It's
just.
We
will
add
an
extra
label
to
make
sure
to
better
understand
what
we
are
working
on.
A
C
I
was
just
yes
like:
do
we
see
some
benefit
on
splitting
the
secret
storage
into
tools,
categories,
separate
labels
like
one
for
native
and
then
one
for,
like
supporting
storage
from
third
party
like
float
and
Etc.
A
B
C
A
B
C
A
A
D
D
B
D
I
think
the
issue
is
that
the
GWT
token
doesn't
have
a
label.
So,
like
you,
you
wouldn't
put
CI
job
token
on
the
JWT
token
work,
because
they're
separate
and
so
I
I
suspect
that
Jocelyn
is
trying
to
find
a
way
to
categorize
the
jwd
work,
because
there's
there
there's
going
to
be
a
lot
of
work
and
like
authenticating
with
Vault
and
Azure
and
gcp,
and
everything
is
going
to
be
done
through
the
JWT.
So
it
I
mean
it
could
potentially
even
be.
D
You
know,
they'll
probably
be
merge.
Requests
that'll
have
both
Secrets
management
and
JWT
could
because
they're
they're
linked
together,
but
they
wouldn't
be
related
to
the
job
token,
because
that
the
probably
a
better
way
to
say
is
the
job
token
is
used
for
internal
authentication
to
authenticate
with
other
projects,
and
things
like
that
within
gitlab.
Well,
JWT
is
for
external
authentication,
with
other
Integrations.
B
I
might
be
wrong,
but
I
think
there
are
some
other
place
like
features
that
use
JWT
the
same
JWT
implementation.
C
B
Not
just
for
external
vault.
D
It
feels
like
you
could
I
I
I'm
just
guessing
it
feels
like
you
could
use
it
Json
web
token
to
authenticate
with
gcp
just
to
deploy
something
like
not
necessarily
to
to
to
pull
a
secret,
but
but
to
do
a
deployment
or
something
like
that
that
you
know
it,
it
might
accept
it.
So
it
could
be
just
you
know,
often
a
type
of
authentication
for
anything.
B
Yeah
I
think
it's
a
good
follow-up
form
from
that.
So
I'm
looking
to
Define
like
a
list
of
nomenclature
for
anything
related
to
secret
management.
B
B
Different
features
there's
a
lot
of
different
terminology
that
or
different
concepts
that
is
difficult
to
communicate
across
so
I
feel
like
having
a
list
of
terms
that
we
all
agreed
to
be
like
a
shared
vocabulary
will
be
really
helpful
so
that
everyone
knows
exactly
what
everyone
what
someone
else
is
talking
about,
especially
when
they
read
comments
or
issues
like
asynchronously.
There's,
no
room
for
any
misunderstanding,
like
any
misunderstanding,
rule
just
delay
conversations
so
having
that
crisp,
very
clear
language
mix,
I
think
is
important.
B
So,
let's
take
a
look
and
then
add
anything
that
you
want
to
add
or
any
concept
that
you
feel
are
difficult
to
capture
in
a
few
words,
then
I
think
that
indicates
that
we
need
to
Define
some
terms
for
those
so
yeah.
Please,
please
add
on
interestingly,
when
I
was
like
browsing
through
the
documentations
of
the
secret
manager,
I
think
Azure
or
AWS.
B
They
also
do
have
they
start
with
definitions
of
what
certain
words
or
phrases
are
in
their
documentation,
which
I
think
is
really
good,
because
then
people
use
that
same
language
like
the
customers
can
use
the
same
language.
Internally,
engineering,
product,
2x,
technical
writers,
all
use
the
same
language,
which
I
think
is
very
important.
D
But
yeah
just
on
the
thing
of
technical
writing,
we
don't
normally
do
glossaries
and
lists
of
vocabulary
very
often,
but
it
is
a
common
thing
for
for
people
to
do
and
we're
actually
kind
of
there
have
been
people
that
have
been
bringing
it
up
more
often,
and
so
some
of
some
groups
have
started
to
include
glossaries
either
a
separate
page
or
within
a
current
documentation,
page
and
I
think
we're
starting
to
open
up
more
towards
the
idea,
but
part
of
it
is
just
having
such
a
wide
feature
set
that
it's
hard
for
you
know
not
just
the
customers,
but
even
for
the
technical
writers
to
understand
everything
that's
going
on,
so
it
does
seem
like
like
this
Google
doc
is
useful
for
me
right
now,
like
I
read
through
it's
like
okay,
I
see
what
you
mean.
D
B
I
think
just
to
be
clear:
eventually
it
will
go
to
handbook
or
the
GitHub
Docs
I'm,
just
using
Google
docs
for
the
easiest
way
to
collaborate.
Yeah.
D
Yeah
absolutely
yeah,
just
I'm
saying
that
already
like,
like
you,
you
define
secret
secret
manager,
the
secret
keyword.
You
know
we,
we
we've
loaded
a
single
word
already,
with
three
different
definitions
and
there's
probably
more,
but
the
the
way
you've
written
it
out
here
does
help
me
a
lot
right
there.
So
I'm
just
trying
to
say
that
when
it
makes
it
to
the
handbook
or
the
docs
or
both
I'm
already
seeing
the
benefits
of
it,.
B
Okay,
I'll
just
move
on
to
the
next
item
in
the
interest
of
time.
Okay,
so
I
added
a
few
questions
on
the
okay
I
think
this
is
small,
mainly
for
Jocelyn
or
vitica.
B
There
are
some
questions
about
requirements
from
the
customers.
They
want
to
understand
because
again,
like
what
I
said
earlier
about
the
encryption,
so
some
of
these
things
will
this
help
us
decide.
How
do
we
approach
a
design
unable
to
design
an
implementation?
I?
Think
one
of
the
biggest
question
is
when
we
say
native
secret
manager.
Does
it
mean
that
it
is
part
of
the
gitlab
Rails
or
is
it
something
that
we
built
and
provide
to
the
and
that
the
users
can
host
themselves
like,
like.
B
Runner,
for
example,
these
two
make
a
lot
of
the
make
a
very
big
difference
in
terms
of
the
complexity
but
also,
more
importantly,
the
use
case
that
they
surf
so
I'm,
not
sure
like
what
kind
of
requirements
or
customers
in
terms
of
how
and
where
the
secrets
are
stored,
whether
it
can
be
gitlab's
environment
or
must
it
be
in
their
own
infrastructure.
B
So
whether
whether
a
customer
says
it
makes
a
difference
especially
to
SAS
customers,
because
for
self-manage
I
think
it's
really
straightforward
every
they
own
everything.
So
it
doesn't
matter
where
we
implement
it,
but
for
cell
phone
for
says
fast
customers,
it
make
a
difference
because,
on
one
hand,
having
it
it
be
part
of
rails
means
that
the
secrets
are
stored
together,
co-located
with
other
customers.
I'm,
not
sure
whether
this
will
be
a
concern
to
some
people
it
may
or
may
not.
It
may
not
be.