►
From YouTube: CNCF Security TAG Supply Chain WG 2021-09-16
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).
B
A
A
A
So
andreas
can
make
it
today,
so
I
will
pass
a
date.
Oh
if
dan
is
here,
he
will
also
help
out.
Let's
give
a
couple
couple
minutes
and
then
we
can.
C
Get
silent
brendan
mitchell
won't
be
able
to
make
it.
He
has
a,
I
think,
he's
going
to
some
docker
thing:
cool.
A
Okay,
cool,
so
just
wanna
go
doesn't
let
me
go
through.
I
think
everyone
here
has
been
here
before,
so
we
don't
need
to
do
any
new
introductions.
Please
correct
me
if
I'm
wrong,
and
so
today's
agenda
is
going
to
be
kind
of
going
through
some
of
the
points
in
the
paper
figuring
out.
A
I
think
there
are
a
few
points
of
discussion
where
I
get
that
ironed
out
and
also
you
know
that
there
are
a
few
places
where
I
think
we
still
need
to
to
to
add
a
few,
a
few
more
details
to
clarify
a
few
more
things
other
than
that.
I
I
think,
based
on,
I
just
took
some
time
to
review
the
document.
I
think
it
looks.
It
looks
good
everything
before
the
prototyping
section,
which
we
haven't
really
gotten
to
yet
looks
spectacular.
I
mean
just
read
like
that.
A
Just
looking
at
this,
I
think
this
in
my
opinion,
you
know
already
useful.
So
that's
great.
So
let's
go
around
first
to
if
anyone
has
any
updates
any
interesting
thoughts
that
they'd
like
to
share
that.
Maybe
we
can
talk
about
in
future
meetings
or
we
can
just
discuss
about.
C
Sure
so
one
that
I
wanted
to
talk
about,
so
I
took
a
lot
of
what's
already
in
the
the
white
paper,
my
team
and
I
using
sort
of
the
open
source
tooling
started
to
build
up
a
reference
implementation.
This
is
just
purely
some.
You
know
a
poc.
This
is
not
intended
to
be
the
open
source
implementation
for
what
we're
doing
necessarily
with
the
cncf,
but
can
definitely
show
that
off
in
a
future
meeting,
there's
obviously
some
stuff,
that's
still
missing
some
stuff.
C
That's
probably
we
have
some
open
questions
about,
but
I
think
it
can
do
some
pretty
cool
stuff.
A
A
D
Sure
I'll
even
put
on
my
camera.
A
D
Is
that
working
okay
hi,
I'm
jason
hall?
I
work
at
red
hat
on
dozens
of
things,
one
of
which
is
techton
and
openshift
pipelines
and
prior
to
being
at
red
hat
working
on
that
I
was
at
google
working
on
all
of
that
stuff,
and
so
I
have
an
interest
in
how
stuff
gets
delivered,
I'm
also
on
the
cdf
governing
board
in
toc.
D
A
Awesome
thanks
jason
good
to
see
you
here
all
right.
If
not,
I
think
we
can.
We
can
jump
straight
in
so
I
know,
michael.
You
had
a
few
things
on
your
side
and
I
think
I
had
a
few
things
as
well,
so
you
can
cure.
C
Yeah,
I
think
one
of
the
big
ones-
and
this
is
something
that
came
out
of
some
of
the
stuff-
that
we
were
poking
around
with,
while
sort
of
writing
up
a
reference
reference
implementation
was
definitely
sort
of
the
need
to
clarify
a
bit
more,
how
we're
doing
emission
control
inside
of
this
the
secure
software
factory,
so
not
emission
control
for
like
signed
things
that
are
coming
out
of
it
and
policy
and
yaya,
but
actually,
how
do
we
sort
of
validate
that
you
know
as
an
example,
you
know
we
have
some
cicd
tools.
C
How
are
we
sure
that
the
cicd
tools
that
are
being
run
are
signed
and
have
been
validated
and
have
been
checked,
signed
off
on
and
that
somebody
hasn't
replaced
that
you
know
behind
the
scenes
and
the
same
thing
goes
with
builders
right
like
if,
if
I'm
using
something
like
canaco?
C
How
am
I
validating
that?
The
parent
image
of
my
doctor
file
is,
you
know,
signed
off
on
that?
You
know
yes,
you're
allowed
to
use
that
that
parent
image
and
if
you
want
to
see
me
break
that
go
attend
the
supply
chain.
Con
demo.
A
Yeah,
so
I
think
this
was
one
of
the
things
I
had
on
my
list
so
so,
but
that
you
brought
them
up.
Let
me
scroll
through
the
section.
A
So
I
think
that
that
is
like
a
couple.
I
think
the
two
main
parts
is
like
emission
control
for
for
use,
like
you
said,
outside
and
within
the
ambition
controller.
C
What
are
we
saying
is
a
reasonable
bottom
turtle
for
folks
to
sort
of
say:
okay,
I'm
trusting
this
level
of
base
image,
and
this
is
where
or
this
base
level
of
thing
and
then
moving
forward
from
it.
So
like
just
as
an
example
like
you
know,
we
could
go
all
the
way
down
the
chain.
I'm
not
saying
we
should
do
this
right
where
we
can
say.
Oh
well,
you
gotta
compile
your
linux
kernel
from
scratch.
Using
a
known,
you
know,
good
compiler,
I'm
not
saying
we
should
do
that.
C
But,
like
that's,
you
know,
potentially
an
argument
but
there's,
I
think,
a
more
reasonable
argument
around,
maybe
just
highlighting,
and
once
again
this
is
just
my
two
cents.
Other
folks,
chime
in
of
saying
you
know,
use
you
know,
signed
base
images
from
you
know,
organizations
you
trust
like
and
leave
it
open
to
to
that.
C
I
I
don't
know
like
like
as
an
example,
I
know
for
myself,
like
hey,
if
I'm
using
techton,
I'm
validating
that
I'm
using
techton
signed
images,
I'm
validating
that,
if
I'm
using
a
techton
specific
builder
like
the
get
one,
I
am
validating
that
that
was
signed,
oh
nice,
so
and
when
it
comes
to
sort
of
other
things
like
let's
say
I'm
using,
I
don't
know
a
rust
builder
like
okay
is
russ
signing
their
images.
If
not,
what
do
I
do?
C
E
So
yeah
so
I
mean
for
the
sake
of
sort
of
making
progress
right,
like
I
think,
ultimately
right.
We
want
as
big
a
surface
as
possible
to
to
be
that.
I
think
you
know
I
I
like
to
sort
of
carve
out
sort
of
a
line
in
the
sand
that
we
think
is
achievable
and
we
can
expand
over
time
using
the
sort
of
principles
of
how
we
do
these
things.
So
you
know
it.
E
I
think,
and
I
also
think
different
organizations
will
have
different.
You
know
tolerance
for
you
know,
accepting
things
from
other
organizations,
but
I
I
do
think
it's
a
really
good
point
to
sort
of
identify
sort
of
a
set
of
principles
but
and
that,
but
then
you
know
sort
of
carve
out
what
we
think
is
sort
of
practical
as
a
starting
point
and
then
sort
of
work
back
from
there,
because
this
will
take
years.
A
F
So
if
I
can
jump
in
and
add
a
depressing
point
whatever
we
do,
if
jenkins
doesn't
pick
it
up
and
make
it
a
default,
then
we're
missing
out
on
about
two-thirds
of
the
world's
workloads.
F
Sadly,
I
get
I
I
admire
where
tekton
is
going
and
I
think
it's
really
cool
and
it
it's
one
of
the
few
things
that
you
know
makes
me
sort
of
take
my
eyes
off
my
one
true
love
in
ci
systems,
but
ultimately
the
running
in
jenkins
in
bulk.
A
I
I
think
it
seems
like
there
are
kind
of
two
subcategories
of
the
mission
controller,
at
least
at
least
from
rising
right.
There
seems
to
be
one
where
it's
like
validating
the
actual
step
or
task
that's
being
run,
but
by
the
prominence
of
that
and
then
validating
the
artifacts,
which
it
seems
like
some
of
these
are
handled
by
by
the
things
that
run
within
the
steps,
and
then
the
prominence
of
the
step
itself
obviously
has
to
be
done
by
a
mission
controller.
C
C
One
is
validating
that
the
secure
software
factory
itself
like
running
inside
of
a
control
plane
that,
whatever
it
itself
is
being
you
know,
its
images
are
trusted
and
signed,
and
that
only
those
images
that
are
trusted
and
signed
are
being
run
and
then
separately
when
running
pipelines
ensuring
that
the
pipelines
that
we're
running
are
you
know
the
the
definitions
are
following
some
sort
of
policy
and
that
the
actual
builds
that
we're
running
are
also
only
running
things
that
we,
you
know
against
some
sort
of
policy.
B
Yeah,
so
for
the,
for
the
first
point
you
made
right
like
ensuring
our
pipelines
are
trusted
the
pipeline
that
are
running
so
there's
some
work.
We
are
doing
essentially
on
the
admission
controller
for
our
pipeline,
specifically
for
techno
at
the
moment
right
when
the
tecton
run
gets
triggered.
B
We
do
the
validations,
whether
the
specification,
the
images
that
you
are
using
the
task,
whether
those
are
signed,
and
then
we
are
allowing
the
admission
to
that
pipeline
run
and,
on
the
second
point,
that
the
dependency
that
you
are
pulling
like
base
images,
whether
those
are
signed
or
not.
I
think
it
applies
equally
to
all
the
third
party
dependencies
right.
I
mean
it
might
be
a
python
package
that
you
are
downloading.
How
do
you
ensure
that
it
is
trusted
right?
B
So
the
way
I
think
we
should
we
can
frame,
it
is
like
generate
an
s
bar
of
all
the
dependencies
and
check
every
dependency,
whether
it
is
coming
from
trusted,
source
and
base.
Image
is
essentially
one
part
of
it,
but
it
should
basically
be
generic
enough
to
say
all
any
dependencies
that
you're
bringing
in
you
should
be
verifying
it
for
whether
they're
coming
from
trusted
source.
I.
A
So
I
think
this
changes
with
the
idea
of
hermetic
builds
right,
so
I
think
the
it
seems
like
the
responsibility
is
kind
of
in
between
either
on
the
pipeline
itself.
If
we
are
assuming
the
pipeline
is
the
one
that's
sharpening
all
the
artifacts
around
versus
you
know.
If
the
task
itself
is
going
to
be
pulling
and
using
the
basic
match.
C
Yeah
also
one
thing
regarding
the
the
s-bomb
thing:
actually
that
I
think
opens
up
a
another
question.
This
is
like
just
purely
a
like.
You
know,
I'm
not
trying
to
lead
this
in
any
direction,
but
I've
struggled
to
find
a
lot
of
existing
s-bomb
tooling.
That
really
does
generate
the
full
list
of
things
that
I
would
sort
of
want
from
an
s-mom,
so
that
includes
stuff.
Like
I
want
my
source
right,
I
want
to
have
hashes
of
all
my
source
files.
C
I
want
to
have
my
dependencies
and
some
way
of
you
know
some
hash
reference
to
it,
whether
it
be
a
git
hash
reference
or
a
shot,
256
reference
to
the
package,
or
something
like
that.
So
there's
that
s-bomb
that
I
want.
I
want
an
s-bomb
of
my
build
environment
right,
so
you
know
some
and
like
and
an
s-bomb
of
like,
if
I'm
applying
it
to,
let's
say
a
runtime
container
after
the
fact
like
yes,
I
built
it
here.
C
I
took
that
layer
that
had
all
my
artifacts
and
I
plopped
it
on
a
runtime
container.
I
want
to
have
also
an
s
bomb
of
the
runtime
container
so
that
I
know
all
these
things
and
I
found
at
least
like
in
most
cases.
I
don't
know
if
there's
particular
languages
that
that
both
spdx
cyclone
dx
and
whatever
else
is
out
there
have
done
some
good
stuff
on,
but
I
haven't
really
found
a
lot
that
seemed
to
to
to
be
able
to
really
generate
most
of
that
stuff.
B
Yeah,
I
think,
for
all
the
dependencies
in
the
all
the
s-bomb
right
they
take
different
approach.
If
you
are
using
package,
you
identify
with
the
version
number
right.
If
it
is
the
image,
you
are
indirect,
with
the
tag
and
sha
of
the
image.
If
it
is
a
file,
then
I
think
the
hash
makes
sense.
So
the
identifier
keeps
changing
based
on
the
type
of
the
artifact.
C
Yeah,
so
in
that
particular
case,
that's
where
I
kind
of
I
think
that
that's
a
hill
I'd
fight
on
which
is
to
me,
I
think,
depending
on
the
package
manager,
depending
on
how
they
compiled
the
that
particular
package.
C
You
can
end
up
with
you
know:
oh
debian
compiled
it
with
these
parameters,
red
hat,
compiled
it
with
these
parameters,
and
you
look
at
the
two
of
them
and
you
go
and
you
say:
okay,
well,
you
know
the
debian
one
is
is:
has
this
vulnerability,
but
the
rpm
one
doesn't
there's
a
lot
of
areas
where
I
think
that
that
can
kind
of
get
messed
up
and
then
also
with
lots
of
things
anyway,
I'm
not
going
to
go
too
deep
there,
but
I
I
think
it's
something
that,
but
but
even
beyond
that,
I
think
the
thing
that
I'm
running
into
is
when
I
generate
s-bombs
with
spdx
tools
or
cycle
and
dx
tools,
I'm
often
not
getting
all
the
things
I
would
sort
of
want
from
them.
C
Like
my
list
of
source
files.
My
list
of
you
know
like
recursive
references
to
other
s-bombs.
That
kind
of
thing.
F
C
Well,
I
I
think
that
there's
it's
the
way
that-
and
this
is
maybe
just
some
lack
of
clarity
in
you
know
if
you
read
through
like
the
ntia
s-bomb
sort
of
spec,
they
kind
of
leave
a
lot
of
it
very,
very
open-ended
with
saying
only
a
couple
of
things
are
really
sort
of
required.
C
The
sorts
of
things
I'm
I'm
wondering
right
is.
I
want
to
know
what
were
the
inputs.
What
was
how
were
they
built
right
like
so
what
was
the
actual
build
context
and
then
what
were
the
outputs?
So
I
can
go
back
and
look
at
my
you
know
if
I
I'm
concerned
about
a
particular,
let's
say
package,
I
can
go
and
look
at
the
s-bomb
for
that
package
and
see.
Oh,
it
was
compiled
with
you
know
this
version
of
this
library,
so
it's
not
exposed
to
that
that
vulnerability.
I.
F
Follow
that
what
I'm
driving
at
is,
it
seems
to
me
most
s
bombs,
oriented
towards
asset
data.
I
don't
know
that
they're
the
right
place
for
process
data,
something
like
in
toto
or
in
toto,
is
more
oriented
towards
process
data
that
might
be
the
natural
place
for
it,
like
that.
They're,
complementary
data
that
that,
like
one's
a
different
differential
and
the
other
one's
the
integral,
but
I'm
I'm
not
sure
that
a
single
format
will
correctly
encompass
them.
I
can
think
of
a
single
database,
doing
it,
but
a
single
format,
I'm
not
sure.
C
So
yeah
I'll
just
off
offline
I'll,
send
you
a
link
of
sort
of
what
I
was
looking
at
sure.
A
Yeah,
so
I
I
think
it
seems
to
we're
talking
about
this
metadata
document,
section
right
kind
of
tender
today.
I
think
the
question
here
is
one:
does
this
fit
into
metadata
chains
or
two
does
this?
Is
this
kind
of
like
marginally
out
of
scope
and
whether
we
can
talk
about
it
and
not
dive
too
deep
into
it?.
A
Yeah,
so
so,
michael
I,
what
do
you
think
is
a
good
way
to
express
some
of
those
talks,
but
at
the
same
time,
do
you
think
that
this
is?
It
sounds
like
it's
a
problem
that
isn't
fully
solved
today.
C
Yeah
that
I
I'm
gonna
defer
to
to
some
of
the
other
folks
on
that.
I'm
still
relatively
new
to
the
s-bomb
sort
of
world.
C
So
I
yeah,
my
only
concern
is
having
sort
of
poked
around
with
some
of
the
tooling.
I
found
that
some
of
the
tooling
isn't
capturing
some
of
the
libraries.
C
Some
of
the
tooling
is
in
capturing
some
of
the
packages
that
are
maybe
included,
and
you
know
I
just
want
to
sort
of
highlight
that
as
maybe
like
something
we,
we
maybe
want
to
say,
hey
look
generating
spam,
but
we
recognize
today
that
the
s-bomb
tooling
is
very
much
in
flux
and
maybe
isn't
purely
representative,
so
you
might
need
to
have
mitigating
controls
around
it
like.
That
might
be
something
that
you
might
want
to
say,
but
I
want
to
get
everybody
else's
thoughts.
E
So
I
agree
that
both
of
those
pieces
of
information
are
useful.
I
mean
I
sort
of
see
it
as
sort
of
states
and
state
transitions
right.
So
you
know
there's
the
supply
chain
is
effectively
a
set
of
states.
You
know
pieces
of
things
that
have
been
aggregated
together
and
handled
by
various
pieces
of
tooling
to
produce
other
things
that
are
then
consumed
by
other
things
and
turned
into
the
thing,
but
s-bomb,
I
think,
is
oriented
towards
the
set
of
states.
Sorry,
my
dog's
going
nuts.
E
A
If
not,
it
does
sound
like
it
does
sound
to
me
like
it's
important,
but
it's
pretty
hard.
E
Well,
I
mean
yeah,
I
think
yes
doing
doing
it
completely
and
exhaustively.
You
know
to
the
full
transit
of
effect
will
will
be
hard,
partly
because
you
will
quickly
reach
outside
of
the
domain
of
your
own
control,
and
so
we
will
need
to
like
bring
other
folks
into
the
fold
and
stuff
like
this
right
like
this.
This
touches
on
the
prevalence
of
open
source
dependencies
and
things,
and
you
know
what
not
right,
but
I
think
establishing
how
you
do
this
for
sort
of
individual
transitions
within
the
broader
state
graph.
E
E
So
I
don't
know
if
you
can
hear
me
he's
one.
No.
A
E
Know
I
think,
that's
part
of
how
we
solve
the
much
harder.
You
know
general
problem.
A
Sorry,
so
my
my
thoughts
on
so
it
sounds
like
this
is
something
that
we're
gonna,
say:
okay,
here's
a
recommendation
that
we
do
this.
A
We
don't
want
to
say
that
for
this
particular
reference
architecture,
it
sounds
like
we
don't
want
to
say
that
you
must
do
it
because
it
may
not
be
possible,
but
we
want
to
recommend
that
you
do
it
whenever
possible
and
that
in
today's,
in
today's
ecosystem,
from
what
from
what
I
think
in
the
chat
is
that
there
are
ways
that
we
can
do
this
and
there's
a
way
that
we
can
kind
of
show
this
within
the
reference
architecture.
A
Anything
nuts,
I'm
wondering
matt
and
michael.
Would
you
like
to
kind
of
add
this
section
in
or
just
talk
a
little
bit
about
it,
yeah
yeah
I'll.
C
I
I
will
update
that
a
little
later
today,
okay,.
A
Yeah
and
matt,
if
you
could
help
take
a
look
and
have
your
own
auditions
as
well.
That
would
be
awesome,
and
this
will
go.
Let
me
just
what
do
we
want
to
call
this
metadata.
B
A
A
C
A
Jackpots,
if
you
want
to
just
share
it
in
the
in
the
in
the
sec-
and
you
know
if
it's
something
that
folks
are
interested
in,
maybe
you
can
just
spend
some
time
next
time
just
talking
about
that.
So
if
it's,
if
it's
ready.
F
Yeah
I
mean
I've
been
sitting
on
it
for
several
months
on
a
draft
and
it's
one
of
those
things
where
I
work
so
hard
on
that,
but
I'm
afraid
to
read
it
in
case
I
hate
it
which
happens.
I
have
a
book,
I
wrote
and
I
I
I'm
terrified
of
reading
it.
A
All
right,
so
so,
coming
back
to
this
admission
controller,
I
I
think
we
we
we
have
to
do
kind
of
a
similar
exercise
with
what
we
did
with
s
bombs,
right
where
it
seems
like
we
have
three
different
things
to
take:
that
infrastructure,
pipeline
and
artifacts
that
we
want
to
say
are
related
to
emission
controller.
A
And
how
comfortable
are
we
to
say
the
animation
controller
is
going
to
fulfill
all
of
these
tasks.
G
C
Yeah,
the
I
think
the
mission
controller
can
do
most
of
it
and
what
it
can't
do.
What
we
can
probably
suggest
is
you
have
a
you:
have
the
emission
controller
validate
the
provenance
of
a
image
and
a
task
that
can
do
those
things
as
part
of
the
process
but
defer
to
admission
controller
where
you
can
so
as
an
example,
I
know
was
it
who
mentioned
this?
Oh
jason
had
mentioned
you
know,
kaneko
is
looking
to
you
know,
adopt
a
way
of
validating
the
signatures
of
parent
images
automatically.
C
So
it
can't
do
that
today,
but
one
of
the
things
I've
done
in
my
own
stuff
is
I've
been
able
to
go
in
and
say.
Well,
I
create
a
step
that
uses
uses
a
signed
image
that
validates
the
signature
and
then
passes
that
on
to
the
next
thing,
and
I
think
that
seems
like
a
reasonable
trade-off.
We
could
probably
make
that
when
and
where
the
emission
controller
can't
do
an
action
just
have
a
trusted
task
that
can
do
that
action
and
then
does
that
sound
reasonable
to
folks.
D
So
having
a
separate
having
a
separate
verify
thing
is
definitely
nice
for
its
universality
right
it
can.
You
don't
have
to
modify
conoco
and
a
dozen
other
tools
to
do
verification,
but
it
introduces
a
race
like
or
or
a
race,
maybe,
and
definitely
some
coordination-
some
some
need
to
make
the
two
things
work
together.
I
think
we
should
attack
in
both
directions
right
where
like
have
something
that
covers
every
case
and
try
to
get
that
built
into
these
tools.
So
you
don't
need
that
in
every
case,
you
might
end
up
verifying
twice.
D
If
you
have
the
cover
everything
verifier
and
the
kanako
verifier
or
the
you
know,
build
paddocks
or
docker
or
whatever,
but
that
way
you
know
who
does
it
hurt
to
verify
it
twice?
That's
not
so
bad
curious.
What
other
folks
think.
C
I
largely
I
largely
agree
with
that.
You
know,
if
possible,
you
want
to
include
it
in
the
right
sorts
of
tools,
like
the
more
the
admission
controller
can
do
with
a
lot
of
these
pieces
right,
the
the
more
you
can
kind
of
take
out
of
some
of
these
other
pieces
that
you
now
need
to
say
like
because,
as
an
example
of
the
kaneko
case,
like
hey,
I
have
a.
C
I
have
a
cosign
verifier
that
goes
in
verifies
the
parent
images
of
the
docker
file
and
says:
okay
cool
those
things
are
signed,
but
now
I
have
a
cat
now
I
have
that
image
and
that
task.
I
now
need
to
trust
and
that's
another
piece
that
could
potentially
go
wrong
compared
to
something
that's,
maybe
a
little
bit
more
well
suited
for
it
like
the
emission
controller
or
whatever
or
canaco
itself,
but
yeah.
E
It's
like,
okay,
this
this
step
in
the
build
pipeline,
may
end
up
executing
relatively
arbitrary
stuff
based
on
the
inputs,
and
so
you
want
it
to
have
sort
of
the
the
big
you
know
the
toughest
sandbox
in
terms
of
hermeticity
and
blah
blah
blah
blah
right,
but
you
you
invariably
may
need
to
do
things
that,
like
fetch
external
dependencies
that
aren't
necessarily
going
through
you
know
for
talking
about
the
context
of
kubernetes.
E
You
know
those
kinds
of
traditional
admission
control,
and
so
there
may
be
a
level
of
trust
in
those
things.
So
you
know,
for
instance,
here
would
be
if
I
were
executing
a
conoco
task.
I
may
want
to
do
that
hermetically,
because
that
may
be
executing
you
know.
Well,
it
has
the
potential
to
do
things
like
fetch
packages
over
the
network
and
do
other
forms
of
sort
of
arbitrary
code
execution,
but
it
needs
to
do
things
like
fetch
images
right.
E
So
maybe
the
conoco
warmer,
which
is
much
more
constrained,
can
execute
outside
of
the
hermetic
sandbox
it.
It
is
one
of
the
more
trusted
things
because
it
doesn't
do
arbitrary
code
execution
and
you
can
sort
of
reason
about
you
can
sort
of
partition
the
roles
and
responsibilities,
as
my
friend
feli
would
say
across
sort
of
more
trusted
things
and
less
trusted
things
and
the
less
trusted
things
run
in
stricter
under
stricter
controls.
E
You
know
to
do
some
of
the
more
arbitrary
code
execution
work.
Does
that
sort
of
make
sense.
C
Yep
yep,
no,
that
definitely-
and
I
think
that
falls
in
line
with
some
of
the
other
elements
of,
for
example,
the
build
itself
where
we
do
call
out
stuff
like
a
things
that
can
do
arbitrary,
builds,
really
need
to
be
monitored.
C
You
know
you
really
need
to
sort
of
limit
the
capabilities,
privileges,
etc,
that
it
has
to
purely
what
it
needs.
Compare
that
to
let's
say
something
like
a
linter
where
you're
like
okay.
Well,
I
know
the
linters
should
only
be
doing
these
sets
of
things.
We
can
easily
detect
that
they're
doing
something
that
is
outside
the
scope
of
that
thing.
Compared
to
you
know
a
build,
you
know
or
a
compilation
step
where
you're
like
you
know,
if
anybody's
ever
run,
ebpf
traces
against
a
build.
It's
like.
I
have
no
idea.
C
What's
going
on
in
there
like
there's,
like
all
sorts
of
file,
opens
and
writes,
and-
and
you
know
it's
writing
to
memory
here
and
yeah
yeah
like
that,
can
be
significantly
more
difficult.
So
I
I
totally
I'm
on
board
with
that,
and
you
know
I
think
we
call
out
a
couple
of
times
in
the
build
steps
like,
for
example,
if
your
build
does
not
need
to
write
anything
right.
C
It's
purely
reading
do
not
give
it
right
access
to
anything,
and
I
think
that
that
sort
of
thing
makes
sense-
and
I
think,
with
some
of
the
stuff
that
that's
kind
of
coming
down
the
pipe
with
you
know,
including
stuff
as
oci
objects
and
whatever
we'll
kind
of
get
a
better
get
a
better
understanding
of
some
of
those
things.
A
I
I
also
want
to
point
out
one
thing
where,
if
I
think
we
are
we
are
making,
we
were
talking
about
some
assumptions
of
the
things
that
are
running
inside
that
you
know
within
the
the
reference
frame
of
this
reference
architecture.
We
are
treating
those
as
inputs,
so
I
think
we
wanna
we
need
to
be
able
to
establish.
You
know
what
what
what
the
different
categories-
and
you
know,
put
more
more
into
defining
that
before.
I
think
we
create
this
complicated
relationship
with
the
policy
at
the
emission
control
side.
A
So
it
sounds
like
the
task.
Verification
I
think,
is
pretty
straightforward
for
mission
control.
The
infrastructure
itself
is
that
something
that
can
be
done
today
or
that's
kind
of
like
a
bottom
to
the
problem.
E
So
I
I
mean
there's
many
layers
right,
like
there's
verification
of
the
node
image
up
through
to
the
the
cluster
execution
layer
and
then
the
stuff
running
inside
those
things
right.
So
thinking
thinking
about
it
in
terms
of
sort
of
what
you
know,
techton
instructs
kubernetes
to
execute
tecton
doesn't
necessarily
do
anything
with
respect
to
verification
there.
E
But
since
it's
executing
things
in
terms
of
pods,
you
can
use
something
like
you
know,
cosine
signatures-
and
you
know
one
of
the
policy
enforcement
agents
like
okay,
gatekeeper,
the
caverno
stuff
or
even
the
cosign
web
hook
to
verify
that
the
images
going
into
that
pod
spec
are
verified,
so
that
would
that
would
basically
verify
the
tecton
sort
of
system
images
as
well
as
the
images
that
you
know
are
the
steps
that
execute
as
part
of
that
workflow
itself
yeah,
and
so
so
yeah
you,
you
could
do
it.
C
Yeah
yeah
yeah
that
I
yeah
I
I
validate.
I
validate
my
own
techton
images
against
to
ensure
that
they
are
signed
by
tecton.
A
So
so
it
sounds
like
it
sounds
like
you
know,
verifying
the
different
verifying
different
things
with
this
infrastructure,
the
the
tasks
itself
they're
running
and
then
the
artifacts
seem
like
logically
different
components.
A
C
Yeah,
so
I
think
those
are
two
separate
things.
I
think
that
they're
related
right,
you
could
use
the
admission
controller
to
do
in
most
cases
both
of
those
things
and
they
probably
don't
require
a
significantly
different
configuration
to
sort
of
do
that.
But
I
know
like
one
thing:
to
sort
of
keep
it.
One
of
the
reasons
why
to
keep
it
somewhat
different
is
a
lot
of
folks
are
going
to
keep
their.
C
Oh
so
some
of
the
stuff
is
like,
for
example,
what
was
I
gonna
say
blank
for
a
second
there.
Oh
the
reason
to
keep
it
conceptually
different
is
some
folks,
like
financial
services
are
often
thinking
like.
No,
no,
we
secure
you
know
our
secure
software
factory
is
going
to
be
its
own
control
plane.
It
is
not
going
to
have
anything
to
do
with
production,
and
so
we
are
going
to
have
a
separate
admission
controller
for
that
cluster.
C
A
Okay,
so
I
I'm
I'm
kind
of
setting
around
the
idea
of
should
we
split
this
component
into
two
different
components:
two
or
three
different
components
and
talk
about
it
separately.
E
Well,
and
and
sort
of
from
what
layer
up
right,
yeah
yeah,
exactly
like
I
said,
there's,
there's
sort
of
the
node
layer,
that's
there's
the
cluster
orchestration
layer
and
then
even
within
that
right,
like
tekton
tasks
can
go
out
and
fetch
dependencies
like
I
was
talking
about
with
you,
know,
conoco
and
whatnot
so
like
unless
you're
doing
things
for
medically
you
know
they
can,
they
can
go
out
and
fetch
sort
of
non-containery
things,
and
so
there's
also
a
form
of
admission
control
there.
So
you've
got
the
vm
image.
E
You've
got
container
images,
you've
got
you
know,
potentially
language
level
things
you
know
being
fetched
from
the
tasks
themselves,
so
it
would
be
good
to
scope
this.
A
A
Like
having
pipeline
verifier
or
pipeline
mission
control,
artifacts
verifiers
such
as
mission
control.
B
Yeah,
I
think
it
makes
sense
to
break
it
up
to
basically
different
scope,
so
each
animation
controller
we
can
discuss
in
a
different
scope.
Okay,.
G
B
G
Is
there
also
a
build
the
build
machine
or
control
plane
admission
controller
like
the
block
things
that
are
happening
there
and
then
also
the
runtime
admission
controller
right
like
so
meaning
if
something's
happening
at
runtime?
That's
I
don't
know
like
some
metadata
comes
in
and
somebody
drops
something
in
then
you
know
it
would
stop
it
as
well.
Am
I
overthinking
it
you
all.
A
E
Should
we
think
about
it,
I'm
wondering
I'm
sorry
if
this,
since
we
finally
got
names
out,
I'm
just
sort
of
marinating
on
this
right,
so
should
we
think
about
it
in
terms
of
the
actors
involved
in
being
like
regulated
right,
so
you
know,
I
talked
about
sort
of
arbitrary
developer
code
being
sort
of
sandboxed
a
particular
way
right.
So
how
do
we
sort
of
admission
control
those
things
and
then
there's
sort
of
you
know
the.
E
Sort
of
more
systems-y
thing,
but
not
like
the
the
root-level
systems-y
things
like
you,
know
the
tasks
that
are
running
as
part
of
the
build
pipeline,
which
you
know,
maybe
the
ops
folks
are.
You
know
configuring
particular
tasks
or
pipelines
for
execution
right
and
then
you
know,
there's
even
higher
level
bits.
You
know
around
like
what
you
were
consuming,
maybe
provided
by
a
cloud
vendor
or
something
like
that
and
the
guarantees
you
want
around
on
those
kinds
of
things
right.
E
A
Know
I
I
think
some
of
the
points
you
brought
up.
Initially,
we
were
initially
when
we
were
scoping
it.
We
were
like
okay,
you
know
we
just
won't
assume
anything
about.
What's
what's
given
to
us
to
run
we're
gonna
cover
that
in
a
separate
section
and
therefore
we
you
know,
we
came
up
with
these
these
caveats
here,
where
you
know
maybe
on
the
computer
and
boxing,
maybe
you're
under
providence,
for
the
task
themselves,
and
things
like
that.
A
So
I
think
I
think
that
goes
to
the
point
of
like
I
don't
think
within
the
reference
architecture
would
define
like
what
these
things
look
like
or
correct
me.
If
I'm
wrong,
I
feel
like
we
would
have
to
define
a
little
bit
more
about
the
things,
the
properties
of
the
the
inputs
being
because
we
take
the
task
as
a
input.
G
I
think
we
just
have
to
be
in
kind
of.
I
don't
want
to
use
the
term
violet,
but
veeam
vehement
agreement
on
what,
like
our
scope,
is
for
this,
because
we
can
literally
boil
the
ocean.
I
think
we
talk
about
this
pretty
much
every
week
on
what
we
need
to
do.
We
just
kind
of
have
a
line
in
the
sand
in
terms
of
what
we're
going
to
do
here
from
an
emission
controller
perspective
like
what
is
what
does
a
v1
look
like?
Is
it
like?
G
C
Yeah
I
mean,
I
think,
honestly,
each
of
those
things
is
probably
going
to
be
two
or
three
bullet
points
for
each
right,
and
you
know-
and
that's
it
right
like
at
this
point,
and
you
know
we
might
have
a
high
level
like
hey
your
mission.
Controller
should
be
looking
at
these
sorts
of
things
right
and
then
the
three
specific
ones
should
be
just
looking
at
the
you
know.
These
sorts
of
bullet
points
right,
you
know,
and
and
where
you
know,
the
emission
controller
can't
do
something
today.
C
Here
is
an
example
of
a
mitigating
control
around
that
and
you
know,
but
but
I
wouldn't
want
it
to
be
like
you
know,
because,
obviously,
if
we
get
deep
into
the
weeds
there
of
you
know
outside
of
stuff
like
check
for
signatures
and
check
for
these
sorts
of
things,
we
could
we
could
go
real
real,
deep
where
the
policy
is
like.
C
You
know
here
are
the
sorts
of
like
common,
build
parameters
that
are
maybe
suspicious
and
we
we
can
go
that
route
and
we'd,
be
here
till
the
end
of
time,
but
I
think
for
now,
yeah,
like
just
just
a
couple
of
high-level
sorts
of
things,
to
give
people.
G
And
then
also
if
a
tool
comes
out
down
the
line,
v2
of
this
somebody
can
go
ahead
and
add
as
much
data
as
possible.
That's
the
whole
point
of
this
is
just
to
put
a
line
in
the
sand,
so
folks
can
have
that
you
know
primary
reference
architecture
that
they
can
iterate
on
so
yeah.
I
kind
of
agree
on
the
bullets
there
and
also
the
overview.
A
Yeah,
I
I
I'm
tempted
to
say
that
that's,
let's
take
an
exercise
where
each
person
picks
one
put
everything
that
that
you
think
you
know,
basically
the
entire
kitchen
thing
and
then
we'll
come
together,
re-evaluate
and
determine
okay.
A
You
know
a
lot
of
things
which
are
good
to
mention
by
our
scope,
while
things
that
are
doable
within
the
reference
architecture,
but
I
think
we
there's
a
lot
of
good
information,
that's
going
around,
but
we
so
we
want
to
capture
that
and
these
have
it
whether
it's
gonna
end
up
being
part
of
the
v1
reference
architecture,
or
it
goes
into
like
the
caveats
here-
some
recommendations
that
are
not
necessarily
in
scope
of
of
the
reference
architecture.
I
think
we
should
at
least
capture
the
information.
A
Yeah,
I
know
I
I
think
I
agree
with
if
you're
mad,
it's
kind
of
like
overloaded
them.
A
A
Shall
we
who
wants
to
volunteer
for,
for
you,
can
take
more
than
one
I'm
not
starving,
I'm
not
stopping
anyone,
but
it
sounds
like
it
sounds
like
this
has
been
a
lot
of
discussion
and
people
opinionated
on
this
topic.
So
I
want
to
let
folks
put
in
all
the
content
that
they
want.
C
Yeah
and
then
also
once
again
feel
free
to
put
stuff.
We
can.
Maybe
even
you
know
this
is
where
maybe
I
don't
want
to
have
the
all
the
discussion
in
a
thread
inside
the
supply
chain
working
group,
but
even
just
like,
I'm
also
willing
to
kind
of
have
some
discussions
with
some
folks
other
highly
opinionated
folks
off.
You
know
outside
of
the
scope
of
this
meeting.
If
we
wanted
to
keep
going
because
I
just
you
know
yeah,
we
have
other
things.
E
Yeah,
I
I'm
I'm
happy
to
help
here.
I
guess
part
of
my
hesitation
is
I'm
sort
of
struggling
to
figure
out
how
I
would
articulate
this.
So
if
we
get
into
words,
he
was
like
a
leap,
but
I
guess
I
can
sign
up
and
and
deal
with
that
and
I'm
happy
to
chat
with
other
folks
if
they
want
to.
B
A
I
know
I
see
a
lot
of
chat
within
the
the
the
zoom
chat,
so
I'm
not
gonna.
Well,
I
can't
tag
anyone
so,
but
you
know
don't
hesitate
to
put
in
put
in
your
comments
here
and
what
your
thoughts
are.
A
Okay,
I
think
we
have
a
fairly
acceptable
action
item
for
ambition
controllers.
C
Yeah,
that's
a
that's
a
good
one.
That's.
C
Sorry,
michael
yeah,
the
the
I
think
I
I'm
down
to
have
also
another
conversation
with
all
the
folks
who
might
be
interested
in
that.
I
know
a
lot
of
folks
have
very
strong
opinions
on
a
lot
of
this,
but
I
know
one
of
our
unique
one
of
the
challenges
I
think
a
lot
of
us
are
running
into
is
the
challenge
of
like
okay.
We
have
a
metadata
chain.
C
C
There's
a
lot
of
big
questions
there
that
I
think
what
we'll
need
to
have
a
a
a
pretty
big
discussion
on
as
as
well
and-
and
we
might
to
to
go
to
you
know-
to
to
parrot
pop
a
lot
like
we,
we
might
have
to
you
know,
say:
hey
look.
This
is
the
the
generic
opinion
we're
keeping
right
now,
as
time
goes
on,
we
might
have
a
more
you
know
a
more.
We
might
be
more
opinionated
in
the
future,
but
this
is
what
we're
saying
right
now
right.
G
A
B
A
C
I
don't
want
to
volunt,
tell
anybody,
but
I
would
love
to
have
both
chains
and
in
toto
folks
put
put
their
opinions
in
there.
I
know
that
just
yesterday
you
know
internally
we
had
a
two-hour
discussion
about
this
very
problem
and
we
still
have
a
lot
of
open,
open
questions
about
it.
A
So
it
sounds
like
reach
out
to
marina
and
jason.
G
A
Cool-
it's
not,
I
think,
we're
out
of
time,
but
this
was
very
productive.
I
think
there's
a
lot
of
good
information,
and
you
know
we
all
learn
new
things
today,
so
cool
yeah,
so
next
week,
we'll
have
michael
will
do
a
quick
demo
on
the
the
reference
architecture.
A
Well,
an
implementation
of
an
architecture
that
he
sung
at
city
and
jack
was
sorry.
If
I'm
pronouncing
your
name
wrong
all
the
time.
Please
put
that
if
you
feel
comfortable
with
draft
and
the
channel,
if
not,
we
can
spend
maybe
by
10
minutes
next
time.
If
you
want
to
just
talk
through
talk
to
the
stuff
that
you've
been
writing.
F
And
if
you're
wondering
it's
jacques,
if
rhymes
with
shock
okay,
yeah.