►
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
Tutorial: Building Security into Kubernetes Deployment Pipelines – Andrew Martin & Pi Unnerup, ControlPlane; Michael Hough & Liam White, IBM (Limited Seating Available - See Description for Details)
How secure is your deployment pipeline? Is image integrity verified or can any user deploy any image to production? Are those images scanned for known CVEs? And are security policies enforced to harden the cluster at runtime?This tutorial covers current best practices for enhanced Kubernetes cluster security. It is led by core contributors and subject matter experts, and provides hands-on experience with Notary, admission controllers, and vulnerability scanning.It teaches integrating image signing and vulnerability scanning into a pipeline through live examples, and demonstrates how to configure Kubernetes to enforce security policies and image integrity.Attendees should expect to learn how to utilise state-of-the-art CNCF and OS tooling, and frustrate potential attackers throughout the deployment lifecycle.Requirements: internet-capable laptop, a local Minikube installation.
To Learn More: https://sched.co/Gra6
A
B
There's
my
twitter
handle
and
tweet
March,
but
everyone
puts
their
Twitter
up
so
they
go
so
my
marketing
guys,
unfortunately,
have
said
that
I
have
to
do
a
little
plug
for
IBM
cloud.
There
you
go
people
like
us.
Apparently,
we've
got
a
booth
in
the
sponsor
showcase.
D6,
give
it
a
try:
we've
got
loads
of
free
stuff.
You
can
have
a
go
if
you
listen
to
one
of
our
talks,
so
yeah.
D
A
And
hello:
I
am
Andrew
Martin,
also
infrastructure
and
security,
engineering
at
control,
plane
and
yeah.
Let's,
let's
get
into
the
background
of
these
slides,
so
pre-flight
checks,
I
hope.
Everybody
has
now
had
an
opportunity
to
do
this.
Anybody
who's
just
arrived.
You
just
need
that
URL
everything
else
is
specified
in
that
repository.
A
A
We
want
to
stop
this
guy
from
getting
our
Bitcoin
or
cat
pictures
or
social
security
numbers,
and
we
have
to
do
these
things,
of
course,
with
automation
so
for
an
enterprise
that
is
attempting
to
do
this
at
the
highest
level
of
complexity
with
multiple
environments.
Here
is
a
view
of
secure
cloud
native
delivery.
This
is
even
oversimplified
and
neglects
the
use
of
environments,
but
we
can
importantly
see
the
various
stages
of
a
build
pipeline.
A
We'll
publish
these
slides
afterwards
as
well,
so
of
course
dependencies
building
the
scanning
of
the
image
and
gathering
of
metadata
about
it
and
we're
able
to
use
the
fact
that
containers
in
terms
of
the
file
system
are
immutable.
We
have
a
char
of
an
image
that
reflects
the
contents
of
this
file
system
and
that
is
a
content
addressable
immutable
hash.
A
We
can
talk
more
about
this
afterwards,
but
we
will
be
doing
something
a
little
bit
more
simplistic,
so
for
a
secure
software,
development,
lifecycle
or
container
delivery
lifecycle.
In
this
case,
we
kind
of
build
from
a
fairly
predictable
set
of
things.
We
start
with
the
base
image,
which
is
our
from
line
in
a
doc
file.
This
is
the
image
that
we
build
our
container
on
top
of
it,
maybe
from
scratch,
which
is
essentially
null
and
void,
there's
nothing
in
there
or
it
may
be
a
full-blown
sort
of
Windows
VM
where
the
kitchen
sink
is
included.
A
Of
course,
best
practice
is
to
ship
minimal
dependencies
in
containers
because
it
minimizes
our
attack
surface.
On
top
of
that
base
image,
we
ship
our
application
code.
This
is
probably
done
with
a
copy
from
the
host
file
system,
where
the
git
repo
containing
the
docks
and
checked
out
it's
what
comes
out
of
the
software
development
process,
then
we
perform
the
build.
This
is
the
dockerfile
work
itself.
This
builds
a
container
image
from
our
code
and
the
various
packages
and
dependencies
that
are
required
to
run
it.
A
We
then
have
the
application
image.
This
is
our
docker
image.
This
is
what
we
might
be
tagging
and
labeling
in
a
different
way.
Ultimately,
those
tags
and
labels
are
not
a
safe
thing
to
rely
on.
They
are
just
a
pointer
to
a
content,
addressable
hash
and
in
the
same
way,
that
there
have
been
attacks
on
gits
image,
signing
from
some
of
our
respected
friends.
In
the
room
who
reported
those,
there
are
also
theoretical
and
provable
attacks
on
container
tag
usage.
A
What
we
will
get
to
in
this
tutorial
is
using
tools
to
detect
and
prevent
these
attacks
and
then,
finally,
once
we
have
that
immutable
application
image
addressable
by
hash,
we
can
deploy
it
now.
It's
all
very
well
placing
these
controls
into
the
build
pipeline,
but
if
we
then
permit
any
image
to
be
deployed
to
our
production
systems,
well,
what's
the
point
in
doing
all
this
other
work.
So
what
we'll
do
today
is
will
tie
back
all
this
work
that
we
do
in
the
pipeline.
A
It
should
be
noted
that,
in
order
to
really
secure
this
process,
one
should
be
GPG
signing
each
of
their
git
commits
to
link
some
form
of
identity
to
the
whole
process,
because
everything
is
as
code
but
for
the
sake
of
ease.
We
have
omitted
that
mandatory
step
today
and,
of
course,
Darth
Vader
recommends
that
all
these
parts
are
put
into
a
pipeline.
There's
lots
of
continuous
integration,
tooling
that
we
can
use
these
days
from
something
as
simple
as
Travis
when
hosted
or
something
as
wide
and
varied
in
use
case
and
secure
ability
as
Jenkins.
A
But
again
in
the
interest
of
keeping
this
tutorial
within
usable
timeframe.
We
are
not
going
to
mount
any
of
this
stuff
and
run
it
automatically
will
give
you
the
tooling
and
the
workflow
to
run
locally.
But
of
course,
automation
is
just
wrapping
that
up
in
a
bash
script,
so
the
pipeline
I,
don't
think
you
need
convincing.
Is
the
ideal
place
to
run
these
security
checks
and
controls
because
we
are
doing
so
automatically?
A
Pipelines
are
the
fundamental
building
block
of
robust
fault,
tolerant
and
secure
systems,
because
they
provide
a
repeatable
environment
in
which
we
can
assert
expectations
about
the
state
of
the
software
that
we're
building
the
minimum
viable
pipeline
security
for
a
container
image
should
be
the
knowledge
of
any
CVS
in
the
image
or
application
libraries
and
their
acceptance,
or
blocking
the
images
based
upon
the
risk
that
they
present
can't
believe.
At
this
point
enough,
shipping
CVS
to
production
is
the
easiest
way
to
get
pwned,
because
all
of
the
drive-by
script,
kiddie
tooling,
is
based
on
published
CVS.
A
We
have
this
new
opportunity
with
containers
to
be
able
to
perform
not
only
microwave
mminton
around
a
single
process
in
the
container,
but
also
to
have
a
full
manifest
of
everything.
That's
packaged
with
the
container
as
we'll
go
through
today,
and
there
really
is
no
excuse.
It's
a
lot
easier
to
be
secure,
so
I
hope
by
the
end
of
the
day.
You
are
convinced
that
it
is
simplistic
enough
to
introduce
into
your
own
pipelines
so
once
the
risk
of
shipping
certain
configurations,
it
may
be
that
a
CVE
is
acceptable
to
you.
A
If
it's
something
that's
in
no
way
exploitable
in
the
container,
for
example,
so
once
we
accept
that
risk,
we
want
to
ensure
that
the
shipped
build
image
is
exactly
the
same
one
that
we
deploy
to
production
and
one
such
tool
that
supports
that
pattern
is
notary,
so
we
will
use
notary
as
the
basis
of
a
secure
pipeline.
In
fact,
the
author
of
the
tough
spec
the
notary
was
based
on
was
briefly
with
us,
but
sadly
he's
had
to
ghost
right.
So
these
are
tools
that
you
can
use
at
various
stages
of
the
build
pipeline.
A
I'm
sure
you
recognize
some
of
them
today
we
will
be
using
these,
so
we
need
a
docker
registry
or
hope
to
pull
from
notary
is
the
way
to
overlay
GPG
cryptographic
signing
against
image.
Shaw's
tough
for
the
update
framework
is
the
specification
that's
based
on
their
both
CN
CF
projects.
Then
we
have
this.
As
I
mentioned,
attaching
build
metadata
to
the
image.
Is
an
emerging
field?
There's
two
main
tools
in
this
category
in
toto
and
go
face
again.
We
will
not
be
covering
them
today,
but
I
would
advise
you
to
keep
an
eye
on
them.
A
Application
image
scanning
Clair
is
bundled
into
harbor.
Harbor
is
again
a
CN
CF
project
from
VMware,
which
is
a
hosted
docker
registry
and
Claire
is
an
image
scanner
initially
developed
by
core
OS
that
pulls
in
those
CVE
feed
date.
Earth.
Sorry,
cv
e
data
feeds
and
performs
an
enumeration
of
the
installed
packages
and
checks,
those
versions
against
the
published
feed
and
then
finally,
we
have
poor,
tiaras
and
cube
Seck
admission
controllers.
A
Poor
TRS
means
that
when
we
get
to
deployment
time
would
check
the
notary
signing
of
the
image
that
we're
deploying
and
if,
if
it's
not
correctly
signed,
it's
either
downgraded
or
not
allowed
and
cube.
Seck
is
a
tool
very
similar
to
pod
security
policy,
but
with
more
granular
opinionated
security.
Profiling.
A
Here
is
the
flow
of
our
theoretical
pipeline.
We
will
build
an
image.
We
will
assert
that
it
has.
No
vulnerabilities
cryptographically
signed
the
image
because
we
now
trust
it
push
that
to
a
container
registry
attempt
to
deploy
it
to
our
cluster.
This
point:
Porteous
checks.
The
image
has
been
signed
at
a
mission
control
time
and
we
reject
images
that
do
not
follow
process
to
a
policy.
C
C
What
we
care
about
here
is
really
the
harbor
just
packages.
These
components,
you
will
probably
be
using
some
form
of
other
public,
hosted
registry,
we're
running
this
locally.
Just
so
we
can
have
a
simplified
path,
kind
of
and
repeatable
thing,
and
so
we
don't
have
to
distribute
cloud
credentials
to
all
of
you.
C
Basically,
so
if
using
ISO
IBM
container
registry
has
notary
as
part
of
this
and
vulnerability,
adviser
Quay
has
a
similar
thing
and
I
believe
ACR
does,
but
the
registry,
using
if
you
want
to
leverage
these
features,
should
have
at
least
image
digitally
digital
signing
of
image
digests,
which
is
what
notary
is.
You
obviously
need
the
registry
to
host
the
files
for
you,
and
then
you
need
to
have
some
kind
of
image
vulnerability
scanning
again.
This
is
often
just
bundled
in
as
part
of
your
registry,
like
that's,
usually
some
of
the
differentiators
they
offer.
C
D
You
really
want
to
make
sure
that
you
don't
have
any
known
vulnerabilities
in
these
images,
the
process
of
doing
that,
the
process
of
preventing
known
vulnerabilities
and
images,
whether
you're
doing
it
in
your
CI
CI
plan
or,
if
you're
doing
it
in
your
registry.
That
is
what
is
known
as
image
scanning.
D
This
is
what
I
think
of
when
I
visualize
pulling
straight
from
the
dogger
hub
and
into
communities.
We
have
to
scan
these
things,
otherwise
we're
just
going
to
be
shipping
images
with
our
CES,
with
known,
documented
vulnerabilities
straight
into
our
production
environment.
That
means
we're
just
basically
offering
the
attack
surface
on
a
plate
to
whoever
wants
it.
D
Let's
wait
until
we're
doing
the
workshop
together
and
then
we
can
go
over
questions,
so
I've
been
talking
about
known
vulnerabilities,
but
what
can
image
scanning
actually
detect?
What
are
some
concrete
examples
of
what
image
scanning
can
detect?
That
depends
on
the
tool
that
we
use
and
it
depends
on
the
depth
of
the
tool
that
we
use.
Some
tools
only
scan
OS
package
manager
versions
and
others
check
file
system
permissions
for
everything.
That
means
it.
Checks,
OS
package
manifests
application.
D
Library
package
manifests
bearing
in
mind
that
for
some
of
these
applications,
vulnerability
feed
is
not
free,
it's
paid
for
so
depending
on
what
scanner
you
use.
If
it's,
if
it's
purchased
it,
it
might
not
find
all
of
the
vulnerabilities
in
these
packages.
You
can
scan
compressed
formats
such
as
jaws,
Wallis
and
TAS
manually
installed.
Binaries
manually
installed
files
you
can
scan
for
malicious
code,
such
as
malware
root
kits
backdoors,
like
I
mentioned
you
can
scan
for
for
filesystem
properties
like,
for
example,
set
user,
ID
set
group,
ID
owners,
emissions
and,
of
course,
misconfigurations.
D
It
generally
almost
always
comes
from
very
similar
databases
from
the
same
cbss
database,
but
some
vendors
might
override
that,
depending
on
the
information
that
they
have
the
best
scanners
out.
There
are
the
ones
that
compare
multiple
sources
to
make
sure
that
we
don't
have
too
many
false
positives.
So.
D
Generally
speaking,
we
have
three
wildly
used
open
source
scanners.
We
have
Korres,
clear,
aqua,
Microscan,
ER
and
anko
open
source
engine
like
for
the
same
case
for
all
of
these
is
not
the
only
standalone
project
that
the
vendors
use,
they'll
usually
be
owned
by
companies
that
have
other
offerings
like,
for
example,
a
paid
scanner.
D
Let's
look
at
the
first
one,
Claire
Claire
works
by
creating
and
index
of
images
all
the
features
in
the
images,
and
then
it
queries
a
database
based
on
this.
Based
on
these
features
based
on
this
information
images
in
Clara
scanned
it
in
just
time,
and
what
do
I
mean
by
that?
It
means
that
when
you
have
new
vulnerabilities
updated
in
this
database
they're
compared
to
existing
image
scans,
we
don't
rescan
the
image.
Every
time
haba
did
we'll
be
using
today,
as
I
mentioned,
is
using
clear.
D
The
next
tool
is
a
quest
microscope
which
I'm
sure
a
lot
of
you
have
probably
already
heard
of,
or
you
might
even
have
gone
to
talk
about
it.
It
runs
quite
differently
from
Claire
the
hub.
The
Aqua
Microscan
are
works
by
scanning
at
runtime.
It
has
an
executable
in
the
docker
file
and
that
runs
when
you're
building
the
image.
That
means
that
you
get
the
additional
functionality
that
you
can
fail,
a
build
based
on
the
based
on
the
result
of
this
microscope.
D
So
if
you
want
to
run
it
in
Jenkins
or
in
any
CI
CD
pipeline,
this
is
a
useful
tool
to
know
about.
Lastly,
we
have
anchor,
which
is
quite
similar
to
Claire
it's
a
platform.
It
includes
the
database
of
vulnerable
information
for
the
images
as
a
separate
container
in
your
infrastructure,
so
it
runs
as
a
container.
It
creates
a
list
of
packages
that
you
can
search
include
software
artifacts
such
as,
for
example,
ruby,
gems
or
node.js
modules.
D
Now,
let's
move
on
to
the
first
part
of
the
tutorial
today,
here
we're
going
to
be
building
a
vulnerable
image,
trying
we're
going
to
deploy
it
to
the
harbor
registry
and
attempt
to
deploy
it
into
our
mini
cube
clusters
that
hopefully
most
people
should
have
somewhat
up
by
now
and
then
just
having
a
look
at
how
that
runs.
I'm
just
gonna
put
yeah
I
think
I'll
just
go
back
into
that
the
installation
slide.
D
D
You
can
definitely
ship
yeah.
The
question
is:
can
you
define
your
own
vulnerabilities
or
do
you
have
to
use
a
premade
database
I,
don't
know
of
anyone.
So
if
you
find
a
new
vulnerability,
you
mean
a
lot
of
these
tools
that
get
their
database
from
the
internet,
so
they
have
a
preset
database,
but
you
can
also,
which
is
what
we're
going
to
be
doing
today.
You
can.
D
So,
generally
speaking,
in
terms
of
the
databases
that
we
have
now,
the
vulnerability
databases
that
we
have
a
lot
of
them
are
patched
and
updated,
as
we
go
along
bitNami
in
particular,
is
particularly
good
at
not
shipping
vulnerabilities
in
their
systems.
But
if
you
scan
it's
good,
it's
just
good
practice
to
scan
every
image
in
your
registry,
your
local
registry,
wherever
you
keep
it
before
you
deploy
it
I,
don't
know
if
there
is
a
I.
C
A
The
so
the
state
of
the
art
with
these
sort
of
things
is
ultimately
everything.
Everything
for
the
docker
hub
is
just
absolutely
trusted
by
most
organizations.
If
you
look
at
what
docker
actually
do,
then
the
Alpine
core
maintainer
is
now
employed
by
docker
and
ultimately,
those
base
images
for
which
there
is
trust
we
have
to.
We
have
to
trust
those
absolutely
because
we're
putting
them
and
we're
running
them.
Docker
does
support
content,
trusts
and
docker
hub
some
of
these
things.
A
So
we
can
know
that
the
person
who's
originally
scan
those
images
and
signed
them
off
says
that
they're
good.
We
can
verify
that
they
haven't
been
intercepted
in
the
middle
and
then
to
the
question
of
like
the
nodejs
based
images.
Things
like
that
for
those
well-known
things
like
nodejs
and
and
the
JVM
just
running
the
Alpine
based
images
is
a
super
nice
way
of
doing
it
because
they
don't
ship
with
very
much,
of
course,
the
difference
between
Alpine
and
Ubuntu
or
Debian.
As
soon
as
you
install
Python
they're,
the
same
size
image.
A
So
there's
kind
of
that
there's
not
quite
the
obvious
dichotomy
that
maybe
there's
space
to
be,
but
with
all
these
things,
you're
still
adding
extra
things
into
the
repo
into
the
image.
So
you
have
probably
an
interpreter
like
bash.
For
example,
someone
gets
nasty,
they
can
use
bash
to
do
all
sorts
of
things.
You
you've
got
a
built-in
TCP
library
in
bash
that
you
can
use
via
the
command
line,
which
is
crazy
insane,
but
it's
like
reverse
jail
central.
A
So
there's
a
really
nice
set
of
images
from
Google
called
destroyers
the
ship
with
root
certificate
bundle
like
Etsy
local
time
and
completely
minimum
viable
operating
system.
Basically,
so
if
you
really
want
to
have
the
the
best
sort
of
blast,
radius,
production
and
compromise
resilience,
then
those
every
time
there
is
some
complexity
with
that,
because
you
need
different
debugging
patterns
because
you
can't
just
go
in
and
pop
shell,
so
you
need
to
attach
a
container
to
the
network,
namespace
etc,
but
generally,
depending
on
it's
like
a
risk
profile
question.
A
Yeah
so
yeah,
so
that
there's
a
whole
question
of
untrusted
third
party
code
risk
with
open
source
in
general
operating
systems.
Less
so
because,
like
you
say,
we
can
actually
pay
for
contractor
to
these
people,
but
but
actually
I,
maybe
depending
upon
the
financial
services.
Then
some
of
them
do
trust
the
docker
hub,
because.
A
Yes,
so,
ultimately,
the
the
same
support
that
you
get
from
having
Red
Hat
builds
and
package
and
own
whole
supply
chain.
You
have
the
same
thing
effectively
without
point,
but
I
have
no
horse
in
this
race.
We
don't
offer
support
or
any
of
these
things
and
certainly
building
from
scratch.
Image
then
requires
you
to
have
your
chain
of
custody
for
that
code
when
it
comes
into
organization.
So
it's
still
the
same
problem
just
far
different
mechanism.
A
B
B
B
I
say
that,
but
harbors
still
in
container
creating,
so
while
I
wait
for
that
to
start
we're
using
harbour,
basically
as
a
packaged
notary
and
container
registry
and
all
of
that
stuff,
the
yam.
All
that
we
actually
put
in
the
project
is
the
chart
that
is
normally
used
to
install
harbour
just
put
into
a
single
file.
B
B
Yes,
so
just
as
a
assurance,
these
instructions
are
going
to
stay
up
on
github,
so
anytime
after
this
session,
like
once,
you
get
back
to
your
hotel
rooms
and
things
like
that,
and
you
have
a
Wi-Fi.
That's
not
got
a
hundred
people
trying
to
download
mini
cube
on
it
and
yeah.
You
might
have
better
luck
if
you
have
any
trouble
and
so
I'm
on
booth
GC
at
the
IBM
booth
tomorrow.
B
C
B
C
B
We
would
normally
have,
at
this
point,
got
through
Claire
and
confirmed
that
an
image
doesn't
have
any
C
V's
in
it,
but
that
doesn't
necessarily
confirm
that
the
thing
that's
in
the
image
is
the
thing
that
we
actually
wanted
to
deploy.
So
that's
where
notary
comes
in
in
the
way
that
we're
setting
things
up
here
so
notary
lets
you
quick
to
graphically
sign
your
image
versions,
and
that
provides
a
way
to
assert
that
you're.
Okay,
with
an
image
digital
signatures,
can
be
confirmed
by
our
machines.
B
So
we
can
automate
that
process
and
make
that
part
of
your
pipeline
going
through
to
production,
notary
server
and
is
a
web
application
server
that
you
can
actually
access
as
part
of
your
pipeline.
So
you
can
look.
You
can
look
that
up
and
you
can
confirm
who
has
signed
an
image
as
part
of
your
and
deployment
process
and
yeah.
Multiple
people
can
sign
images,
so
we
can
do
stuff
like
having
I,
don't
know.
B
Someone
like
your
QA
team,
have
a
signing
key,
that
they
could
sign
the
image
so
that
they
can
approve
that
as
and
then
your
pipeline
can
confirm
that
the
image
was
signed
as
a
kind
of
way
of
approving
that
deployment,
or
we
can
just
confirm
that
a
public
image
came
from
the
right
publisher
by
checking
the
signing
key.
Most
of
the
like
major
base
images
like
Ubuntu,
and
things
like
that
on
docker
hub
are
signed
in
there
notary,
and
so
we
can
confirm
that
as
part
of
the
deployment.
B
So
if
we
look
at
a
untrusted
docker
fly,
you
would
normally
ask
your
registry
for
a
tag
like
latest
on
a
repository
like
Ubuntu.
The
dark
demon
will
then
go
away
and
ask
the
registry
what
version
or
what
digests
there
is
assigned
to
that
latest
tag.
A
digest
is
a
sha-256
hash
of
basically
the
image
content,
and
that
is
then
that
will
refer
to
what
layers
are
in
the
image.
What
was
created
at
the
time,
and
so
when
we
pull
the
image
we
ask
for
the
digest.
B
The
registry
identity
itself
is
proven
by
HTTPS
and
the
certificates
that
your
registry
provides,
but
the
identity
of
who
told
the
registry
that,
in
this
case,
1
2
3
4
5,
is
the
digest
that's
assigned
to
the
latest
tag.
We
don't
know
that,
so
anyone
could
have
done
that
or
anyone
with
access
to
your
container
registry
could
have
done
that.
B
B
Part
of
that
will
include
who
has
signed
different
versions
of
the
latest
tag,
and
if
bob
has
signed
the
latest
tag,
it
notary
will
store
the
most
recent
version
that
he
has
signed,
and
so
we
can
go
right.
I
trust,
Bob,
so
I'm
going
to
take
the
version
that
he
said
should
be
latest
and
I'm
just
going
to
ask
the
registry
for
that
digest.
So
we
don't
actually
go
to
the
registry
asking
what
version
it
is.
B
But
how
do
we
apply
notary
to
kubernetes?
So
in
Dockers
view
of
the
world,
you
would
enabled
our
content,
trust
and,
as
part
of
docker
content
trust.
It
will
then
go
and
get
the
signing
information
from
notary
as
part
of
your
starting
in
container
cubanelle
tears,
because
it
supports
various
different
container
runtimes.
It
does
a
little
bit
more.
It
takes
a
little
bit
more
than
just
flipping
content
trust
on
in
order
to
get
to
work
so.
B
We
use
a
admission
controller
animation
controllers,
a
piece
of
code
that
intercepts
a
request
to
the
kubernetes
api
server
and
tell
it
to
create
something
after
the
request
gets
authenticated
and
authorized.
But
in
short,
you
have
two
different
options
for
where
you
can
plug
an
omission
controller
into
the
flow.
There
are
two
types:
there's
a
mutating
web
hook
which
will
allow
you
to
change
something
in
the
deployment
before
you
then
pass
that
through
before.
It
then
goes
on
to
the
couplets
or
a
validating
admission
web
hook,
which
is
a
hard
stop
of
yes
or
no.
C
C
So
the
reason
you
need
something
like
40
RS
is
you:
can
your
Dhaka
demons
view
of
a
world
in
a
kubernetes
cluster
includes
the
couplet
and
everything
that's
kubernetes
itself
right
now
in
some
cloud
platforms,
that's
completely
abstract
it
away
from
you.
You
can't
run
docker
PS
on
the
machine
or,
if
you
turn
it
on
and
you
then
try
and
deploy,
or
your
cloud
provider
updates
the
Kubla
image.
Then,
basically,
what
will
happen
is
you'll
be
blocking
if
they
don't
cryptographically
signed
their
images
using
no
tree.
You
will
basically
break
your
cloud
deployment.
C
Your
kubernetes
deployment
right
because
they'll
try
and
deploy
a
new
version
of
the
Kubler
and
you'll
and
dokgo
the
docker
daemon
running.
Will
just
registry
out
reject
it
and
the
other
disadvantage
of
basic
docker
trust?
Is
that
there's
no
trust
pinning
involved
so
docker
content?
Trust
just
asserts
that
someone
has
signed
the
image,
not
that
this
person
has
signed
the
image.
So
that's
not
entirely
secure
right,
because
anyone
could
anyone
with
access
to
your
registry
at
that
point
can
sign
it
with
their
own
key
push
it
up
and
act
that
then
can
be
deployed.
C
So
that's
where
mutates.
Commission
controller
comes
in
right,
so
when
we
go
through
the
flow
that
we
saw
before
portiere
is
when
you
create
a
resource
in
coop,
so
deployment
pod,
whatever
anything
that
involves
an
image
being
deployed
into
your
cluster
40
eros
will
actually
talk
to
node
tree
and
it
uses
known
as
your
client
to
reach
out
to
no
tree
and
say
can
I
have
all
of
the
trust
data.
For
the
thing
that's
for
everything
in
this
repo
place.
It
then
finds
the
most
recent
image.
C
C
There's
someone
someone
can't
come
along
and
modify
the
image,
that's
order
where
the
tag
is
pointed
to
and
then
just
delete
your
pod
and
then,
if
your
image,
poor
policy
as
always,
then
it
will
just
pull
in
the
thing
that
the
image
that
the
attacker
has
managed
to
put
in
your
registry,
so
the
flow
looks
like
this.
I
can't
see
the.
C
Will
have
to
bear
with
me,
so
you
create
a
resource
by
talking
to
the
cube
API
server.
The
cube
API
server
then
sends
a
request
to
port
eros
or
port
Sierra's
registers
itself
as
a
mutating
emission
web
hook.
So
it
says:
okay
Cooper
has
ever
whenever
someone's
trying
to
deploy
I
think
we'd
better,
but
specify
basically
everything
whenever
anyone's
trying
to
deploy
anything
with
an
image
name.
Ask
me
if
it's
okay
or
ask
me
why
I
should
actually
be
deploying
or
what
you
should
actually
be
deploying
sorry,
porty
Eris
then
reaches
out
to
no.3.
C
It
pulls
in
the
information
as
I
mentioned
previously
and
will
then
mutate.
The
requests
and
I'll
show
you
exactly
what
that
looks
like
a
bit
in
a
second,
but
it
will
then
send
that
stuff
back
to
the
coop
API
server
and
then
that's
persisted
in
SCD
and
so
on
and
then
gets
deployed
of
course,
so
you
would
normally
deploy
a
coupie
animal.
That
looks
something
like
this
right
with
attack.
So
this
is
the
latest
version
of
porty,
Eris,
porty
Eris
will
say:
no
you
need
to
deploy
this
right,
and
this
is
pointing
this
is.
C
The
key
part
is
pointing
out
a
specific
digest
so
because
we've
gone
ahead
and
we've
verified
that
you
well,
we
can.
We
can
declare
that
or
we
can
define
some
CR
DS.
That
say
any
images
need
to
be
first
assigned
by
this
set
of
public
keys.
We
can
then
take.
We
can
then
take
the
information
that
no
tree
gives
us
verify
that
it
works,
find
do
that
last
digest
of
the
last
thing
that
was
signed
that
meets
our
requirements,
and
then
we
send
that
back
to
cube
API
server.
C
So
this
would
be
the
section
where
you
get
this
stuff
done,
but
you
should
do
this
all
in
your
own
time,
because
the
internet
is
just
not
going
to
work
here.
We
will
attach
the
slides
to
this
with
instructure,
but
the
instruction
should
be
able
to
get
you
through
most
of
stuff
I'm
gonna
hand
over
to.
D
Cool
so
scanning
phone
abilities
signing
all
that
is
super
important
to
know
that
your
image
is
secure,
but
that
is
mostly
relevant
if
you
know
that
that
is
the
exact
image
that
is
actually
deployed
into
production
with
no
alterations
whatsoever,
and
you
can't
always
know
that
in
runtime.
Sometimes
you
need
to
be
able
to
continuously
scan
and
check
that
what
you
have
in
your
deployment
is
actually
what
you
think
you
have
in
your
deployment.
D
D
D
This
is
what
the
you
eye
looks
like
for
cube,
SE
cayó.
We
have
a
bunch
of
factors
that
go
into
determining
the
score
of
this
image,
such
as,
for
example,
resource
requests,
limits
that
prevents
resource
exhaustion.
We
have
security
context
like
capabilities
privileges,
so
that
we
don't
have
a
pot
that
have
unrestricted
access
to
the
host,
and
then
we
have
scores
that
limit
visibility
of
the
hosts
like,
for
example,
PID
or
other
namespaces.
That
means
that
we're
not
going
to
be
leaking
information
from
the
hosts
onto
a
potential
attacker
like,
for
example,
environment
variables.
D
All
of
these
factors,
a
droite
code,
is
what
goes
into
determining
the
score
of
an
image
and
based
on
that,
you
can't
just
decide
whether
or
not
you
want
to
deploy
it
here.
We
see
an
example
of
an
insecure
image.
We
can
see,
for
example,
that
it's
it's
privileged.
It
has
almost
unrestricted
host
access.
That
is
pretty
much
route,
you're
you're
handing
out
keys
to
the
kingdom
at
this
point,
and
then
we
have
some
mitigation
suggestions.
D
In
this
case
we
can
see
that
the
user,
it
matters
so
make
sure
the
user
is
non-root
and
then
set
some
limiting
like
some
container
limits
later
down.
So
at
this
point
we
would
normally
be
going
through
the
section
zero
four,
which
sets
more
admission
control
and
goes
through
the
cube,
Seck
section.
However
I'm
guessing
most
of
you
won't
be
able
to
do
that.
D
But
if
you
go
to
this
website
cube
Seck
dot
IO,
there
will
be
a
very
similar
tutorial
that
you
can
do
there
at
this
point
and
then
maybe
when
you
get
home,
you
can
have
a
look
or
later
later
tonight.
You
can
have
a
look
at
the
OL
for
section.
But
if
you
head
over
to
cube
Seck
that
IO,
you
should
be
able
to
go
through
that
in
the
next
five
or
so
minutes.
A
A
So
the
question
is:
how
is
non-repudiation
provided
by
cube?
Seck
IO
keepsake
is
outside
of
the
notary
importance
world.
So
if
that
question
is
for
for
notary,
then
it's
basically
based
on
GPG
keys,
so
so
that
the
notary,
important
thing
is
all
about
signing
images,
and
it
is
also
based
on
delegated
keys
and
key
hierarchy
so
similar
to
the
way
that
we
would
have
a
root
certificate
for
semantics,
which
is
obviously
now
invalid
and
then
an
intermediate
certificate
for
for
their
signing,
Authority
and
then
finally
leaf
certificate
for
a
webpage.
A
The
same
model
essentially
is
used
by
by
notary,
so
that
roots
key
should
be
offline,
should
never
be
compromised
a
bull
if
the
intermediary,
if
the
intermediate
intermediate
key
I'm,
sorry
it's
compromised,
then
that
can
be
rotated
and
Ries
Island
relatively
easily.
So
then,
the
question
of
the
repudiation
is
essentially
had
that
you
trust
your
key
management
and
you
trust
GPG,
but
this
is
all
so.
That's
kind
of
I
would
say
a
brief
overview.
There
is
a
spec
for
this
called
the
update
framework,
which
is
all
or
peer-reviewed
and
in
academia.
B
B
Yeah,
basically
yeah
yeah,
so
when
we're
using
it
inside
IBM
we're
just
assigning
it
as
AI,
because
we
are
a
publisher,
so
we
basically
put
our
signature
on
to
say
we
are
IBM.
We
push
this
image,
here's
how
you
can
validate
that
we're
saying
that
what's
in
our
con
in
our
image
is
correct,
but
you
can
put
any
number
of
signers
on
to
your
image,
and
so
you
can
basically
use
it.
B
It's
entirely
possible
yeah.
It's
the
nature
of
the
cloud
native
landscape
at
the
moment.
There's
a
hundred
tools
to
do
the
same
thing.
At
the
end
of
the
day,
it
comes
down
to
what
which
tools
you're
already
using,
because
if
you
can
make
the
tool
you're
already
using
work
for
you,
then
that
works
great.
B
B
C
So
you
can
completely
just
there
is
a
notary
CLI
that
you
can.
Basically,
you
basically
means
you
avoid
using
the
dock
CLI
completely.
If
you
want
to
yeah
the
reason,
so
we
tend
to
use
the
docker
CLI
still
because
it
talks
about
notary
concepts
in
terms
of
containers
and
images
and
things
that
make
sense.
C
B
B
B
B
C
Would
say
talk
to
no
to
team
about
that,
because
it's
their
implementation
right.
We,
though,
were
our
use
cases,
because
we're
coming
from
public
cloud
is
not
an
air-gapped
environment
if
you're
doing
an
air-gapped
environment
I.
Would
that
something
notary
needs
to
support,
so
I
would
reach
out
to
some
of
the
notary
team,
Justin,
McCormick
I,
don't
know
if
he's
here
we
were
chatting
with
him
before,
but
that
does
probably
a
use
case.
They're
interested
in,
to
be
honest,.
C
So
so
you're
asking
basically
as
an
ongoing
thing
like
we're
there
for
tea.
Iris
is
a
boundary
check
right,
a
perimeter
check
and
you're
talking
about
an
ongoing
thing,
I
yeah.
So
there
are
various
tools
around
this.
It
tends
to
be
tightly
coupled
with
where
you're
deploying
so
I
know.
The
IBM
container
registry
has
this
thing
that
does
something
similar
but
that's
tightly
coupled
to
if
you're,
using
the
IBM
container
registry.
C
C
A
Yes,
so
I
mean
fundamentally
if
one
is
forming
offline
image
scanning
of
everything
that's
deployed
into
production,
so
just
like
scanning
a
registry,
and
you
certainly
then
have
a
critical.
Well,
then
look
what
you
actually
do
when
you
want
to
scale
out
that
deployment,
if
you're,
if
you're
blocking
directly
on
that
attestation,
then
you
can
no
longer
perform
scaling
events
or
like
if
we
deployed
that
that,
given
sorry
I've
missed
the
first
part
of
the
question,
sorry,
could
you
just
rephrase
it
for
me
order
for
heat
of
a
CV
in.
C
A
There's
a
question
of
the
docker
daemons
trust
and
the
integrity
of
the
contents
of
the
file
system.
I
I
would
suggest
that
I
would
suggest
that
you're
in
for
a
bad
day,
if
somebody's
already
tampering
with
something
that's
owned
by
root
on
disk,
like
that
there
are
bigger
problems
than
that
being
changed
there.
If
that
then
perpetuate
them
propagates
through
into
container
registries.
Well
at
that
point
of
revalidating,
the
show
so
I
think
specifically
that
I
yeah,
where
would
that
attack,
be
I,
wonder.
A
A
Yes,
it's
yes,
so
say
the
Spyro
implementation
does
pay
a
lot
more
attention
when
it
tests
things.
That
is
not
the
same
spiffy
as
in
sto
right
now,
right
because
that's
just
going
to
be
still
backing
off
onto
Cuban
asses
and
the
service
account
yeah
issues.
Phase
2
attestation
will
look
more
like
what
the
spy
perm
protocol
suggests
and
what
the
actual
concrete
spire
implementation
does
well.
A
Yes,
it's
so
the
statement
there
was
that
runtime
attestation
can
be
done,
but
it's
different,
tooling
and
then
specifically
we're
into
workload,
identity,
questions
that
are
being
solved
by
the
the
spiffy
team
and
so
I
tell
the
companies
our
backs.
That
project,
which
is
stone-cold
awesome
by
the
way.
If
any
of
you
interested
go
and
see
some
of
the
spiffy
talks
there,
the
basically
solving
workload,
identity,
dynamic,
works
of
identity,
so
you
can
base
cryptographic
verification
of
that
identity
onto
onto
metadata
about
the
process.
A
Sound
simple
bits,
quite
complex
involved,
but
very
interesting,
yeah
I.
Think
with
that,
we
guarantee
that
all
the
steps
do
work
if
one
has
fish
and
bandwidth-
apologies
that
that
did
not
function
as
as
we
expected
all
of
the
slides
will
will
dump
those
and
add
them
to
the
repo.
The
repo
will
stay
up
in
perpetuity.
We're
not
going
to
take
it
down
for
any
reason.
So.
A
Yeah
so
I
mean
again
feel
free
to
reach
out
to
us
all,
individually
or
collectively,
on
Twitter
with
comments
suggestions,
and
we
would
we
initially
had
this
whole
thing
done
in
the
cloud
and
then
we
were
told
we
needed
180
clusters
to
furnish
the
whole
room
and
frantically
reworked
it
for
mini
cube,
so
I
believe
it
works,
but
apologies
that
it's
too
slow.
Thank
you.