►
From YouTube: Birds of a Feather: What Should a Container Build Manifest Look Like? - Nisha Kumar, VMware
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Birds of a Feather: What Should a Container Build Manifest Look Like? - Nisha Kumar, VMware
We create containers by reusing several pieces of software from disparate locations, internal and external to our organization. We then rely on the providers (trusted or not) of the pieces to publish the software component list, or we run vulnerability and compliance scan tools against the fully built containers before pushing it to an internal registry. These methods are more fail safes than applying software delivery best practices, i.e., start from a well defined Bill of Materials (BoM). Can we build a container from a well defined software component manifest? What would that manifest look like? This BoF is to discuss what we need in order to build a better container delivery pipeline that adheres to software delivery best practices. To kick us off, I will present a survey on currently used tools and practices. To Learn More: https://sched.co/GrSY
A
Hi,
my
name
is
Misha
I'm,
an
open
source
engineer
and
anywhere
I'm,
not
selling
anything.
Today,
I
just
want
to
have
a
conversation
about
build
Madison,
specifically
for
indie
nurse,
so
I've
been
in
I.
Think
the
DevOps
for
five
years
now
and
containers
and
docker
is
fairly
new
to
me.
I
started
off
with
dr.
by
building
using
it
to
me,
isolated
development
advanced,
and
this
is
when
I
came
across
a
two
of
the
reproducibility
for
government
in
us.
A
A
C
A
A
C
A
A
A
D
A
E
E
F
A
D
A
Right
now,
the
way
I
feel
that
the
container
builds
are
created
is
that
they
conflate
bill
reproducibility
and
updates.
It's
like
it
comes
all
in
one
when
in
fact
it
should
actually
be
divided
into
two
steps,
so
you
build
it
and
if
you
need
update
you
take
that
build
and
you
update
that
build,
and
then
you
keep
track
of
just
the
updates
from
the
base
build
and
the
problem,
with
the
way
that
we
have
our
container
build
ecosystem
right
now
is
that
there
is
no
accountability
on
the
base
build.
A
A
A
A
A
You
send
environments,
you
send
like
other
metadata
into
your
build
and
then
what
comes
out
is
another
collection
of
files
with
the
same
metadata,
maybe
some
extra
metadata
that
comes,
which
is
like
okay,
the
results
of
the
bill
so
and
it's
after
you
abstract
everything
out
like
that
for
that
unit
of
your
build,
and
then
you
can
start
thinking
about
dependencies.
Okay,
now
I
have
a
unit
of
build
that
has
all
of
these
requirements.
I
can
actually
plug
in
some
other
method
of
figuring
out.
What
my
dependencies
are
I
mean
this
is.
A
This
is
typically
how
package
management
works.
They
have
you,
you
start
from
the
unit
of
the
build,
and
then
you
have
a
tool
that
does
all
the
manipulation
to
give
you.
You
know
your
either
your
snapshot
manifest
of
the
build
or
your
your
sty
build
status
or
artifacts
that
you
will
ship
out
to
someone
else.
So,
okay,
I'm
done
talking
now.
A
E
E
A
Can
go
back
right,
so
the
the
idea
of
the
metadata
is
for
traceability
that
you
can
say:
okay,
I,
have
this
bundle
of
files
over
here
I
can
find
out
exactly
like
their
provenance
and
what
they
contain
and
what
was
the
status
when
they
finally
came
out
at
the
other
end,
so,
okay,
I
guess
we
can
move
on.
Let's
talk
about
tools,
sorry.
B
A
E
A
A
I
tend
to
think
that
it
might
fall
under
just
bill
logs
if,
if
there
was
a
build
failure,
I
think
what
we're
trying
to
end
up
in
the
other
end
is
just
after
everything
is
done
and
you've
distributed
it.
What
is
all
the
information
that
some
other
person
who
gets
their
hands
on?
It
will
be
able
to
find
out
about
this.
So
maybe,
like
you,
know
the
build
number
or
the
build
date
that
that
could
be
a
like,
an
additional
metadata
that
you
can
add
at
the
back.
A
C
So
I
was
just
gonna,
say
sorry.
Can
what
it
may
be
helpful
to
enumerate
what
pieces
of
metadata
that
we're
talking
about?
I,
think
I.
Think
kind
of
the
goal
that
we're
going
for
is
how
to
establish
trust
here
right
so
I
think
there
are
certain
pieces
of
metadata,
maybe
some
sort
of
cryptographic.
You
know
an
identity
of
what
is
this
binary
and
just
to
help
us
enumerate
the
trust
in
the
end
I'm
not
quite
sure
what
that
would
be.
How.
A
About
if
I
get
rid
of
just
metadata
for
outputs
and
put
that
in
its
own
thing
and
then
what
I've?
What
I've
heard
so
far,
is
that
there's
like
metadata
that
you
add
at
your
input
and
met
data
that
you
add
at
your
outputs
and
one
of
the
metadata
that
possibly
could
be
at
the
outputs?
It's
the
build
number
I,
don't
think
credentials
should
be
part
of
this
metadata.
That
seems
to
be
more
just
inputs
to
the
bill
that
that
doesn't
really
go
into
I.
A
G
I
know
the
credentials
shouldn't
like
any
secrets
shouldn't,
but
if
it
was
undoing
a
build
and
accessing
data
under
a
certain
authorization-
and
you
got
like
permission
denied
at
some
point-
you
didn't
know
why
that
could
affect
that
and
investigating
why
I
built
you
know
the
outputs
of
a
build
but
had
accesses
access
to
a
certain
package
and
not
another
package?
Oh
well,
the
token
it
was
given
didn't
have
access
to
that
repo.
It.
A
F
F
F
We
pretty
much
did
this
exercise
and
we
ended
up
with
four
groups
that
are
not
as
overloaded
in
other,
like
as
all
of
the
computing
terminology
that
we
have
and
it's
pretty
much
materials,
which
is
what
what
comes
in.
We
have
a
product
which
is
what
comes
out.
Then
you
have
an
environment
which
is
where
did
it
happen,
and
then
you
finally
have
a
by-product
which
is,
for
example,
a.
C
F
F
A
No
I
I
understand
that
there's
a
there's
something
called
pre-production
and
then
there's
something
called
production
and
definitely
like
the
byproduct
seemed
to
be
something
that
falls
under
pre-production.
You
can
inspect
it
and
see
if
everything
is
kosher.
Yeah,
okay,
I've
spent
a
good
bit
of
time
on
this
I'll
move
on
to
tools
that
I
found
that
meet
or
come
close
and
I'm
hoping
to
get
input.
If
there
are
other
tools
here,
I
did
so
I
did
start
off
with
docker,
because
that's
the
most
ubiquitous
two
out
there.
A
B
B
A
It's
if
you
can,
if
you
can
pull
a
container
image
using
the
digest,
I,
don't
know
if
bill
kid.
Does
that
or
not
so.
This
is
just
something
that
I
I've
noticed
and
it
may
be
wrong.
So
if
you
can,
if
you
can
pull
from
a
digest
using
Bill
kit,
then
maybe
that's
fine.
Is
there
a
way
to
make
to
account
for
the
base
image
that
you
pull
from
the
digest?
How
how
do
they
do
that.
G
No
most
most
of
its
parts,
part
of
the
registry
API
or
now
they
OC
ID
distributions
back,
but
still
that
when
you're
fetching
it,
if
you
fetch
it
just
by
name,
it
implies
latest.
If
you
fetch
it
by
name
tag
you
get
whatever
last
was
pushed,
which
is
what
you're
referring
to
and
then
within
a
scope
of
a
name
and
no
tag.
You
can
reference,
the
sha-256
digestive,
that's
exactly
the
same
thing.
G
A
G
A
D
Me
that's
not
necessarily
true
to
say
so
when
you're
building
up
your
layers,
so
you've
got
multiple
steps
in
your
dock,
a
file
or
you
look
at
the
original,
manifest
from
same
Alpine
or,
let's
just
a
chorus
or
any
other
group,
that's
building
on
top
of
base
images
every
time
they
go
and
build
it.
So
all
their
dependencies
and
all
the
absolute
light
here
in
the
arm.
D
After
two
packages
they
building
up
in
their
space
or
the
alpine
space,
each
layer
will
have
a
256
digest,
so
you
can
pull
each
layer
as
it
was
actually
being
built.
The
context
is,
if
I
run
it
a
week
from
now
and
there's
been
an
update
to
a
dependency
package
that
I
was
using,
say,
pythons
released
a
new
version
or
update,
it
will
have
a
different
shop
and
again
you've
got
the
full
collision
space
or
the
integrity
of
shop.
So
the
idea
of
I
ran
it
a
week
later
and
it
generated
the
same
shot.
D
A
So
what
what
I
am
so?
What
I
am
what
I'm
trying
to
do
like
the
whole
exercise,
where
we
step
back
and
talked
about
the
unit
of
a
build,
the
issue
with
pulling
down
the
whole
container
image
or
building
on
top
of
a
container
image
for
which
you
just
known
the
digest
of
that
container
image
is
that
that
unit
is
lost
so
now
the
way
that
you're
referencing,
that
artifact
is
we
are
one
digest,
but
what's
inside
the
artifact
is
a
whole
host
of
packages
for
which
you
don't
have
any
of
that.
Other
metadata
can.
A
F
So,
even
if
you
want
to
build
the
day
the
same
Debian
image
you
will
not
get,
you
will
not
get
the
same
packages
out
for
certain
packages
that
are
not
reproducible
and
that's
a
that's
a
problem
when
you
want
to
guarantee
auditability
properties
or
bit-by-bit
for
disability
of
on
your
base
italian
image,
for
example,
you
don't
know
the
statistics
for
other
Debian
distribution,
further
Linux
distributions,
but
there
this
can
happen
and
sorry,
it's
yeah
I
mean
I.
Don't.
A
Yeah
so
I
mean
right.
The
the
issue
here
is
right
up
to
the
base
OS
image
layer.
It
is
a
difficult
problem
and
what
you're
doing
is
basically
saying:
okay,
I
trust
the
provider
of
this
operating
system.
Do
give
me
all
of
this
metadata,
the
information
that
we
hadn't
listed
before,
and
so,
if
we,
the
the
whole
idea
of
trust,
is
that
you
know
you're
taking
care
of
me.
I
don't
have
to
ask
you
any
questions.
I,
don't
have
to
query
your
packages.
I
I,
just
know
it's
good
it.
B
Oh
yeah
I
was
just
gonna
jumping
off
this
conversation,
so
like
like
right
now,
the
granularity
of
the
digest
is
at
the
layer
level,
the
next
step
to
make
it
more
reproducible,
or
at
least
but
do
better,
diffs
and
and
in
more
in
better
better
cache
ability
would
be
to
actually
make
it
a
perfect,
and
that
will
give
you
kind
of
what
you're
talking
about
now.
You
can
take
an
RPM
and
you
can
unpack
that
and
you
can
digest
each
file
in
that
and
then
verify
it
against
what
the
contents
of
the
container
image
yeah.
A
G
So,
and
on
that
point,
so
tar
archives
have
been
great
and
terrible.
But
there's
already
some
discussion
going
on
within
the
OCR
community
of
a
potential
v2
image
format
that
would
flatten
out
and
not
do
per
tar
archive
so
that
you
could
have
not
only
better
deduplication
on
the
registry
and
on
disk.
But
you
could
see
like
per
file
diffs
easier,
like
more
self-expressing
and
more
cashable
per
file,
even
per
child.
H
Right
now
go
quick,
two
things
I
wanted
to
mention
one
thing
for
some
of
the
like
base
image
issues.
One
of
the
things
that
Google
has
been
working
on
is
the
this
notion
of
disservice
images
which
are
basically
scratch
with
just
standard
libraries
and
they
work
for
certain
languages.
And
then
you
come
with
the
packages
you
need
to
install
and
you
need
to
figure
out
how
to
get
those.
H
So
there's
the
issue
of
how
to
build
packages
or
install
them
in
a
reproducible
way,
but
that's
one
thing
I'm,
then
a
tool
that
I
think
is
missing
from
here
that
is
kind
of
coming
is
basil,
which
has
rules
to
be
able
to
build
doctor
images
in
a
reproducible
way
without
in
a
declarative
way
as
well,
and
so
there's
certainly
some
things
missing
from
that.
It's
still,
you
know
being
worked
on
still
being
improved,
I
think
that's.
Another
tool
might
be
worth
putting
on
this
table.
A
Linux
kid
all
of
these
address
some
of
the
issues,
just
not
all
of
the
issues
and
I'm
just
trying
to
figure
out
whether,
like
there's
any
like
movement
forward
to
address
all
of
the
issues.
I
just
have
one
one
more
question
to
ask:
has
so
inhabited
there's
a
thing
called
a
heart
file
and
that's
basically
a
tarball
with
metadata
attached,
specifically
the
checksum
of
the
tarball.
A
That
seems
that
seems
interesting
to
me
because
it
actually
does
take
that
unit
of
the
bill
and
attaches
the
metadata
to
that,
and
so
when
you're
distributing
it,
the
metadata
goes
along
with
that
bill
unit.
So,
even
in
like
a
container
space
that
still
seems
to
be
something
that
you
can
query
because
it
comes
with
the
tarball.
So
I
don't
know
what
your
thoughts
are
on
that
so.
I
What
one
other
thing
I
wanted
to
comment
on
is
one
of
things
worth
spreading
with
right
now,
and
everybody
should
be
is
GPL
license
requires
the
source
of
the
builds
to
be
revealed
and
there's
nothing
in
the
metadata
that
tells
you
where
these
things
were
created
from.
If
they
came
from
something
other,
then
you.