►
From YouTube: London OpenShift Commons Gathering 2019 State of Container Security Daniel Walsh (Red Hat)
Description
London OpenShift Commons Gathering 2019
State of Container Security
Daniel Walsh Red Hat
A
A
lot
of
this
is
gonna,
be
demo,
those
that
don't
know
me.
I'm
Dan,
Walsh
I
lead
the
container
runtime
teams
at
Red
Hat.
We
work
underneath
OpenShift.
We
do
everything
in
containers
underneath
the
kubernetes
level,
so
my
team
and
my
job
is
to
experiment
and
work
on
new
technologies
to
make
running
on
top
of
Koopman
running
kubernetes
and
OpenShift
better
and
so
well.
Last
year,
I
came
how
many
people,
who
were
here
last
year
and
saw
me
talk
okay,
so
we're
gonna
go
over.
A
Some
of
that
I
didn't
want
to
repeat
lashes
talks,
so
I'm
gonna
move
this
more
towards
a
demonstration.
Some
of
the
technologies
we've
been
working
on
and
we've
added
so
in
OpenShift,
4.0
we're
moving
to
cryo,
contain
the
technology.
I'm.
Actually
gonna
kick
off
a
little
bit
of
the
demo
right
now,
because
the
first
step
of
it
takes
some
time.
So
we're
going
to
be
demonstrating.
A
A
So,
as
a
talk
last
year,
I
talked
about
what
do
you
need
to
be
able
to
run
a
container?
First
of
all,
you
need
a
container
definition
and
luckily,
for
us
that
has
been
standardized.
This
is
this:
a
standards
body
called
OC,
I,
open
container
initiative
that
define
what
a
container
is
or
what
a
contained
really
what
a
container
images
and
it's
a
table
all
and
some
JSON
file
and
JSON
file
sort
of
describes.
What's
in
the
table
all
right,
it's
describes
things
like
environmental
variables
to
use
when
running
the
container.
A
The
entry
point,
the
actual
executable,
are
you
gonna
be
running
and
in
really
that's
all
containers
are.
Is
these
table
walls
and
these
JSON
files
tied
up
together
and
stored
out
a
container
registries
container
registries,
nothing
more
than
a
web
service?
Okay?
So
it's
just
a
web
server
and
there's
basically
web
protocols
interacting
between
those.
The
second
thing
you
need
to
do
when
you
run
a
container,
is
actually
pull
that
container
image
that
yo
CI
image
from
the
registry
to
your
hosts.
A
Okay,
so
we
needed
a
mechanism
for
pulling
that
down
and
we
have
built
a
library
for
that
called
containers.
Image
was
based
on
a
tool
and
I'll
be
showing
later
on
called
scope,
EO,
so
scope,
EO,
implemented
all
the
protocols
needed
to
be
able
to
pull
container
registries
to
the
host
based
on
basically
the
darker
technology.
What
docker
is
invented
for
pulling
registries,
but
we
have
a
separate
library
for
being
able
to
do
that.
A
The
next
thing
you
need
to
do
when
you
pull
a
container
image
to
the
host
is
actually
take
the
container
image
and
put
it
onto
a
disk.
Okay
containers
images
tend
to
be
layered
right.
You
might
have
heard
the
concept
of
layer
containers
and
in
the
layered
containers
you
basically
have
sort
of
a
base
image
and
then
I
put
some
modifications
to
the
image,
and
usually
it's
just
the
difference
between
the
original
and
the
modification
is
what
we're
shipping
and
then
I
might
have
a
third
layer
so
think
about
I
might
have
a
relevant
image.
A
A
So
I
want
to
ship
out
my
image
I
want
to
run
that
application,
but
when
that
application
is
pulled
down
its
pulled
down
as
four
different
images
of
really
four
different
layers,
so
each
one
of
the
layers
come
down
when
we're
storing
that
on
disk,
we
have
to
store
it
on
top
of,
what's
called
a
copy-on-write
file
system
or
a
layering
file
system.
So
what
happens
when
I
copy
it
down?
A
Is
these
layers
get
created,
usually
layering
file
systems
that
things
like
overlay
device
map
or
a
butter
FS,
and
what
we
did
is
we
created
a
library
to
be
able
to
handle
these?
So
we
have
container
storage.
So
container
storage
is
a
is
a
gold
library
that
basically
supports
overlay
device,
mapper
and
different
types
of
storage,
so
I
can
have
a
different
definition
of
an
image.
Now
you
can
pull
it
to
my
host.
I
can
store
on
disk
now.
A
I
need
to
run
it
so,
the
last
step
of
running
it
is
we
needed
a
standard
mechanism
for
what
it
means
to
run
a
container
when
I'm
running
a
container
I'm
really
talking
about
taking
input
from
three
different
entities.
We
have
the
OCI
image
right.
Remember,
I
told
you
it
had
a
JSON
file
associated
with
that
sort
of
has
definitions
of
what
it
means
to
what
that
container
is
the
intention
of
how
to
run
that
container
and
repoing
environmental
variables.
A
Then
we
have
the
tool
or
the
container
engine
that
pulls
down
the
image
it
has
inputs.
So
it
has
hot
code
of
things.
Little
things
like
you
know,
generating
selinux
types
or
about
what
capabilities
are
going
to
be
defaulted
to
or
on
or
off
and
different.
You
know
maybe
suck
comp
filters
things
like
that,
and
then
you
have
the
user
input
right.
So
anytime,
you've
run
a
container
engine.
You
basically
have
given
an
input.
I
want
to
run
in
privileged
motor
I
want
to
run
with
these
additional
capabilities.
A
So
you
need
to
take
those
three
inputs
right:
the
image,
the
tool,
that's
pulling
it,
and
then
the
user
input
and
combine
them
together
and
somehow
describe
what
you
intend
to
run
a
container
is
definition
and
that
that
thing
that
gets
created
then
is
called
as
OCI
runtime
specification.
It's
another
JSON
file,
but
we
needed
to
have
a
standard
JSON
file
that
can
take
that
container.
Runtimes
then
could
interpret
so
container.
Runtime
is
a
tool
that
reads
that
JSON
file
and
talks
to
the
whole
Linux
kernel
and
says
I
want
to
do
this
right.
A
I
want
to
set
up
these
C
groups.
I
want
to
set
up
these
security
separation
I
want
to
set
up
these
namespaces.
So
we
have
these
four
things
to
run
a
container.
But
the
big
thing
to
understand
here
is:
there's
no
requirement
for
a
big
fat
container
daemon
to
do
any
of
this
stuff.
Okay,
we
have
a
standard
definition,
anything
that
sits
a
dr.
IO,
quai
dot,
IO
registries,
dot,
Red
Hat
that
access
to
car,
whatever
the
Google
one
is
they're
all
been
standardized.
A
How
do
I
set
up
the
default
security
that
that
entity
is
going
to
provide?
Remember
I
talked
about
the
middle
entities,
providing
what
security
who
know
it
has
input
to
what
it
means
to
run
a
container.
So
what
we
want
to
do
is
we
want
to
break
a
pot
that
that
into
sort
of
four
different
categories
of
container
management,
okay,
the
first
one
we
want
to
be
able
to
build
containers
right.
You
want
to
be
able
to
build
container
images.
Second,
one
is
you
want
to
sort
of
run
and
play
and
develop
the
container
images?
A
The
third
one
is,
you
want
to
store
and
share
them,
so
how
do
I
move
things
around
and
then
the
fourth
one
is
running?
Containers
in
production
and
I
argue
that
each
one
of
these
steps
has
different
security
goals
right,
there's
real
different
security
required
for
each
one
of
these
steps,
and
if
we
go
back
to
the
history
in
UNIX,
the
you
know,
the
whole
UNIX
philosophy
was
to
do
things
simply
right,
simple
things
in
each
one
of
them.
A
You
know
unique
and
do
them
well,
so
we
really
wanted
to
do
is
break
a
pot
so
that
what
was
the
traditional
way
everybody
was
running
containers
into
these.
You
know
sub
categories
and
sub
tools,
and
so
the
tools
were
going
to
be
showing
and
demonstrating
today
are
all
being
slowly
built
and
organized
into
openshift.
So
when
we're
building
containers
for
build
is
the
tool
called
builder
okay
and
it's
making
fun
of
my
Boston
accent,
but
basically
it
is
a
container
builder.
A
The
second
one
is
I
want
to
run
and
play
with
containers
how
many
people
have
heard
of
pod
man.
Okay,
whole
bunch
of
excellent
okay,
so
pardon
man
is
all
about
sort
of
playing
of
the
developers.
You
know
when
a
developer
needs
to
build
containers
and
stuff.
He
Padma
is
a
tool.
The
next
one
is
a
tool
called
scope,
EO
and
scope.
Eo
really
is
just
a
tool
I
like
to
think
of
as
like
our
sink
or
SCP.
A
It's
really
a
way
to
move
these
container
images
around
right
to
move
container
images
from
external
registries
say
you
have
a
you
only
want
your
cut
now
use
the
developers
to
work
with
your
internal
registry.
Well,
you
want.
You
need
a
tool
to
copy
from
potentially
from
external
registry,
into
your
internal
registry,
so
you
can
develop
with
them
and
then
the
last
one
is
running
containers
in
production
and
we're
really
to
me:
that's
the
one.
We
really
need
the
tightest
security
on
and
that's
now.
A
Obviously,
in
this
case
is
cryo
in
an
open
ship,
400
you'll
be
getting
cryo,
we
should
contain
a
runtime
engine
and
you'll.
Get
builder
is
built-in
builder,
is
really
a
library
for
building
container
images.
So
when
you're
doing
your
sauce,
the
image
it'll
be
using
build
around
only
needs
two
covers,
so
let's
look
take
a
quick
look
at
builder
and
then
we'll
get
into
the
demo
of
it.
A
So
we
want
one
of
the
key
things
to
be
understand
about
builder,
but
one
of
my
goals,
when
we
develop
builder,
was
to
really
look
at
shrinking
the
attack
surface
of
a
container,
so
container
images
microservices
developed
in
such
a
way
that,
theoretically,
if
you
need
an
upgrade
image
or
an
update,
a
container
image,
you
should
be
swapping
it
out.
You
shouldn't
go
into
a
container
image
and
do
a
DNF
update.
Okay,
that
is
an
anti-pattern.
A
What
you
should
be
doing
is
say
you
have
a
CV
and
a
library,
that's
included
in
the
bill
in
an
image
you
put
in
a
new
image
on
top,
but
because
of
the
way
darker
files
were
built,
you
have
to
have
DNF
and
yum
inside
of
the
container
images.
Okay,
that's
just
basic
weather,
so
the
images
have
to
have
all
the
tools
used
to
build.
A
A
Do
it
that
simple
right?
All
these
container
images
are,
is
a
directory
and
some
JSON
file.
Well,
why
can't
I
just
build
that
and
push
it
to
a
registry?
So
that's
something
builder
allows
you
to
do
other
things
that
we
can
do
with
builder
now
is
build
in
isolated
containers
and
run
without
route.
But
let
me
show
you
that,
rather
than
talking
about
it,.
A
Good,
you
can't
see
it
so
the
top
line
in
the
blue
there.
It
says,
build
it
from
scratch.
So
what
that's
doing
is
it
just
creates
a
directory
on
disk
and
you
know,
creates
a
builder
container.
You
can
see
working
container
three
after
I
enter
my
password
and
then
we're
going
to
mount
the
container
so
that
basically
I'm
mounting
up
creating
a
directory
disk
and
then
we're
just
doing
a
DNF
install
here.
So
there's
a
DNF
install
lying
there
in
its
installed
root
is
mount.
A
So
that's
the
mount
point
that
I
created
on
the
system
and
I'm
just
installing
busy
blocks
from
Fedora
29
and
basically
so
I
started
out
with
nothing
inside
of
the
container
and
I
just
installed.
The
package
that
I
wanted
to
be
inside
the
container
and
that
because
of
slow
internet
has
happened
in
the
background.
A
So
now
the
container
and
now
I'm
gonna
try
to
I'm
gonna
created
a
container
image
off
of
it
and
at
this
point
I'm
gonna
run
ping
inside
of
the
container.
Oh,
that's
weird!
That
field.
Oh
that's,
right,
ping
doesn't
exist
inside
of
the
container,
because
I
didn't
install
it.
I'm
gonna
run
Python
inside
the
container.
Oh
that's
right,
Python
doesn't
exist
inside
the
container.
The
only
thing
inside
of
this
container
is
busybox
right,
there's
no
special
tooling!
A
A
Builder
being
separate
is
that
builder
can
actually
be
run
inside
of
containers,
and
this
is
actually
what
OpenShift
4.0
is
gonna
be
doing.
It's
actually
gonna
allow
you
to
run
builds
inside
of
your
openshift
environment,
but
unlike
open,
openshift,
3.7
and
everybody
else
in
the
universe,
we're
not
leaking
the
darker
socket
into
the
containers,
so
we
don't
have
to
run
every
single
container,
that
does
a
bill,
doesn't
have
access
to
the
darker
socket
and
by
doing
that,
we
increase
the
security
of
the
systems.
A
It's
actually
running
a
container
so
pod
man's
running,
a
container
I
took
some
directory
in
my
volume,
but
basically
I
created
some
storage
and
I
previously
built
a
builder
container,
so
I'm
running
the
Builder
container
inside
of
the
container
is
pulling
down
alpine
and
basically
executing
that
docker
file.
So
now
I
have
a
builder
container.
You
know
basically
I've
just
built
a
container
inside
of
a
container
without
leaking
any
kind
of
socket
in
and
basically
it's
done
it
inside
of
a
secure
environment.
A
So
let's
go
back
so
that's
example
of
some
stuff.
You
can
do
with
Bill
de
doop.
Okay.
So
now
we're
gonna
look
at
pod
men,
so
pod
man
is
a
replacement
for
the
docker
CLI.
It
allows
you
to
do
everything
pretty
much
everything
that
dr.
CLI
can
do
or
lease
that
side
goal,
except
for
things
like
Swan,
because
we're
in
the
kubernetes
community,
but
pretty
much
every
command
that
you've
ever
executed
with
darker.
You
can
do
with
pod
man,
but
it's
interesting
that
we
can
do
them
all
without
root.
A
But
I
actually
gave
a
talk.
We
were
at
the
Brno
this
past
week
and
I
gave
a
talk,
and
this
I'll
extend
my
time
a
little
try
to
get
through
this
talk
so
replacing
doctor
with
pod
man
and
guys
what
happened
with
the
red.
You
guys
are
sleeping
out
there,
alright.
So
the
first
thing,
if
you
want
to
replace
doctor
with
pod
man,
you
do,
is
you
do
DNF
install
pod
man,
everybody
got
so
far,
then
you
do
alias
doctor.
He
goes
pod
man
and
the
next
step
is
any
questions.
A
It
was
a
very
short
talk,
ok
and
the
way
I
proved
it
is
that
this
by
the
way
this
came
out
back
in
and
May
29th,
this
alan
moran
tweeted
out.
I
completely
forgot
that
two
months
ago,
so
back
in
ones
that
april
last
year,
I
completely
forgot
that
almost
two
months
ago
I
set
up
an
alias
of
doctor
who
goes
pod
man,
and
it
has
been
a
dream.
A
So
let's
go
look
a
little
closer
to
what
pod
man
some
interesting
features:
a
prod
mant
engine.
Okay.
So
if
you
see
here
the
pod
man
command
up
the
top,
there
doesn't
have
the
word
sudu
behind
it
and
I'm,
not
cheating,
there's
nothing
going
on
behind
on
the
script.
It's
actually
gonna
run
pod
man
as
non-root,
so
it
just
showed
you
the
images
that
are
in
my
home
directory
versus
images
on
the
system.
A
Bit
so
there
that
the
previous
one
showed
you
images
in
my
home
directory
and
then
images
on
the
system,
so
the
ones
with
pseudo
in
front
of
it.
So
you
see
there's
a
totally
different
list
of
images.
So
when
I'm
running
pod,
man
is
non
rude,
I'm,
actually
writing
the
images
to
my
home
directory.
So,
as
you
get
you
developing,
even
developers
come
to
you
and
say:
I
need
to
run.
A
Docker
I
need
to
run
docker
on
the
server
to
play
with
the
container
images
there
you
can
say:
no,
you
can
use
Padma
and
I,
don't
have
to
give
them
access
to
the
dock,
to
the
darker
socket.
So
now,
I'm
got
actually
run
the
container,
and
this
actually
shows
this
example.
We're
doing
is
we're
running
a
container
only
showing
UID.
A
So
there's
a
file
out
on
the
system
called
it's
the
sub,
UID,
alright
and
every
modern
Linux
system,
anything
more
modern
than
rel
7.6
has
this
now
we
will
have
in
rel
7.7
everything
I'm
about
to
show
you
so
that's
coming
out
in
the
summertime,
and
it's
really
it's
not
to
do
with
our
container
tools.
It's
actually.
We
need
a
new
version
of
shadow
utils
to
be
able
to
do
this.
So
there's
a
file
on
disk
call.
A
It
cat,
Etsy,
sub,
UID
and
you
see
up
here-
has
D
Walsh
and
it
basically
says
that
not
only
am
I
gonna
have
my
UID
ability
to
use
it,
but
I'm
also
getting
these
UID
so
I
get
all
you
IDs
from
a
hundred
thousand
to
a
hundred
thousand
six
hundred.
Fifty
a
hundred
thousand
six
sixty
five
thousand
five,
thirty
six.
So
basically
the
system
is
now
allocating
lots
and
lots
of
you
IDs
for
each
use
that
gets
added
to
the
system.
A
Now,
if
I
look
at
my
directory
I'm
about
to
run
this
test
on,
that's
what
my
directory
looks
like
and
you
notice
in
the
third
file
down.
There
is
a
file
owned
by
root:
ok,
probably
not
a
common
thing
to
have
root
inside
of
my
home
directory,
but
now
I'm
going
to
do
a
builder
on
share
and
I
go
look
at
the
same
directory,
so
build
around
share
actually
puts
my
account
into
a
username
space.
So
it's
switched
now
is
still.
This
is
not
privileged.
I
am
not
real
root
in
the
system.
A
I
am
root
inside
of
my
username
space,
but
you
see
the
file
that
is
owned
by
root
now
becomes
nobody
and
all
my
files
now
become
root?
Okay
and
that's
based
on
what
now
basically
what's
happening
here,
is
I,
go
put
it
put
into
a
user
name
space,
so
when
I
run
pod
man
or
builder
is
non
root.
I
am
being
stuck
into
a
user
name
space
that
says
map
UID
inside
of
my
name,
space
to
3267.
Remember,
that's
my
UID!
A
So
that's
what
I
login
to
the
system-
and
it
says,
map
one
UID
to
that.
Then
it
says
starting
at
UID.
One
inside
of
the
container
map
100,000
for
the
next
65,000,
so
I
have
basically
650
5036.
You
IDs
that
I
can
now
play
with
so
I
can
create
files
that
are
owned
by
one
and
two
and
three
and
four
and
I
can
install
software
that
might
come
with
Apache
home
by
UID
60
inside
of
my
home
directory.
It's
going
to
be
mapped.
The
UID
60
would
be
mapped
to
UID
100,000
and
59.
A
So
we
can
use
pod
man
to
run
containers
inside
of
you
use
a
namespace
in
your
home
directory,
but
user
name.
Space
was
always
gain,
guided
at
basically
giving
me
container
separation.
So
if
I
run
five
different
containers,
all
in
different
user
name,
spaces
I
can
actually
use
UID
separation
to
separate
them.
These
are
the
things
that
we're
looking
to
add
to
cryo
to
make
our
openshift
containers
more
secure.
A
So
here,
I'm
gonna
run
a
container
now
now
I'm
running
with
sudo,
but
now
I'm
gonna
run
a
container
and
this
time
I'm
mapping
hundred
thousand
or
being
5000
UID,
starting
at
a
hundred
thousand
to
a
sleep
container,
and
this
is
an
interesting
thing
that
pod
man
also
has.
It
actually
has
the
ability
to
show
you
showed
the
process
inside
of
a
container
and
how
they
map
so
a
mapping
route
inside
of
the
container
to
UID
100.
A
So
pardon
me,
on
top
now
it
takes
the
flags
of
user
and
H
user.
So
it
shows
you,
with
a
user
inside
the
container
and
outside
of
the
container
and
I'm
gonna,
show
you
that's
that's
actual
the
container,
so
that's
just
standard
PS
command,
showing
you
that
it's
running
as
UID
100,000
outside
of
the
container
now
I'm
gonna
run
a
second
container
as
UID
200,000,
I'm
gonna
show
you
there's
PS.
A
So
now,
I
have
two
containers
simple
as
that
running
on
the
system:
each
one
in
a
separate
user
name,
space
that
means
I've
either
one
of
those
containers
breaks
out.
It's
going
to
be
UID
200,000
attacking
UID
100,000,
not
real
UID
root
attacking
it.
So
this
allows
you,
as
we
add
this
functionality
to
cryo
all
of
a
sudden.
We
can
start
to
launch
each
container
in
a
separate
user
namespace
and
give
you
better
security,
separation.
A
One
last
thing
about
pod
man,
padmi
and
versus
darker
pod
man
uses
the
fork
and
exact
model.
So
anybody
have
it
know
what
login
UID
is
no
security
people
out
there?
Ok!
So
when
you
log
on
to
a
system
there's
a
flag
set
in
the
first
process
system
to
say
you
are
Dan
Walsh
and
no
matter
what
I
do
sudo
root
or
anything
else
on
the
system.
It
will
report
me
report
that
I
am
GN
Walsh,
so
we
can
track
what
the
user
does
on
the
system.
A
So
if
that
is
set,
login
UID
and
root
can't
change
it
so
now
I'm
going
to
execute
a
command
as
part
I'm
going
through
sudo,
so
I'm
becoming
the
root.
So
that's
another
shell,
I'm
executing
part
man,
part
man
is
then
executing
a
container.
So
I
am
now
four
levels
away
from
the
login
user
on
the
system,
and
yet
it
still
reports
that
Dan
Walsh
did
this.
Ok,
if
I
do
the
exact
same
command
underneath
docker,
it
reports
that
it
was
done
by
42
billion
of
4.2
billion,
what
it
would
whatever
that
number
is.
A
That
number
is
actually
minus
1
and
a
64-bit
number
category.
Ok,
so
what's
happened
here
is
su.
Docker
is
a
client-server
operation,
so
I
am
a
client
talking
to
a
demon,
and
the
demon
actually
is
exactly
right,
that
the
big
fat
demon
and
when
it
execs
it
was
never
started
by
a
user
right.
It
was
started
by
the
init
system.
So
therefore
it's
reporting
that
it
was
started
by
nobody.
So
now,
why
is
that
important?
A
Let's
put
an
audit
control
that
watches
who's
modifying
it
see
shadow,
so
I
just
ran
a
container
that
modified
that's
a
shadow.
So
here
we
say
turn
on
auditing
next
line
is
I've
mounted
into
a
container
the
ability
/
mounted
at
host,
and
then
I
touched
host,
/,
Etsy
shadow,
so
I've
modified
that
see
shadow
on
the
host
if
I
log
into
the
container.
A
If
I
then
look
at
the
auditing
subsystem
reports
that
who
modified
Etsy
hook
at
see
shadow
be
walls
dead
right
now,
if
I
do
the
exact
same
command,
modify
Etsy
shadow
with
docker
it
reports,
instead
of
it
being
D
Walsh,
did
it
that
it
was
a
UID
unset.
So
if
you
give
your
users
the
ability
to
talk
to
darker
daemon,
they
can
do
things
on
your
system
that
you
have
no
idea
who
did
it
on
your
system?
They
can
also
remove
the
log
set.
A
Basically,
all
the
darker
locks
get
removed
when
you
destroy
the
containment
last
couple
of
top
features
upon
me
on
features.
Basically,
I
can
things
like
the
pit
on
the
host
and
the
pit
inside
the
container
I
can
see
what
SELinux
labels
are
associated
with
it.
I
can
see
whether
the
SATCOM
filtering
is
turned
on.
I
can
see
some
capability,
so
this
is
gonna
come
up
in
a
minute
but
notice.
These
are
the
default
capabilities
that
I
see
that
darker
runs
by
default.
A
I,
don't
need
to
do
the
auditing
writing
system
and
there's
a
couple
others
in
there,
so
we
run
in
cryo
we're
gonna
cut
down
on
a
number
of
capabilities
in
it.
This
list,
no
one
knows
unless
you're
a
developer
and
actually
looked
at
the
code
because
it's
not
revealed
so
we
wanted
to
reveal
to
users
what's
actually
going
on
inside
of
the
containers.
A
What
we
wanted
to
do
is
basically
go
out
and
look
at
a
registry
and
download
that
without
having
to
pull
the
image
to
the
local
system
and
then
you're
able
to
move
images
between
different
types
of
environments-
and
it
runs
without
root
right,
there's,
no
reason
for
root
I'm,
just
moving
these
blobs
from.
If
I
can
move
from
one
repository
to
another
repository
I,
don't
need
to
pull
it
in
and
make
it
root
in
the
system
right,
I,
don't
have
to
save
it
anywhere,
I,
just
move
it
back
and
forth.
A
So
here
is
that's
the
scope,
yo
command
and
right
now,
I'm,
basically
going
out
to
fedora,
and
this
is
actually
pulling
down
the
JSON
file.
So
that's
actually
never
pulled
the
image,
never
pulled.
The
Fedora
image
is
not
storing.
In
a
local
disk,
but
basically
pulled
down
the
JSON,
if
you
just
want
to
look
at
the
JSON,
that's
associated
with
an
image,
you
just
do
it,
so
this
is
actually
kind
of
so
here
we
have
a
list
of
Hogman
images.
Well,
I
should
have
removed
the
Ubuntu
image,
but
anyways.
A
Here's
a
list
of
darker
images
and
what
I'm
going
to
do
is
scope.
You
actually
has
the
ability
and
all
the
tools
have
the
ability
to
do
this
to
transfer
between
different
types
of
container
storage
and
so
I
can
copy
from
container
registries.
But
in
this
case,
I'm
gonna
copy
an
image
directly
out
of
the
darker
daemon
into
something
pod.
Man
can
use
okay,
and
this
might
be
as
people
looking
to
convert
from.
A
You
could
actually
use
scope
yo
and
run
through
your
container
images,
and
what
this
is
doing
is
pulling
directly
from
the
from
the
darker
demon
and
now
storing
it
inside
of
basically
inside
of
something
pod
man
can
use.
So
you
can
actually
move
between
container
storage
to
directories.
Registries.
Everything
else
scope,
yo
has
all
that
built
in
it,
but
scope
is
using
containers
image,
which
means
that
builder
cryo
and
Lib
pas
and
pod
man
are
also
getting
the
same
type
of
functionality.
A
Okay,
so
cryo
cryo
is,
if
you've
seen
last
year's
presentation,
I
go
through
into
major
major
pounding
away.
That
cryo
is
all
about
love
for
kubernetes
it
services
just
kubernetes.
We
had
it
this
past
week
we're
the
reason
I'm
in
Europe.
Is
we
had
this
huge
conference
in
Brno
last
week
called
dev
cough
and
one
of
the
talks
there
was
talking
about
how
cryo
is
tested.
Cryo
right
now
has
15,000
tests
running
on
every
single
PR.
If
you
want
to
change
cryo,
you
got
a
pass
15,000
test,
every
single
kubernetes
test,
every
single
openshift
test.
A
Every
test.
We
can
imagine,
there's
a
thing
called
cry:
CTL
we
just
take
all
the
tests,
we're
testing
it
on
top
of
Ubuntu
on
top
of
rel
on
top
of
fedora
we're
talking.
We
we
also
embed
cotta
container
tests
on
top
of
it,
so
we
basically
want
to
make
absolutely
positively
sure
that
we
don't
break
kubernetes
all
right.
That's
why
it's
totally
dedicated
to
it,
but
we
also
want
to
add
security
features
to
cryo,
to
make
running
containers
in
production.
More
secure,
I
personally
believe
that
all
containers
and
production
should
be
run
as
read-only.
A
You
don't
want
your
containers
writing
to
slash
user
as
an
example,
we
want
to
enable
fewer
capabilities
again,
as
I
showed
you
earlier
and
pod
man.
You
know
the
list
of
capabilities
that
we
allow
by
default.
We
want
to
stake,
start
taking
advantage
to
user
name
space,
and
we
want
to
do
things
like
make
our
government
customers
happy
by
actually
implementing
FIPS
mode
all
through
the
stack.
A
So
we're
going
to
show
you
basically
how
to
turn
on
container
on
basically
read-only
support
inside
the
containers,
so
I'm
using
tri-c
TL
for
this,
this
demonstration,
I'm,
not
using
full
kubernetes
or
full
openshift
tri-c
TL,
is
the
tool
that
mimics
kubernetes
and
just
makes
easier
for
demonstrations.
So
we
turn
on.
We
had
their
they
read-only
flag
off.
We
actually
edited
and
turn
on
the
right
to
read-only
flag
and
now
I'm
running
a
container,
as
you
would
run,
underneath
OpenShift
with
read-only
flag
turned
on
there's.
A
A
We
saw
previously
as
a
list
of
capabilities
that
are
on
by
default
inside
of
pod
man
and
inside
of
darker
in
cryo.
We
exposed
to
you
the
capabilities
that
are
running
inside
of
your
containers,
so
you
can
go
in
here
and
actually
modify
container
capability.
So
if
you
think
that
I'm
never
gonna
run
a
container
that
requires
this
to
route,
I
can
turn
that
off
just
by
editing
that
so
what
I'm
gonna
do
is
I'm
gonna
go
in
here
and
it's
just
rude.
A
If
anybody
interesting
I
could
talk
about
what
these
capabilities
allow
you
to
do
by
the
way,
all
that
everything
I'm
talking
about
stepping
back
and
forth,
if
you
just
run,
is
non
route
out
of
the
box
run
all
your
containers
without
requiring
route.
You
don't
need
these,
but
I
know
some
of
you're
gonna
run
some
containers
that
require
route.
A
So
if
I'm
gonna
just
do
a
remove
that
from
the
container
and
a
restock,
cryo
and
I'm
gonna
go
in,
and
if
my
demonstration
works
right,
I
should
no
longer
see
cap
shown
on
the
list
of
capabilities
up
there.
So
you
have
now
with
cryo.
You
have
the
ability
to
choose
what
level
of
security
what
kind
of
containers
you
are,
but
with
countries
with
ability
comes
great
responsibility,
you
break
it,
you
own
it
okay,
but
anyways.
A
You
can
start
to
examine
and
look
at
how
you
want
to
secure
your
system
and
basically
can
start
to
define
I'm,
not
gonna.
Allow
you
know
these
capabilities
inside
of
my
containers
better
by
the
way,
kubernetes
can
always
override
that.
But
now
kubernetes
has
to
request
you
override
the
capabilities.
A
A
Okay,
so
that
is
basically
the
end
of
the
presentation,
as
you
can
see,
we're
taking
advantage
of
different
tools
breaking
it,
apart
of
which
tools
do
which
function
well
and
then
concentrating
on
the
security
of
each
one
of
those
functions.
We're
also
experimenting
at
the
low
levels
trying
to
figure
out
how
the
best
way
to
use
username
space
inside
a
pod
man
once
we're
comfortable
with
that.
We
actually
move
that
that
capabilities
into
cryo
right
start
to
look
at.
A
Can
we
move
those
I
mean
to
cry,
oh
by
the
way
off
for
everybody
taking
pictures
at
the
top
here,
the
slides
are
available
and
everything
I
demo
for
now
on
is
always
going
to
be
in
github.
So
if
anybody
wants
to
try
these
demos
and
prove
that
I
am
lying
or
I
am
NOT
we're
putting
out
all
the
demonstrations,
so
all
these
scripts
and
all
my
team
is
putting
out
any
scripts
we're
doing
online
plus
you'll.
Have
this
so
I?
Guess
no
questions.
You
can
ask
me
questions
later.