►
From YouTube: Webinar: The abc’s of Kubernetes security
Description
As more mainstream IT organizations adopt Kubernetes and cloud-native application architectures, they often identify as one of their main concerns the ability to do so securely. (Interestingly, this almost precisely matches concerns about adopting virtual machine architectures fifteen years ago.) In this session users will be guided through the domain of security concerns, starting from system hardware up through the operating system stack, Kubernetes itself, and applications deployed on it, as well as some of the tools used to address the issues.
Presenters:
Roger Klorese, Senior Product Manager @SUSE
Danny Sauer, Senior Software Engineer @SUSE
A
Okay,
let's
get
started
welcome
everyone.
Thank
you
very
much
for
taking
time
out
of
your
day
to
join
us
today.
Welcome
to
today's
cncf
webinar,
the
abcs
of
kubernetes
security,
I'm
jerry
fallon
and
I
will
be
moderating
today's
webinar.
We
would
like
to
welcome
our
presenters
today,
roger
klorse
senior
product
manager
at
soos
and
danny
sawyers
senior
software
engineer
at
sues
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
were
not
able
to
talk
as
an
attendee.
A
There
is
a
q,
a
box
at
the
bottom
of
your
screen,
so
please
feel
free
to
drop
your
questions
in
there
and
we'll
get
to
as
many
as
we
can.
At
the
end.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chatter
questions
that
are
in
violation
of
the
code
of
conduct.
Please
be
respectful
of
your
fellow
participants
and
presenters.
A
B
Okay,
thanks
very
much
oops
there
we
go
we're
going
over
a
little
bit
again.
My
name
is
roger
clarice,
I'm
a
product
manager
at
souza,
working
on
susa
cass
platform,
our
containers
as
a
service
product
or
better
known
as
our
kubernetes
distribution.
C
I
didn't
have
a
a
great
introduction,
but
I'm
danny
sauer,
I'm
a
software
engineer
working
on
the
cast
platform
with
roger.
B
Okay,
cool:
let's
take
a
look
at
high
level
agenda.
Let's
start
we'll
start
by
talking
about
how
secure
we
feel
about
containers.
Security
is
objective
measured,
but
it's
also
a
subjective
sense
and
we'll
look
at
how
the
subjectivity
effects
can
affects
containers
and
their
deployment.
B
We'll
look
at
how
you
can
address
container
security
in
many
different
areas,
we'll
look
at
an
idea.
That's
closely
related
to
security,
which
is
governance.
That
is,
you
know.
How
do
you
implement
security
policies?
Not
technically,
but
what
organizational
stances
do
you
take?
And
if
I'm
going
to
go
into
the
area
of
securing
kubernetes
environments?
Where
do
I
start?
B
I
want
to
say
up
front
that
a
little
bit
of
level
setting
you
notice.
We
call
this
abcs.
This
is
a
fairly
fundamental
view.
There
are
some
more
expert
and
more
specific
webinars
that
security,
specific
vendors
have
done
if
you
are
working
already
in
security.
B
This
might
just
be
a
pleasant
room
set
of
reminders
or
a
basis
for
discussion,
but
we
are
assuming
that
you
have
a
basic
understanding
or
a
little
more
than
that
of
linux
and
some
linux
security
features
of
containers
and
of
kubernetes.
So
it's
it's
not
linux,
one,
two
one
101,
it's
not
kubernetes
101,
but
it
is
kind
of
a
101
level
discussion
about
security
in
containers
and
kubernetes.
B
B
This
is
why
I
might
not
have
done
so
great
on
a
lot
of
true
and
false
tests.
When
I
was
a
kid
there
are
ways
in
which
containers
are
indeed
inherently
insecure.
One
of
them
is
the
fundamental
assumption
that
everything
is
inherently
insecure
unless
you
work
at
it.
B
Another
is
that
there
are
aspects
of
kubernetes
like
networking,
for
example,
that
were
originally
designed,
assuming
friendly
environments,
so
right
out
of
the
box,
basic
kubernetes
networking
assumes
that
everybody
can
talk
to
everybody,
but
it's
true
also
that
aspects
of
kubernetes
and
the
kubernetes
ecosystem
are
being
designed
and
have
been
designed
with
an
eye
of
security
from
the
ground
up,
so
containers
are
inherently
insecure.
True
containers
are
inherently
secure,
also
true,
let's
move
ahead
and
look
at
how
this
affects
how
people
feel
about
it.
B
Now,
one
of
the
most
interesting
things
I
think
about
this
chart
is
that
something
like
18
years
ago
I
presented
a
chart
that
could
have
looked
with
some
of
the
labels
changed
exactly
like
this
at
a
certain
virtualization
vendor,
when
we
were
launching
this
first
major
server
virtualization
platform,
where
the
top
two
top
three
concerns
were
indeed
cultural
changes,
security
and
complexity.
B
These
tend
to
be
true
for
any
new
technology,
but
you'll
still
note
that
security
is
a
pretty
high
level
concern
for
this
audience.
You
know
if
40
are
concerned
about
security
security
is
an
important
component
of
their
plan
and
their
delivery
and
maybe
holding
people
back
from
their
implementation.
Let's
look
at
a
few
more
things.
Well,
when
we
look
at
where
people
are
deploying
today,
the
number
one
leading
category
is
in
the
public
cloud.
B
Well,
we
would
similarly
have
a
chart
like
that
about
public
cloud,
probably
five
to
four
to
eight
years
ago.
So
you
know
the
same
concerns
carry
over
to
the
platform.
B
B
B
Many
people
have
already
done
their
proofs
of
concept,
so
that's
maybe
dropping
a
little
bit,
but
the
ramp
in
production
is
the
is
the
most
significant
factor
where
we
look
at
people
now
who
are
solidly
moving
into
production
environments,
reporting
on
this
cncf
survey,
where
four
and
a
half
years
ago
only
about
a
quarter
of
them
were
in
any
sort
of
production
on
containers.
B
Esg
did
a
survey
about
three
years
ago
that
many
of
the
learnings
are
still
valid
almost
luckily,
almost
every
company
that
they
interviewed
realized
that
containers
had
security
implications
about
a
third
were
worried
about
the
lack
of
mature
security
solutions.
B
As
with
most
new
technologies,
securing
them
generally
starts
out
with
new
vendors,
and
there
are
some
excellent
container
specific
security
vendors.
I
want
to
point
out
if
I
mention
any
of
them
by
name
later,
it
is
neither
a
specific
endorsement
of
them,
nor
a
a
lack
of
endorsement
of
any
of
the
other
people
in
that
space.
B
B
B
B
Looking
at
adding
network
security
to
the
environment
as
well
as
visibility
into
the
network
and
the
general
environment,
we
talked
about
data
in
motion
issues,
we'll
look
at
encryption.
There
we'll
talk
about
secrets
management
so
that
we
don't
expose
passwords
and
other
security
information,
we'll
look
at
restricting
access
using
policies,
as
well
as
how
the
underlying
operating
system
tools
relate
to
the
containers
themselves
and
then
we'll
look
at
monitoring
the
security
posture
using
classical
tools.
B
C
Yeah
thanks
roger
containers,
like
everything
in
computing,
are
built
in
a
series
of
layers.
You
know
whether
whether
you're
using
you
know
a
strip
down
os
as
the
base
for
your
containers
or
a
purpose-built
base
like
the
python
image,
or
something
like
that.
You
want
to
start
with
a
solid
foundation.
C
So
you
want
to
have
a
a
gold
master
image
that
you
install
your
code
on
top
of
so
you
know
you're,
you
know
you're,
not
starting
with
any
holes
and
that
build
process
you
really
want
to
use.
You
want
to
be
reproducible,
so
you
know
you
want
to
use
your
ci
cd
pipeline
to
ensure
that
your
builds
are
consistently
using
that
trusted
gold
master.
That's
already
been
verified
to
comply
with
your
organization's
policies
to
you
know
with
all
your
governance
rules.
C
So
when
your
bugs
are
found
and
patched
when
they're
rebuilt
everything
happens,
the
same
way
every
time.
B
If
you're
using
a
commercial
linux
distribution
by
the
way,
pretty
much,
all
vendors
who
offer
support
also
offer
a
base
image,
which
is
a
solid
starting
point
that
is
under
the
rich
end-to-end
controls
that
other
delivery
formats,
such
as
iso
images,
are
in.
So,
if
your
os
offers
it
a
base,
image
from
the
vendor
is
really
a
good
place
to
start.
You
can
add
things
and
remove
things
and
secure
your
own
base,
but
that's
a
great
place
to
start.
B
Space
and,
of
course,
the
worst
possible
thing
you
can
do
is
not
to
use
role-based
access
control
at
all
or
to
grant
cube
system
the
default
system
wide
admin
account
giving
it
all
permissions
on
all
workloads,
so
strive
for
the
most
secure
approach,
and
that
is
one
of
the
things
that
security
benchmarks
and
benchmark
suites
I'll
get
to
the
difference
between
those
in
a
little
bit.
C
Your
hump
so
you've
you've
got
your
solid
base
image
and
now
you've
added
code.
On
top
of
top
of
that,
so
you've
changed
things.
You
need
to
have
some
sort
of
automation
that
that
verifies
the
the
code.
Changes
that
have
been
made
still
comply
with
your
local
policies.
You
do
that
by
scanning
the
the
generated
images.
C
In
addition
to
running
at
deployment
time,
you
really
ought
to
want.
You
want
scheduled
scans.
Vulnerabilities
are
found
all
the
time,
even
if
you
haven't
changed
your
your
container,
your
code,
that's
on
the
container
new
stuff
pops
up,
so
using
scheduled
scans
on
old
containers,
make
sure
that
you're
alerted
of
new
vulnerabilities
in
old
containers
there
are
also
runtime
scanners
out
there.
Falco
is
is
one
example.
C
They
do
essentially
the
same
thing,
but
they
they
run.
While
your
container
is
running
so
they're
sort
of
your
last
line
of
defense,
where
you
know
maybe
something
popped
up
that
hasn't
been
caught
by
your
scheduled
scan.
Yet
that
still
alerts
you
that
hey
you've
got
something
running
that
you
might
want
to
look
into.
B
B
That's
implements
the
ability
to
have
different
implementations
of
networking
in
different
clusters
or
with
some
extensions
conceivably
in
the
same
cluster.
At
the
same
time,
calico
is
a
very
popular
one.
Psyllium
is
a
more
recent
one
that
leverages
a
kernel
feature
called
ebpf
or
back
packet
filtering
to
optimize
the
performance
and
improve
the
introspection
by
running
in
the
kernel.
B
Do
this
and
container
application
firewalls
do
this
as
well,
so
that
you
can
say,
for
example,
instead
of
I
want
to
set
a
policy
on
who
can
talk
to
on
what
I
can
do,
for
example,
on
port
80
or
port
443,
I
could
set
a
policy
on
http
and
then,
whatever
port
was
speaking
http,
the
system
would
recognize
the
protocol
and
implement
that
policy
on
it,
especially
with
cases
where
we
use
non-standard
ports
for
anything
from
administrative
interfaces
to
specific
application.
B
Specific
protocols
being
able
to
have
protocol
specific
policies
is
very,
is
a
very
effective
approach.
B
C
Here
you
need
to
have
visibility
into
what's
happening
within
your
cluster.
A
lot
of
the
controls
we're
talking
about
are,
you
know
static.
You
know,
you're
analyzing
things
to
ensure.
Are
things
happening
the
way
we
expect
them
to
be
happening
without
any
kind
of
observability?
You
don't
have
any
way
to
one
know
what's
expected
and
to
know
when
things
are
happening
that
are
unexpected,
so
you
have
to
expose
really
as
much
as
you
can
about.
What's
what's
going
on
within
your
cluster
network
traffic?
C
So
with
your
applications
you
want
to
export.
You
know
metrics,
wherever
you
can.
Prometheus,
is
sort
of
the
defective
place
where
all
those
metrics
you
know
get
gathered.
So
you
can.
You
can
do
your
later
analysis
and
you
know
see,
what's
what's
normal
at
the
at
the
network,
level
cni's
typically
provide
flow
analysis.
So,
rather
than
than
just
your
basic
packet
level
analysis,
network
flows
are
a
little
another
level
higher.
C
C
You
know
the
size
of
packets
that
are
generally
going,
so
you
can
see
when,
when
things
have
deviated-
and
you
know
you
might
need
to
be
concerned-
service
meshes
another
layer
above
that,
where
network
flows
are
you
know
your
layer,
three
level,
four
stuff
service
meshes
are
operating
up
at
layer
seven,
so
you
can
see
what's
happening
with
your.
You
know
your
hdb
traffic,
your
you
know
your
database
queries.
C
Your
the
whole
point
here
is
to
be
able
to
know.
What's
what
what
sort
of
communication
is
happening
inside
the
cluster,
so
you
can
identify
when
anomalous
communication
is
is
happening.
More
data
is
generally
better
here.
B
Yeah,
I
just
want
to
add,
for
example,
psyllium
offers
a
tool
called
hubble,
which
is
its
flow
analysis
tool,
but
these
exist
for
other
cni
plug-ins
as
well.
B
C
C
Yeah,
the
the
whole
point
of
secrets
is:
they
have
to
be
kept
secret,
so
what
you?
What
you
want
to
do
is
basically
expose
them
for
the
minimum
amount
of
time.
So,
in
an
ideal
world,
you
have
enough
control
over
your
application,
where
you
can
use
a
an
external
secret
manager
like
vault
or
one
of
those
kinds
of
tools
where
your
application
say
it
needs
to
connect
to
a
database
and
needs
credentials.
They
could,
you
know,
make
the
api
call
out
to
default.
C
Get
the
the
authentication
information,
make
the
connection
and
then
free
that
memory,
so
that
the
secret
is
just
not
exposed
in
the
application
at
all.
C
In
a
lot
of
cases,
you
don't
have
that
level
of
control
over
the
the
applications
you're
developing,
so
the
next,
the
next
step
down
from
there
would
be
to
have
the
secrets
available
to
your
your
application
through
the
environment
variables
that
sets
up
when
the
pod
now
gets
gets
started.
C
That's
that's
not
quite
as
ideal
because
they
still,
you
know,
exist
a
little
a
little
longer
in
the
memory
of
the
process.
But
it's
you
know
not
real
easy
to
get
to.
You.
Can
then
move
down
from
there
to
exposing
virtual
files
within
the
container,
where
you
know
the
the
environment
variables
are
passed
in,
but
they're
exposed
to
the
within
the
container
as
a
a
simulated
file
by
the
container
runtime?
B
Great
runtime
security
is
an
area
that
of
course
extends
beyond
kubernetes
itself.
We
do
have
capabilities
in
kubernetes
to
deal
with
them
and
then
starting
with
pod
security
policies.
B
Pod
security
policies
will
control
how
we
use
privileged
containers
and
what
privileges
they
can
carry
can
restrict,
which
host
resources
a
given
pod
can
use,
can
disable
or
control
privilege
escalation
expose
linux
capabilities
that
should
probably
be
a
capital
c.
That's
the
linux
feature
called
capabilities
as
well
as
os
security
profiles
through
things
like
st
linux
and
app
armor.
B
In
addition,
danny
mentioned
falco
earlier,
it's
a
good
example
to
of
of
considering
the
use
of
runtime
security
monitoring
tools.
So
we
see
what's
going
on
in
our
network
and
in
the
system
environment
at
runtime,
not
just
based
on
static
analysis.
C
This
a
little
bit,
I
yeah,
so
it's
important
to
remember
that
your
containers,
your
container
runtime,
runs
on
top
of
an
os.
C
So,
just
like
your
containers
have
to
be
built
on
top
of
a
known,
secure,
base
image,
your
runtime
ideally
would
run
on
top
of
a
known,
secure,
os
platform.
This
is
really
a
solved.
Well
generally,
a
well-known
problem.
You
know
there
are
a
number
of
os
level
security
tools
that
they
run.
You
know
your
system,
auditing,
your
you
know
os
firewalls,
that
kind
of
thing,
even
within
your
container
network.
C
If
you've
done
your
your
cni
level,
networking
filtering
and
segmentation,
you
still
probably
want
to
have
firewalls
controlling
what
gets
it
gets
access
to
the
nodes
that
make
up
your
cluster
using
a
web
application
application
layer
firewalls
in
general
to
filter.
You
know,
what's
what's
coming
in
and
ensure
that
you're,
not
exfiltrating
data,
using
intrusion,
detection,
intrusion,
prevention
systems
to
again
look
at
the
anomalous
traffic
and
act
on
that,
you
know,
use
any
malware
tools,
the
same
thing
with
storage
and
your
cloud
security.
C
B
Great
so,
let's
stepped
on
from
that
to
some
of
the
specific
things
you
can
do
to
harden
the
host,
and
this
is
in
pretty
much
the
order
that
you'll
step
into
them
through
the
life
cycle
start
with
secured
services,
and
we
mentioned
our
build
service
here.
B
There
are
obviously
other
places
to
get
secure
packages
depending
who's,
os
you're
running
on
who's
distribution,
but
be
sure
that
you
can
trust
the
package
not
just
to
the
source
not
just
to
the
source
you
get
it
from,
but
to
the
source
that
it's
built
from
secure
boot
is
an
option,
harden
the
host
so
that
it
recognizes
valid,
signed
images
and
won't
boot
images
that
have
been
tampered
with,
implement
automation
of
security
standards.
B
Security
profiles
such
as
openscap
will
do
that.
We
talked
about
firewalls,
implement,
transit
layer,
security
or
tls
throughout
the
environment,
not
just
the
internal
features,
not
just
accessing
the
api
server,
but
also
exposing
tls
for
the
applications
enable
auditing
so
that
you
have
a
path
to
assess
accesses.
B
Use
controlling
the
the
capabilities
that
processes
have
and
controlling
their
rights
through
app
armor
or
se,
linux
encrypt
file
systems
for
data
at
rest.
One
thing
we
strongly
advise
to
both
reduce
downtime
and
to
be
able
to
bring
in
security
fixes
as
soon
as
possible
is
to
implement
live
patching.
If
your
operating
system
supports
it
and
then
be
religious
about
security
updates
and
vendors,
as
well
as
yourself
concerned
about
security,
where
previous
versions
are
running
as
well.
B
B
B
We
control
where
given
workloads
can
run.
Sometimes
we
do
that
for
reasons
like
performance
and
availability,
but
sometimes
we
do
that,
for
example,
to
keep
things
like
you
know.
Here's
the
payroll
here
are
the
payroll
and
hr
systems.
Here
are
engineering
development.
I
want
to
keep
them
in
separate
places.
B
Use
of
packet
manage
package
managers
control
of
encryption.
We
talked
about
all
of
the
areas.
The
idea
here
is
have
policies
control
your
changes,
keep
them
visible
and
use.
B
B
So
that's
a
lot.
We've
talked
about
a
big
chain
of
things
today,
where
do
you
start
start
at
the
beginning?
Obviously,
and
when
I
say
start
at
the
beginning,
I
mean
look
at
these
things
from
the
beginning
of
your
implementation
process.
Well,
let's
talk
about
some
of
the
low-hanging
fruit.
B
Some
distributions
and
releases
enable
it
automatically.
This
is
really
something
you
really
don't
want
to
do.
I
said
I'm
going
to
take
a
little
step
back.
I
said
earlier
that
I
would
talk
about
benchmarks
and
benchmark
suites.
The
benchmarks
are
actually
the
standards,
not
the
tests.
B
B
Set
of
standards,
as
well
as
there's
an
implementation
of
those
to
test
those
that
is
developed
by
aqua
security,
called
cube
bench
that
should
be
integrated
into
the
process
of
your
all
of
your
deployment
processes.
I
I
generally
insist
that
it
should
be
run
all
the
time
in
in
the
upgrade
and
any
process
that
involves
the
cicd
pipeline.
B
Don't
auto
mount
the
default
service
account
token.
We
talked
about
restricting
service
account
tokens
before
use
admission
control
so
that,
even
if
you
have
privileged
containers,
you
cannot
escalate
privilege
with
shell
access,
restrict
user
impersonation.
B
B
Staying
vigilant
is
critically
important.
Don't
release
reconfigure,
don't
do
anything
without
testing
the
security
implications
of
it.
I
managed
to
bench
cue
bench
early
and
often
and
don't
do
it
by
hand.
The
most
vulnerable
component
is
humans.
B
A
Okay
well,
thank
you
both
very
much
for
a
wonderful
presentation.
We
have
about
15
minutes
before
we
wrap
up.
So
if
you
have
any
questions,
please
feel
free
to
drop
them
into
the
q,
a
box
and
we
will
get
to
as
many
as
we
can.
Our
first
question
here
is
there
any
procedure
to
add
security
to
the
containers
that
could
be
done
already
in
the
firmware
boot
phase.
B
Well,
I
think,
to
containers
in
the
firmware
boot
phase.
That's
an
interesting,
that's
an
interesting
question
for
which
I
don't
actually
have
details.
My
email
addresses
and
slides
drop
me
a
note
and
I
will
check
with
people
generally.
B
The
firmware
process
validates
the
underlying
operating
system,
not
the
containers
themselves,
I'm
not
aware
of
anything
danny.
Are
you.
C
B
Okay
thanks,
sorry
folks,
but
we
will
we'll
check
in
but
as
far
as
we
know
that
it's
firmware
to
os
and
then
os
to
containers.
A
Okay,
do
we
have
anyone
else
who
would
like
to
ask
questions?
We
have
plenty
of
time.
So,
if
you
have
anything
you'd
like
to
know,
please
drop
in
questions
and
we'll
we'll
get
to
you.
B
That's
a
really
that's
a
that's
a
good
question
because
it's
hard
to
say
what
integrated
into
kubernetes
means
as
we
go
along
now
more
and
more
things
that
have
started
you
know,
there's
there
are
two
competing
tensions.
B
B
So
I
think
the
point
of
integration
has
to
be
the
your
evaluation
and
your
choice
of
processes,
not
native
kubernetes.
Now
the
process
of
building
the
kubernetes
ecosystem
security
has
very
much
been
brought
into
it
in
that
projects
are
now
required
that
our
lecncf
projects
are
required
to
have
security
assessments,
some
of
which
are
audits,
some
of
which
are
examination
of
their
approach
to
security.
A
Okay,
thank
you
for
that
before
we
get
to
the
next
question,
just
jim,
I
want
to
address
your
question
here.
Yes,
it
will
be
possible
to
download
the
slides
for
the
pdf
for
this
webinar,
as
always,
recording
of
slides
are
posted
to
the
cncf
webinar
page
after
each
webinar.
So
please
look
out
for
those
later
today.
B
Good
good
question
I
mean,
I
think,
it's
advisable
to
run
and
I'm
gonna
use
a
more
general
term.
I
think
it's
advisable
to
use
anti-malware
everywhere
that
is
implemented
on
on
the
hosts
in
containers
in
the
pipelines
or
in
appliances
outside
the
cluster
will
vary,
and
I
mentioned
anti-malware,
because
antivirus
is
one
very
specific
sort
of
attack
point,
but
more
and
more.
B
What
we
need
to
look
at
are
analysis
tools
that
use
techniques
like
sandboxing
for
dynamic
analysis
that
is
looking
at
the
payloads
and
what
they
would
do
rather
than
you
know,
conventional
antivirus,
which
is
usually
just
looking
at
the
fingerprint
of
known
malware.
It's
the
unknown
malware,
that's
at
least
as
important,
and
we
need
things
that
can
look
at
it
behaviorally.
B
You
think
I'd
remember
where
I
used
to
work,
but
I'll
be
back
on
it
in
a
second.
They
were
just
required.
They
were
just
acquired
by
vmware,
a
very
sophisticated,
advanced
anti-malware
company.
I
feel
really
stupid
right
now.
I'm
having
like
the
memory
lapse
of
of
all
time.
C
And
pointing
out
silence
is
one
of
those
anomalous
behavior
type
programs
that
works
like
not
really
any
of
the
kind
of
runtime
security
tools,
so
it's
built
as
antivirus
antivirus,
but
it
fits
in
very
well
with
you
know,
as
we
were
saying
like
the
runtime
security
monitoring.
So
you
know
that's
the.
A
A
B
Crds
danny
you
want
to
yeah,
I
mean
if.
C
If
your
analysis,
tooling,
is
all
running
within
kubernetes
it,
you
know,
it
makes
sense
that
you
could
store
some
of
your
data.
You
know,
alongside
the
the
applications,
that's
really
more
of
an
organizational,
you
know.
How
do
you
want
to
handle
operations?
C
It's
you
know
not
a
terrible
idea,
so
it's
whatever
makes
sense
in
your
your
situation.
I
think.
A
B
Some
method
of
interfacing
external
directories
and
other
authentication
methods
such
as
oidc
and
saml
into
the
processes
we,
for
example,
at
souza
use
tools,
called
deck,
decks
and
gangway
in
our
product.
But
there
are
other
approaches
as
well,
but
yes,
absolutely
standard
directories
are
frequently
used.
Not
only
is
it
possible
it's
pretty
much
typical.
A
A
A
All
right:
well,
no
one
has
any
other
questions
and
I
think
we
will
call
this
a
day.
I
want
to
thank
both
danny
and
roger
for
a
wonderful
presentation
and
thank
everybody
for
attending
today's
webinar.
As
I
said
earlier,
the
recording
and
slides
will
be
available
on
the
cncf
webinar
page
at
cncf.
Dot,
io,
slash
webinars,
thanks
again
to
everyone
for
attending
today.
Have
a
wonderful
rest
of
your
day.
Take
care
stay
safe,
and
we
will
see
you
next
time.
Bye-Bye.