►
From YouTube: The Secure Cloud Cast (E3) | KubeCon Announcements and a Walkthrough of Advanced Cluster Security
Description
Welcome to the Secure Cloud Cast!
Here you can find our monthly show focused on all things security, cloud native, and open source projects. Today we are discussing the following:
- KubeCon Announcements!! What we are looking forward to and how you can watch
- The Istio project reaches incubation
- Getting started with SigStore
- Weekly Reading: 6 Overlooked Yet Important Kubernetes Features to Secure
And we will have Chris Porter joining the show to discuss Red Hat Advanced Cluster Security. Chris is on to review RHACS’s recent updates, answer your questions and give a demo of the new features.
A
A
B
Yes,
hello,
hello
and
welcome
it's
the
third
episode
of
the
secure
cloudcast
every
third
Tuesday
of
every
month
we
get
together.
We
talk
about
all
things:
kubernetes,
Cloud
native
anything
security
related,
including
updates,
especially
in
the
open
source
world,
so
I'm
Mike,
Foster
and
I'm
joined
by
my
lovely
co-host.
B
Yes,
that's
great
thanks
again,
this
is
the
third
episode.
Hopefully
you
guys
been
following
along.
We
have
a
pack
show
kubecon's
coming
up
next
week,
so
we're
looking
forward
to
talking
about
that
and
we
have
a
guest
special
guest,
Chris
Porter
who's,
going
to
be
talking
about
all
things.
Security
supply
chain,
ACS
stack
rocks.
B
So
if
you
have
any
security,
related
questions
drop
them
in
the
chat
for
him
coming
up
for
those
who
don't
know,
like
I,
said:
I'm
Mike
Foster
I've
been
in
kubernetes
and
kubernetes
security
for
about
four
or
five
years
now,
with
a
like
background
more
in
the
devops
and
Consulting,
and
join
stack
rocks
over
two
years
ago
now
and
recently
got
acquired
by
red
hat.
So
it's
been
a
fun
Journey.
It's
been
kind
of
a
hectic
couple
years,
but
really
excited
and
Kim.
C
So
I've
been
working
in
various
areas
of
security
since
2015
from
threat,
intelligence
to
vulnerability
management,
infrastructure
security,
vendor
risk
log
monitoring,
firewalls,
all
the
different
things
I
like
to
diversify.
What
can
I
say
and
I
joined
Red
Hat
here
in
January
to
focus
on
security
use
cases
specifically
for
openshift.
B
C
I
do
so
specifically
around
our
open
shift.
Commons.
We
actually
will
have
a
customer
come
it's
pratik
Patel
and
he
is
actually
the
head
of
cloud
security
and
Informatica
and
he's
going
to
talk
about
how
or
discuss
specifically
around
how
they
automate
and
operationalize
devsecops
to
best
address
eks
security
and
compliance
requirements
using
Red,
Hat
Solutions.
C
C
B
Also
be
talking
at
the
cloud
native
security
con
bright
and
early
on
Monday
morning,
9
20.,
we'll
be
talking
about
MP
guard
and
shifting
left
with
those
Network
policies.
Pretty
excited
I
know
Boaz
is
in
the
chat.
So
if
you
have
any,
let's
say
kubernetes
and
network
policy
questions
Chuck
them
in
there
as
well
I
think
on
Tuesday,
it's
six
door.
Con
I
believe
Tuesday.
Six
for
Khan
want
to
give
a
shout
out
to
Luke
Heinz
he'll
be
presenting
and
giving
a
keynote
there
as
well.
B
I
think
he's
been
working
tirelessly
over
the
last
year
and
a
half
on
that
project,
especially
after
the
red
hat
donation
to
The,
cncf,
so
I
think
it's
it's
really
cool
to
just
have
all
these
people
in
one
place
and
really
looking
forward
to
finally
meeting
everybody
for
the
first
time
yeah.
It's
gonna
be
great
any
other
sessions
that
you
want
to
call
out.
Kim
I
know,
kubecon
is
packed
and
it's
going
to
be
recorded.
Everything's
gonna
be
online,
typically
two
or
three
weeks
after
but.
C
B
And
if,
if
you
missed
the
the
keynote,
I'll
be
doing
a
little
demo
in
the
booth
as
well,
the
red
hat
booth
at
belief,
12
40
on
Wednesday
so
swing
by
and
you
get
more
of
a
Hands-On
look
at
what
I'll
be
speaking
about,
and
this
is
kind
of
a
weird
throw
in.
But
if
you
do
like
Cloud
native
security
con,
it's
something
you
want
to
go
to
in
the
future.
B
C
B
B
Hopefully
I
mean
you
could
always
just
make
quick
Trek
up
to
the
mountains
in
in
BC
yeah.
The
last
thing:
well,
there's
two
more
things:
istio
reached
incubation,
I'm,
not
sure
if
you
saw
this
Kim,
but
it
was
a
huge
announcement.
Istio
finally
got
accepted.
It's
still
a
long
ways
to
go
to
graduation,
but
for
the
project
to
be
a
lot
around.
B
C
I'm
cool
it's
on
cool
man,
no
I
do
not
have
thoughts,
but
we
do
have
Chris
coming
on
to
talk
a
good
bit
about
ACS
and
we
have
had
a
couple
of
releases
this
past
quarter.
So
we
can
ensure
talk
about
that,
but
we
do
want
to
talk
today
in
terms
of
or
some
specific,
listen
to
me
specific
things
that
you'll
cover
will
be
around
six
overlooked.
C
B
A
very
very
SEO
friendly
amount.
Let's
say
what
I
thought
was
really
interesting.
Is
it
it?
It
used
our
2022
state
of
kubernetes
security
report.
So
always
model
has
been
working
titles
here
behind
the
scenes
to
to
talk
to
kubernetes
customers
get
their
feedback
talk
about.
What's
delaying
production,
what
are
some
of
the
biggest
security
impacts
in
their
communities,
clusters
and
yeah,
so
it
was
really
cool
to
have
that
reference
and
I
think
you
know
six
six,
sometimes
eleven
twelve
you're
supposed
to
avoid
five
or
ten
I
guess
for
the.
A
No
I
will
miss
out
on
a
trip
to
lovely
Detroit.
This
year,
I've
been
a
coupe
Con
on
and
off.
You
may
have
seen
me
there
and
so
no
there's
you
know,
there's
there's
you
know
we're
coming
from
stack
rocks
where
you
and
I
just
kind
of
did
everything
we
got
roped
into
every
task,
every
fire
that
was
burning.
B
B
A
Yeah,
so
my
title
here
is
the
director
of
solution
architecture.
So
I
have
a
team
of
specialist
solution.
Architects
that
help
customers.
We
have
red
hat
with
all
kinds
of
products
and
services
here
at
Red
Hat,
you
know
me
is
mostly
a
specialist
on
the
ACs
topic
and
stack
rocks
topic,
but
I
have
other
team
members
that
are
focusing
on
other
areas
like
application.
A
Prior
to
that,
my
career
is
mostly
been
a
series
of
startups.
Some
of
them
through
you
know,
gone
to
acquisition,
so
I've
ended
up
at
larger
companies
from
time
to
time.
So
the
you
know
the
shifting
back
and
forth.
If
you
look
through
my
LinkedIn
you'll,
see,
small
company
acquired
by
a
bigger
company
spend
a
little
time
there
transitioning
things,
but
always
in
security,
at
least
for
the
last.
B
Awesome
yeah
I
was
I
kind
of
want
to
kick
off
this
first
question
because
you
touched
on
a
lot
there:
we've
had
Kirsten
who's,
been
at
red
hat
for
I.
Think,
like
six
or
seven
years,
we
had
Emmy
who's,
been
working
in
supply
chain
security
for
a
year
and
a
half
at
Red
Hat
coming
in
from
the
outside,
especially
at
tons
of
different
startups
and
really
joining
container
security
craze.
B
A
Yeah
I
think
you
know
I
think
that
it's
it's
really
not
an
issue
about
the
tools
and
the
technology.
You
know
I
think
ACS
excels
at
kind
of
presenting
the
the
new
model
in
a
way
of
that's
that's
familiar
to
most
security
teams,
most
organizations
actually
struggle
with
the
the
devops
culture,
change,
right
and,
and
so
I'm
fauna.
A
I
think
the
best
thing
you
could
do
for
Security
is
to
embrace
that
cloud
native
approach
right
when
you
think
about
everything
as
code
infrastructure
and
applications
and
dependencies
tasks
like
security
and
supply
chain
which
are
related,
but
but
not
the
same,
I
think
end
up
being
a
lot
easier.
Once
you've
got
that
organization
on
board,
you
know
when
I
talk
to
organizations
that
are
considering
that
move.
I
want
them
to
think
about
how
security
can
actually
help
to
promote
those
goals.
A
Right
I
want
this
agility,
the
freedom,
the
flexibility
security
is
often
seen
as
the
the
folks
that
close
the
door
right.
They
say.
No,
they
put
blockers
in
place
can
adopt
these
new
technology.
It's
not
vetted,
but
I.
Think
with
the
right
attitude
you
can.
You
can
actually
help
support
that
organization,
I'm
a
firm
believer
that
moving
to
this
model
of
application,
software
development
is
actually
better
for
security
But.
A
Ultimately,
the
automation,
the
pipelines,
is
a
way
to
get
running
these
applications,
so
when
it's
more
resilient
to
attack
easier
to
remediate
like
honestly,
compared
to
running
something
on
a
virtual
machine
or
in
a
cloud
instance
where
we
work
with
the
traditional
method
of
you
know,
waterfall
and
pushing
releases
like
this
model
is
actually
better
for
security.
I
think
it's
the
ideal
way
to
way
to
go.
Do.
B
You
think
that
the
everything
as
code
helps
so
being
able
to
say:
hey,
here's
a
very
hardened
or
secure
pipeline.
We
have
a
new
team,
that's
getting
onboarded
and
it's
going
to
start
to
use
kubernetes
here.
Why
don't
we
start
with
this
pipeline?
As
an
example,
do
you
think
that
that
helps
the
security
story,
or
is
that.
A
No,
it
definitely
helps
a
security
story.
Right
I.
Think
that
model
that,
like
you,
you
must
declare
all
your
dependencies
and
you
have
to
keep
a
very
broad
perspective
on
what
a
dependency
is
right.
The
more
we
embed
in
that
code,
the
more
the
developers
can,
can
understand
like
that.
They
need
to
make
a
conscious
decision
about
these
settings.
You
need
that
level
of
privilege.
You
have
to
declare
it.
You
need
that
level
of
access
on
the
network.
A
You
have
to
declare
it
and
that
declarative
nature
is
what
allows
us
to
get
at
that
for
for
security
early
on.
You
know
when
you,
when
you're,
giving
teams
access
to
a
platform
like
this,
whether
it's
Cloud
it
could
be
serverless
or
you
know
in
this
case
we're
talking
about
kubernetes
and
containers.
A
You're
actually
handling
a
lot
of
that
decision
making
over
to
those
developers-
and
we
know
you
know,
love
application
development
teams,
but
they
don't
always
make
the
best
security
decisions
right
and
that's
because
of
of
you
know
the
time
is
not
there
to
deliver
on
both
features.
They
have
to
deliver
and
performance
metrics.
A
A
I
think
that
in
all
of
the
methods
and
the
production
environments,
you
could
run
your
applications
in
like
I
mentioned
things
like
serverless.
This
is
that
one
benefit
that
the
limitations,
the
constraints
of
the
the
running
environment
are
expressed
in
that
code
that
we
can
get
at
early
on.
You
know
the
day
that
I
begin
prototyping.
My
application
I
can
go
and
find
out
whether
this
is
going
to
pass
muster
from
from
security
right
I
can
find
out
whether
it's
going
to
meet
my
my
team's.
You
know
trusted
secure
supply
chain
sources.
A
A
Yeah
so
I
mean
the
fact
that
you
have
like
known
sources
coming
in,
or
you
should
right,
we'll
talk
about
that
with
with
supply
chain
like
you
should
know
where
your
sources
are
coming
from
you,
you
get
that
no
blind
spots
right.
You
know
where
everything
is
and
the
automation
that
I
referred
to
right
when
teams
begin
experimenting
with
containers.
A
You
know
you
certainly
can
manually
build
your
container
image
manually,
build
your
deployment,
but
teams
quickly
see
the
need
for
automation
there
and
the
automation
is
what
makes
that
remediation
easier
when
you're
used
to
rebuilding
those
container
images,
5
10
20
times
a
day
and
re-rolling
and
redeploying
them
right.
You
get
used
to
that
operational
excellence
of
devops
of
being
able
to
make
these
quickly
on
the
Fly.
You
can
quickly
resolve
a
dependency
vulnerability
like
that
and
and
push
out
those
changes.
A
Now
that's
an
Ideal
World
and
takes
a
lot
of
steps
to
get
there,
but
organizations
that
have
visibility
in
place
and
automation
can
quickly
link
those
two
things
together
to
say:
okay,
now
that
we
know
about
this
is
in
the
pipeline.
Let's,
let's
start
to
remediate
that
in
that
Pipeline
and
get
these
teams
aware
it's
really
about
helping
a
development
or
any
application
owner
the
Ops
teams
or
others
understand
that
they
they
have
responsibility
for
this,
like
they're
part
of
the
security
story
here
themselves
and
what
they're
bringing
into
the
environment
is
creating
this
risk.
A
And-
and
so
we
talk
about
that
shared
responsibility
of
of
security
teams
and
devops
teams,
because
like
otherwise,
you
get
security,
putting
rules
in
place.
So
the
developers
don't
like
it
breaks
things.
It's
we're
back
to
that
old
style
of
of
invoking
security
controls
out
of
band
from
from
the
platform.
B
Okay,
we're
at
900
next
month
we're
at
800
and
we're
focusing
on
the
ones
with
high
impact
that
are
fixable
right.
So
when
you're
talking
or
educating
a
security
team
on,
let's
say
the
newer
way
of
managing
vulnerabilities,
what
are
some
of
the
the
key
points
that
you
touch
on
with
them
just
in
terms
of
getting
started.
A
Well,
yeah
letting
them
know
about
the
about
the
the
process
right.
The
automation
there
that
it's
more
important
to
have
a
process
where
the
vulnerabilities
are
identified
and
resolved
than
it
is
to
fix
any
one
vulnerability.
You
know
certainly
nightmarish
things
like
log
for
Shell
come
up
all
the
time,
but
I
don't
want
to
treat
that
as
a
special
case.
I
want
that,
to
just
be
the
day
in
day
out,
hey,
there's
a
critical
one
out
there.
It
impacts
our
applications,
there's
a
patch
available
Upstream
from
the
various
vendors.
A
Now
you
have
the
Automation
in
place
that
can
do
that
or
you
can
get
to
a
point
where
it
doesn't
even
require
any
manual
intervention
right.
The
the
exposure
of
this
in
a
common
dependency
really
just
requires
going
back
and
doing
that
rebuild
redeploy
instead
of
thinking
about
you
know
like
like
in
traditional
world
like
rebooting,
a
virtual
machine
that
hosts
one
of
your
application
components
can
be
pretty
disruptive
right.
You
might
have
to
have
load,
balancers
shift
the
load
away
from
that
particular
component.
A
You
know
in
kubernetes
that's
kind
of
a
matter
of
course
right
that
that
you
know
restarts
and
things
are
really
non-events
and-
and
you
should
embrace
that
we
talk
about
that-
also
embracing
the
the
limitations
of
the
of
the
perceived
limitations
of
the
platform.
So
security
teams
are
often
thinking
about
containers
on
kubernetes.
It's
just
another.
You
know
mini
virtual
machine,
but
there's
a
couple
things
that
we
could
demonstrate
to
show
them.
B
I
think
there
are
new
I
would
say
techniques
to
be
able
to
mitigate
different
issues.
Maybe
you
can't
patch
a
vulnerability
right
away
that
day,
but
you
could
change
the
configuration
or
move
a
workload
out
of
a
namespace
or
something
like
that
right,
like
there's
other
kubernetes
controls
that
can
mitigate
a
critical
or
important
vulnerability
right.
Absolutely.
A
Right,
that's
right,
and
this
is
my
favorite
topic,
and
it
is
honestly
what
stack
rocks
was
founded
to
point
out
was
that
this
is
a
different
world
and
that
that
you
can
mitigate
the
the
possibility
of
an
attack.
You
can
put
a
stop
to
most
classes
of
application
attacks
by
making
use
of
the
features
that
are
part
of
the
platform
right
by
embracing
the
nature
of
it.
You
know
when
you're
running
an
application
component
in
a
container.
You
know
that
thing's
not
supposed
to
live
an
interesting
life.
A
It's
got
one
job
right,
it
accepts
connections
from
other
pods,
or
maybe
it's
running
some
long-running
compute
process
or
whatever,
but
it
doesn't
have
the
general
need.
It
doesn't
need
to
reach
out
to
go
and
get
you
know
patch
up,
updates
from
from
red
hat
or
from
Microsoft.
It
doesn't
need
to
contact.
You
know
all
these
other
services
within
your
environment.
A
It's
got
a
very
small
world
and
a
very
boring
world,
and
we
can
use
that
both
to
identify
the
non-boring
right
by
as
a
signal
that
there's
a
potentially
a
threat
here,
but
we
can
use
the
rules
and
kubernetes
to
enforce
boring
right.
There's
no
reason
for
a
container
to
write
to
the
local
root
file
system.
It's
not
a
virtual
machine.
You
shouldn't
be
logging
anything
important
there
because
that's
going
to
disappear
on
you.
A
So
if
you,
if
you're
depending
on
that
thing,
you're
you're
making
a
mistake
already,
but
the
the
technique
of
dumping
a
payload
to
disk
and
then
executing
it
is
a
pretty
common
chain
in
attacks.
So
I
get
your
application.
I
find
a
weakness
that
allows
a
remote
code,
exploit
boom
I'm
using
curl
to
download
a
crypto,
Miner
and-
and
you
know
then
run
it.
A
A
It
has
one
thing
it
can
do
so:
Network
policies
with
egress
rules
that
severely
restrict
where
it
can
get
to
can
help
to
interrupt
that
and
then,
of
course,
making
all
your
file
systems
read
only
except
for
where
you
need
to
persist
data
again,
we
can
look
at
that
in
a
declarative
way.
I
can
tell
you
whether
your
file
system
is
read,
write
because
if
you've
left
the
default
or
you've
actually
said,
I
want
to
read
rewrite
file
system,
but
we
can
check
that
and
say
nope.
This
is
a
setting.
A
You
need
to
change
right,
and
rather
than
do
it
for
you,
of
course,
we
don't
want
to
just
change
that
on
somebody,
because
that
breaks
applications
if
I
make
your
file
system
read
only
boom,
your
containers
are
crashing.
So
what
we
do
is
push
back
and
try
to
nudge
teams
to
use
features
like
that.
But
that's
where
that
collected
set
of
things
can
make
your
applications
more
resilient
to
to
attack
just
by
turning
on
the
options
that
are
commonly
available
in
the
platform.
B
Yeah
I
had
a
question
about
malware,
specifically
and
ACS
and
kubernetes,
and
you
kind
of
touched
on
it.
I
think
best
practice
is
just
to
avoid
writing
to
nodes
in
general
that
also
limits
that
capability
I
want
to
I'm
gonna
pass
off
to
Kim,
because
I'm
not
asking
you
way
too
many
questions,
but
before
that
Dwayne
Branch
had
a
comment
asking
about
zero
trust,
a
best
practice
or
an
evolving
practice.
B
A
Yeah
I
think
it's
it's
at
this
point
that
that
zero
trust
covers
this
basket
of
techniques
that
we
can
use
here.
Some
of
the
majority
referred
to
right
like,
even
though
your
kubernetes
applications
are
all
running
in
the
same
cluster,
there's
no
reason
for
them
to
trust
each
other
and
you
shouldn't
allow,
which
is,
unfortunately,
the
default.
It's
allowed
this
wide
open
communication
within
the
cluster
right
that
there's
no
reason
to
believe
that
you
know
another
namespace
or
another.
Pod
is
necessarily
a
legitimate.
A
You
know
legitimate
functioning
application
in
your
environment
and
being
able
to
you
know
to
distrust
that
and
just
by
default,
treat
it
as
potentially
hostile.
It's
a
it's
an
opt-in
kind
of
model
right
that,
if,
if
security
is
all
about
looking
for
the
bad
from
the
good
right
and
and
in
the
virtual
machine
we've
got,
you
know
antivirus
engines
and
malware
engines
and
authentication
to
look
for
things
like
hey.
This
isn't
authenticated.
A
This
is
running
something
that
we
don't
know
and
then,
of
course,
the
attackers
are
trying
to
avoid
those
rules
here.
What
we're
doing
doing
is
trying
to
reduce
the
noise
right
that
we
know.
What's
good,
and
so
if
these
five
things
are
running,
that's
good.
If
the
sixth
thing
is
running,
that's
not
good.
B
And
so
I
give
one
last
thing:
I
want
to
put
it
before:
I
hit
it
off
to
you
and
in
ACS,
when
those
things
do
get
flagged
or
stocks.
When
those
get
flagged,
you
can
create
policy
exceptions
right
or
violation
exceptions
and
that
way,
you're
putting
the
notes
down
specifically
that
you're,
seeing
it
you're
aware
of
it
and
you're
understanding
the
risk
I
think
that
yeah.
A
Yeah,
we've
always
taken
this
attitude
to
get
to
the
ideal
that
we've
been
describing
takes
a
while
it
takes,
you
know,
evolving
the
organization's
culture.
It
takes
the
tuning,
the
controls.
Acs
would
be.
You
know
no
good
to
anybody
if
you
turned
it
on.
You
had
to
function
in
this
way.
Perfect.
All
the
time
I
I
like
to
point
out
that
getting
better
at
security
over
time
is
a
good
thing.
A
You
don't
have
to
solve
all
the
problems
at
once,
I
mean
you
can't
right,
there's,
there's
constraints
in
time
and
money
and
expertise
so
getting
started
means
that
you,
you
pick
a
use
case.
You
pick
a
small
environment
and
those
exceptions
play
into
that.
You
can
actually
make
exceptions
and
you
can
make
inclusions
right.
You
can
start
with
a
small
use
case
once
that's
successful
roll
that
out
as
a
pattern
across
the
organization
and,
of
course
you
know
not
everything's
perfect.
Some
of
your
applications
are
going
to
act.
A
A
little
funky,
they're,
gonna,
they're
gonna,
throw
up
those
signals
that
say:
hey,
there's
a
threat
here.
Well,
it
turns
out.
You
know
someone
with
domain
expertise.
There
is
going
to
say:
well,
it's
not
really
right,
it's
it's
something
that
we
have
to
live
with
today.
I
think
that
security,
that
you
know
doesn't
take
exceptions
into
account,
just
ends
up
getting
turned
off
right,
it's
noisy
it.
It
makes
a
mess
and
then
nobody
uses
it
because
you
can't
you
can't
get
around
the
rules
in
it.
So
try
to
avoid
that
with
the
stack
rocks.
C
C
A
Absolutely
so
risk
is
one
of
those
things
a
little
bit
nebulous,
but
there's
a
lot
of
things
that
have
to
be
managed
through
risk
and
deciding
what's
acceptable
versus
unacceptable
is
very
sensitive
on
the
context
right.
What
I
accept
for
you
know,
for
my
you
know,
less
important
applications
versus
my
credit
card
payment
or
Health
Care
handling
applications
is
going
to
be
different
and
it's
going
to
change
over
time
and
and
actually
risk
might
be
dependent
on
circumstances
that
are
outside
of
my
control.
A
Right
situation
on
the
internet
active
exploits
suddenly
that
thing
that
I
was
less
worried
about
before
now
becomes
a
much
much
higher
risk
and
so
being
able
to.
You
know
to
like
to
be
able
to
make
that
change
over
time
and
have
a
tool
that
can
actually
help
you
understand
that
risk
and
as
it
changes
over
time,
what
I
love
is
too
is
with
ACS
is
that
customers
can
provide
that
input
into
that
risk
model
right,
unfortunately,
very
few
do
but
like
they
know
things
about
their
applications.
A
They
know
which
one
is
making
the
organization
loads
and
loads
of
Revenue
and
over
here,
which
one
is
subject
to
government
Regulatory
Compliance
and
that's
risk
information
that
you
can
express
through
through
kubernetes
standards
in
a
declarative
way.
And
then
the
risk
reaction
of
a
tool
like
ACS
can
can
reflect
that
so
cool
stuff.
Well,.
C
So
I
think
kind
of
going
back
into
the
idea
of
you
know
hardening
security
and
we
did
touch
on
Sig's
store
and
even
you
know
us
having
that.
Having
that
day,
zero
eight
Koo
con
I
wanted
to
know.
If
you
could
talk
a
little
bit
more
about
that,
you
know.
How
are
we,
as
red
hat,
have
we
kind
of
been
involved
in
there
as
much
as
you
can
much?
A
Right
good
question,
and
yes,
there's
others
that
know
I
think
more
about
red
Hat's
involvement
with
Sig
store,
I
mean
the
the
goal
of
the
project
is,
is
pretty
Grand
when
you
think
about
it
right
about
improving
the
Trust
In
open
source
software?
To
avoid
some
of
these
nightmare
scenarios,
where
you
know
someone
hijacks
an
npm
package,
name
space
right,
someone
ends
up
injecting
into
a
broad
range
of
of
projects
out
there
from
these
these
dependencies
and,
of
course,
cryptographic
verification,
always
always
a
good
thing.
A
A
A
One
of
those
things
could
be
the
contents
of
the
image
and
a
signature
do
I
trust
the
source
of
this
and
so
ACS
acts
as
that
enforce
point-
and
you
know
what
I
like
about
it-
is
that
it's
it's
pushback,
it
is,
you
know,
stopping
a
developer
from
advancing
something
that
is
not
meeting
the
requirements,
but
it's
not
in
a
very
straightforward
way.
It's
a
fail,
fast
kind
of
model
fail,
clean
right,
I
know
what
happened.
A
I,
don't
need
fancy
tools
or
to
go
to
another
dashboard
to
go,
look
and
see
what
happens
sitting
there
right
in
front
of
me.
Okay,
it's
not
signed
by
a
trusted
Authority.
How
do
I
get
that
signed?
I
have
to
go
look
into
my
process.
I
have
to
go
enroll
this
and
make
sure
it's
passing
through
my
my
verified
supply
chain
process
in
order
to
get
vetted
in
order
to
run
it.
A
B
A
Right
so
you're
not
going
to
catch
me,
arguing
against
supply
chain
measures
right
and
we've
seen
the
impact
of
things
like
the
solar
winds,
breach.
That
was
clearly
a
supply
chain
problem.
I.
Think
that
we're
we're
getting
well
prepared
against.
You
know
this
type
of
thing.
Are
we
seeing
the
threats
we've
seen
the
the
potential
so
I'm
not
going
to
argue
that
this
is
a
bad
thing.
A
That
means
secure
right-
and
we
know
that
that's
just
not
the
case
also
is
the
kind
of
perception
that
something
that
does
pass
all
my
checks
remains
that
way
forever
right
that
once
I've
got
that
image
signed
and
then
I've
got
that
deployment
running,
that
things
are
good,
but
we
know,
of
course,
that's
also
not
true
right.
Five
minutes
after
I
build
my
perfectly
vulnerability,
free
container
image.
There's
another
Discovery,
maybe
there's
a
new
exploit
in
the
wild
like
I,
said,
there's
other
configuration
that
gets
dated
right.
A
People
still
use
things
like
RSA
keys
and
they're
quickly,
going
out
of
fashion,
or
you
know,
or
hash
algorithms
that
are
no
longer
considered
secure
and
so
rooting
all
of
that
out
is
is
a
continual
problem.
Things
time
is
not
kind
to
security
of
your
applications.
Yeah
there's
also
that
other
perception
that
I
think
I
see
with
this
stuff.
There's
a
focus
on
container
contents
right.
A
I
know
that
that
software
building
materials
is
focused
on
this,
but
that's
also
this
misperception
that
the
security
of
your
application
is
entirely
dependent
on
the
contents
of
the
container
image,
and
it's
also
not
the
case
right.
I
can
take
a
same
container
image
and
run
it
in
two
different
kubernetes
deployment
configurations
and
have
wildly
different.
A
You
know
security
results
right,
I
can
expose
one
on
the
network.
I
can
give
it
a
service
account
for
Kube
that
has
cluster
admin
privileges
like
I'm,
just
asking
for
trouble
with
that
configuration
and
that's
that's
again.
The
point
that
we
were
making
at
stack
rocks
was
that
security
was
so
much
more
than
just
when
it
went
into
the
Container
image
right.
So
we're
going
to
continue
to
play
that
role
here.
Of
that
little
nagging
reminder
that
there's
always
more,
you
could
be
doing
and
there's
more.
B
Yeah
one
of
the
interesting
I
guess
add-ons
to
secure
to
spot
chain
security
that
I've
seen
are
you
know
you
see
things
like
Acorn
or
different
types
of
Dev,
tooling,
that
package
the
configuration
with
the
application
so
I'm
curious.
We
talked
about
about
container
image
signing
what
about
developers
if
they
create,
like,
let's
say
their
Network
policy
at
the
beginning,
along
with
their
deployment
yamls
and
their
services,
can
they
package
all
that
up
as
part
of
an
artifact
and
do
you
think
we
can
scan
that
at
in
the
cluster
as
well?
A
Yeah
and
yeah
and
ACS
supports
that
kind
of
model
where
you
know
once
something
is
vetted
and,
and
it
passes
that
check
like
the
the
change
that
you
mentioned.
The
container
image
is
something
that,
because
of
the
way
I'm
going
to
have
to
declare
it
I'm,
either
going
to
apply
a
diff.
You
know
I'm
going
to
apply
that
that
incremental
change,
that's
something
that
would
be
visible
to
ACR.
A
So
you
again,
you
would
know
about
it
before
it
got
deployed
and
again
you
would
know
why
it
didn't
work
if
you
just
simply
set
that
image
attribute
to
change
that
container
image
source
left
everything
else
the
same
unless
the
new
container
image
meets
the
requirements
set
by
the
security
team.
Acs
would
would
reject
that
change
so,
rather
than
you
know,
fully
tearing
everything
down
and
redeploying
it
you'd
see
that
that
model
would
work
here
as
well.
A
When
it
comes
to
things
you
mentioned
Network
policies-
and
you
know
there
is
some
more
coming
up
on
ACS
you've
talked
about
that
a
little
bit.
We're
gonna
have
some
demos
at
kubecon
that
I
think
really
improve
and
kind
of
set
a
you
know
set
a
pattern
for
how
customers
can
be
successful
with
things
like
that,
where
Network
policies
are
one
of
those
things
it
takes
domain
knowledge
about
your
application
to
understand,
you
know,
is
this
right?
Is
it
not
right?
A
Does
it
allow
the
connectivity
that
I
need
how
do
I
troubleshoot
that
so
shifting
that
further
left
here
right
being
able
to
check
that
ahead
of
time
is
going
to
make
it
easier?
I
think
the
right
thing,
of
course,
is
is
that
changes
should
be
leveraging
the
source
code
control
control
process
that
you
have
right
if
I
open
up
a
network
policy,
because
I
need
to
talk
to
the
pod,
that's
a
you
know,
that's
a
source
code
change
that
should
go
through
it.
A
You
know
pull
requests,
Change
review
process
and,
ultimately,
that's
how
change
management
for
security
should
be
done
in
these
environments.
I
want
to
turn
the
security
operations
people
into
source
code.
You
know
PR
reviewers,
right,
yeah
I
want
them
to
have
that
input
to
say
no
we're
not
giving
you.
You
know
open
access
to
Port
80
outbound,
like
that's
crazy.
You
know,
restrict
this
right.
A
So
there's
a
human
component
to
that
too.
But
the
tools
that
we're
bringing
in
are
really
neat
and
being
able
to
give
you
suggestions
and
to
test
those
changes
against
the
security
requirements
before
you
go
and
apply
them
or
modify
them.
So
you
know
we're
trying
to
strike
this
balance
between
keeping
everybody
flexible
right
like
hey.
You
want
to
use
that
like
I'd
love
it
you
want
to
go
out
and
experiment
with
that
new
memory.
A
Cache
technology
like
by
all
means,
but
don't
bring
in
this
unmaintained
vulnerable
mess
and
leave
it
wide
open
in
my
environment,
so
the
security
team
gets
to
save
you
know,
what's
what's
insane
and
what's
saying
right,
what's
what's
acceptable
and
what's
not
acceptable,
the
the
key
is
early
feedback
right,
I
want
to
know
the
instant
I
go
out
and
find
that
project.
Whether
or
not
it's
going
to
fly
in
my
Farm.
B
Yeah
and
that's
MP
guard
specific
project
which
I
actually
know
a
lot
about
so
Chris
yeah.
You
touched
on
it,
I'll
be
talking
about
it
next
week.
One
of
the
huge
advantages
is
the
developer
can
check
it
against
created
system
policies
so
that
that
all
happens
asynchronously
without
even
Communications
between
the
teams.
If
I
go
and
try
to
create
or
open
port
80
with
a
network
policy,
it's
going
to
automatically
get
shut
down
because
ACS
has
a
policy
that
says
hey.
B
You
know
you
can't
use
this
policy
or
you
can't
use
this
network
port
and
so
developer.
Just
gets
shut
down
right
away.
There's
no
back
and
forth!
There's
no
hey
I
check
this
into
GitHub.
Can
you
take
a
look
at
my
deployments
and
then
security
team
comes
in
shuts
it
down
to
me.
That's
the
biggest
advantage
and
I
know
that
developers
don't
necessarily
like
working
with
network
policies
too.
So
to
have
that
to
have
that
automated
in
a
way
that
they
could
check
it
in
or
test
it
before
they
go
and
reach
out.
A
Absolutely
and
the
key
is
like
again
I
know:
I
said
this
all
the
time
when
I
talk
to
customers,
we
know
that
developers
don't
like
security
products.
They
don't
want
to
have
to
deal
with
that,
but
in
in
the
old
days,
if
you
ever
sat
at
a
workstation
or
you're
working
on
an
application
server
and
there's
a
firewall
somewhere,
some
Network
device,
that's
interfering
with
your
communication,
it's
so
frustrating
to
find
out
where
that
is
why
that's
in
place?
Who
owns
that?
How
to
get
it
changed
right.
It's
a
black
hole!
Your
packets
disappear.
A
So
in
this
case,
as
a
developer,
if
I
have
to
deal
with
this
stuff,
I
want
it
in
network
policies
that
are
in
yaml
that
I
can
read
and
I
want
it
running.
You
know
when
I'm
running
on
Mini
shift
on
a
you
know
in
a
test
environment
right,
I
want
this
front
and
center
part
of
my
application.
So
as
I
go
through.
My
automated
testing
and
I
hit
a
roadblock
I
know
why
it
is
there
and
what
the
problem
is
and
get
it
fixed.
It's
all
about
solving
those
problems.
A
B
I
think
there's
one
more
model
there
too,
which
is
operations
team,
can
use
this
automated
function
to
go
into
the
different,
the
different
repositories,
let's
say,
and
pull
out
deployment
information
and
then
create
PRS
against
developers.
Existing
applications
right,
so
I
can
go
in
and
automatically
generate
a
network
policy
for
you.
The
developer
doesn't
even
have
to
touch
it,
and
then
you
know
we
can
move
forward
and
I
can
make
sure
that
hey.
Okay,
all
of
my
different
organizations
are
properly
segmented
in
kubernetes.
B
They
have
correct
Network
policies
according
to
policy
according
to
ACS
and
the
policy
generator
we've
set
up.
You
know
it
doesn't
necessarily
need
to
be
another
CLI
the
developer
uses.
It
can
also
be
something
that
the
different
teams
can
use
to
check
in
with
the
developers.
So
I
think
it's
that
flexibility
in
an
automated
fashion
and
not
through
a
UI
something
that's
can
be
deployed
in
a
pipeline
that
can
break
a
pipeline
as
well
right
yeah.
It's.
A
That's
what
I'm
really
excited
about,
because
the
you
know
you
know:
we've
had
these
type
of
features.
These
suggestion
features
in
ACS
for
a
long
time
was
one
of
the
first
really
cool,
Innovative,
kubernetes
native
things
that
we
did,
but
it
has
had
that
challenge
of
operational.
How
do
I
use
this
this
feature
right?
Do
I,
have
to
wait
until
something's
running
to
see
traffic
before
I
can
build
rules
around
that
traffic
and
and
this
upcoming
capability
is
going
to
help
to
make
that
a
lot
easier,
so
yeah
I'm
very
excited
to
see
it.
A
B
And
if
anybody's,
in
the
slack
Channel
at
the
stack
rocks
channel
in
the
cncf
workspace,
we
do
have
a
lot
of
PMS
Chris.
Is
there
some
existing
existing
essays
and
stack
rocks?
Employees
are
in
that
chat
as
well?
So
if
you
have
any
questions
or
feedback,
we'd
love
to
hear
it
from
you,
especially
when
it
comes
to
network
policies
and
doing
that
in
an
organization.
That's
always
a
very
cool
use
case.
C
Cool
yeah,
so
I
hear
Chris
that
you
may
have
a
hot
take,
no
I'm
more
about
the
idea
of
supply
chain
security
efforts
and
kind
of
what
that
means.
I
know
you
were
like
I
think
I'll
talk
a
little
bit
more
about
that.
You
know.
I've
heard
it
described
on.
One
of
our
last
episode
is
sort
of
the
idea
of
the
trusted.
B
C
A
I
mean
you
know:
I
I
get
asked
about
this
a
lot
we
talk
about
it
and
I
think
the
problem
is
actually
that
word
secure
being
in
that
secure
supply
chain
right
that
it
implies
something.
That's
not
really
there
don't
put.
You
know
too
much
too
much
into
that
wording,
but
I
think
it.
We've
talked
about
this
I
think
the
The
Trusted
supply
chain
is
certainly
a
thing
there,
so
totally
I
believe
that's
necessary,
but
I
don't
want
people
to
think
that
suddenly,
the
days
of
you
know,
security
oversight
are
done
once
we
have.
A
This
problem
solved
right.
The
landscape
changes
too
quickly,
they're
they're.
Still,
of
course,
you
know
Regulatory
and
Industry
compliance
standards
that
sure
they
might
adopt
new
recommendations
now,
especially
from
the
US
federal
government,
around
trusted
supply
chain,
but
you
know
for
most
organizations
I'm,
not
even
sure,
that's
still
the
biggest
risk
right.
We
see
that
that
you
know
most
of
the
active
threats
against
applications
out.
There
are
exactly
what
you'd
expect
automated
systems
probing
for
for
known
software
and
known
weaknesses.
A
All
you
do
to
do
is
run
a
little
Honeypot
Network
for
a
while
and
you'll
watch.
These
folks
come
into
your
front
door.
It's
all
automated!
It's
all
botnets
on
on.
You
know:
Broadband
networks
out
there,
just
probing
looking
for
these
things
so
sure
so
solve
the
supply
chain.
Problem
I
think
the
first
part
of
that
is
understanding
it,
which
ACS
can
help
you
with
where's
this
stuff.
Coming
from
where
my
developers
getting
their
things
from
when
are
they
updating
it?
A
A
I
think
that
some
of
the
Technologies
in
here
really
interesting,
like
software
building
materials,
I'm
still
wondering
what
are
we
going
to
do
with
this?
What
do
we
you
know?
Is
it
just
to
provide
somebody
with
a
spreadsheet
and
who's
going
to
look
at
that
right
if
I
have
a
bill
of
materials
for
my
applications
like
a
lot
of
things
in
technology
and
especially
in
security
and
in
compliance,
I?
Think
it's
going
to
come
down
to
knowing
who
to
blame
right
when
an
incident
does
occur,
come
on.
B
A
Did
this
threat
come
from?
Oh
it
was
this
unpatched
vulnerability
who
owned
that
application.
What
didn't
patch
it
there?
They
are.
Let's
find
the
person
that
we
can
blame
for
this
I
mean
all
joking
aside,
like
understanding
who
owns
a
particular
component
is
an
important
thing
like
who's
responsible
for
that
make
that
clear,
I
think
even
developers
that
build
apps
that
build
their
own
containers,
don't
realize
that
they
are
responsible,
there's
an
implication
there.
That's
not
really
it's
never
explicit
to
them
that
hey
you
bring
in
that
log
for
Jay
Library.
A
B
I
think
that's
one
of
the
challenges
with
s-bombs
in
general
is
one
changes
depending
on
the
language
that
you're
using
there's
also
who
is
maintaining
and
updating
this
right?
Is
it
developers,
maybe
it's
an
open
source
project
where
there's
two
developers
on
it,
so
it's
not
completely
accurate
or
up
to
date,
so
it
has
to
be
some
sort
of
verification
of
who's.
Actually
managing
this
and
updating
the
bill
of
materials.
B
It
becomes
again
a
whole
pointing
finger
game,
and
so
just
because
there's
a
manifest
saying,
the
listed
ingredients
are
X,
so
it
doesn't
necessarily
mean
it's
accurate
or
up
to
a
specific
standard
and
so
you're.
Seeing
a
lot
of
companies
come
out
and
say
you
know,
we'll
verify
these
500
packages
or
these
500
sources
right
and
again,
I
think
it's
just
going
to
be
continuously
a
challenge
over
the
next
Maybe
I,
don't
know,
I'd
say
for
a
while
now,
what's
in
its
infancy,
right
yeah.
A
One
of
my
favorite
tricks:
you
know
if
you're
an
app
developer,
you're
a
devops
you're
involved
in
the
creation
of
the
maintenance
of
these
applications.
You
can
save
yourself
a
lot
of
trouble
right
with
vulnerabilities
with
things
like
s-bomb
and
supply
chain
problems
that
are
going
to
come
onto
your
desk,
whether
you
want
them
to
or
Not
by
eliminating
as
much
of
that
stuff
as
possible.
A
Right
Red
Hat
produces
a
set
of
minimal
base
images
that
you
can
build
on
top
of
you
just
don't
need
all
that
stuff
and
if
you're
not
using
it
well,
the
security
perspective
is.
Why
would
you
give
an
attack
or
access
to
that?
If
you
don't
use
it,
you
don't
need
it,
but
from
a
day-to-day
work,
why
do
you
want
to
maintain
and
patch
that
right,
the
best
way
to
handle
vulnerabilities
in
a
given
component?
That's
in
your
your
container
image
is
not
to
have
it
there
at
all.
A
Why
would
you
want
to
maintain
and
deal
with
that
right?
Build
smaller
images
and
ACS
tries
to
carve
this
out
by
showing
you
here's
some
really
dangerous
stuff.
It's
what
we
call
components
that
are
useful
for
an
attacker
right
and
then
there's
stuff
in
there
that
you
know
teams
don't
like
to
get
rid
of
like
curl
and
stuff,
but
even
even
a
shell
like
bash,
like
what
do
you
need
a
user
interactive
shell
for
right?
A
B
B
Sorry
and
I
think
you
know
I
think
that's
spot
on.
It's
just
here's
the
way
that
you're
running
it,
you
kind
of
bundle
it
all
in
one
and
then
as
organizations
grow
and
they
realize
they
have
these
kubernetes
native
controls.
Yeah
again,
a
lot
of
your
applications
become
less
and
less
vulnerable
over
time,
and
so
it's
just
pointing
that
out,
saying:
hey,
there's
an
alternative,
but
if
you're
used
to
working
in
Virtual
machines,
where
you
put
everything
in
there,
you
know
it's,
it's
just
a
slightly
different
workload.
C
A
There's
some
cool
stuff
coming
I'm,
looking
forward
to
the
announcements
that
are
going
to
come
out
at
kubecon,
we'd
love
everyone
to
participate
in
this
stuff,
the
the
network
policy.
The
shift
left
thing
that
we
talked
about
is
available
to
develop
a
preview.
If
you
want
to
kick
the
tires
on
that,
do
reach
out
to
us
on
slack
and
yeah,
looking
forward
to
collaborating
some
great
stuff,
great
stuff
being
planned
for
for
next
year,
so
stay
tuned.
B
Yeah
definitely
and
again,
all
those
are
going
to
be
recorded
and
online,
so
I'm,
hoping
to
post
them
in
the
stack
rocks
channel
in
the
cncf
if
you're
interested
otherwise
until
next
month.
The
third
Tuesday
of
every
month
at
2PM
will
be
here.
This
secured
cloudcast,
I'm,
Mike,
Foster
and
Kim
I'll
give
you
the
final
word
on
the
sign
off
all.