►
Description
How does Red Hat Advanced Cluster Security integrate with GitOps? In this episode, we are joined by Michael Foster, Technical Marketing Manager from the ACS team. We will be talking about how ACS fits into the GitOps workflows. We'll also talk about Application Delivery Supply Chain, and take a look at ACS in action. So join us to learn more about how Advanced Cluster Security can help us with more secure GitOps practices.
Follow us:
Christian Hernandez https://twitter.com/christianh814
Chris Short https://twitter.com/ChrisShort
Michael Foster https://twitter.com/IdealUsrname
What is GitOps Guide to the Galaxy?
Every other Thursday at 3pm ET hosts Christian Hernandez and Chris Short sit down to discuss everything in the GitOps universe, from end-to-end CICD pipelines to creating Git workflows.
Subscribe to Red Hat's YouTube channel: https://www.youtube.com/redhat/?sub_confirmation=1
About OpenShift:
Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.
Openshift.com https://red.ht/33Fh6uV
OpenShift on github https://github.com/openshift/
OpenShift on redhat.com https://red.ht/2o4ccDk
#RedHat #GitOps #Kubernetes
B
A
B
A
C
Yeah
thanks
for
the
intro,
hey
everyone,
I'm
mike
foster
on
the
acs
team.
Formerly
stackrocks,
we
came
over
april.
I
think,
was
the
official
date
that
we
moved
over.
So
it's
been
a
fun
six
months
so
far,
and
thanks
for
for
getting
me
on
the
show,
I've
been
around
kubernetes
for
four-ish
years
now
and
yeah.
I
have
a
diverse
background
used
to
play
baseball
and
I
went
to
school
in
northeastern
boston.
So
yeah
thanks
for
having
me.
B
Yeah
yeah,
I
know
it's
great
yeah,
it's
great,
I
was
you
know
going
through
this.
It's
actually
been
been
a
while.
I
invited
him
on
the
on
the
show,
but
since
we
had
so
many
we
did
a
show
planner
we
had
so
many
shows
that
was
like
okay.
Well,
you
can
come
in
october.
This
was
back.
You
know,
you
know
closer
to
the
acquisition
than
anything
I
was
trying
to
get
trying
to
get.
You
know
the
guys
from
stack
rocks
on,
but
very
happy
to
be
here.
B
Even
after
you've,
you
know,
deployed
your
your
application
and
that
that
being
part
of
the
whole,
you
know
speaking
of
supply
chain
right
right
talking
about
the
application
supply
chain,
so
so
yeah,
I'm
gonna,
I'm
gonna
shut
up
for
a
little
bit.
Let
let
mike
over
here
take
over
a
little
bit
talk
about
talk
about
acs
right.
Talk
about
stack,
rocks,
talk
about
acs,
talk
about
the
whole
ecosystem.
C
Yeah,
you
nailed
it,
especially
the
devsecops
word
that
buzzword
that
you
keep
hearing.
It's
really
it's
about
breaking
that
down,
because
it's
so
high
level.
Nobody
really
knows
how
to
actually
apply
that,
and
so
just
wanna
show
you
some
practical
examples.
Hopefully
you
can
apply
it
to
your
use
cases
and
when
I
share
my
screen,
I'm
going
to
take
you
through
just
a
couple
slides.
I
won't
bore
you
everything
showing
up:
okay,
right,
everything's,
clear.
C
C
Yeah,
so
the
vision
of
stack
rocks
and
acs
now
is
to
enable
organizations
securely
build,
deploy
and
run
cloud
native
applications
everywhere
and
earlier
in
2017.
Stackrocks
was
a
more
container-focused
security
service
and
you'll,
hear
cloud
platforms
and
container
focused
platforms
that
are
out
there,
but
we
really
pivoted
to
kubernetes,
and
it's
because
kubernetes
has
a
specific
challenge
that
it
presents
to
developers
and
operation
teams.
That
is
slightly
different
from
let's
say,
a
serverless
process.
C
There
are
a
whole
array
of
configurations
with
kubernetes
that
are
challenges
and
if
you
want
to
deploy
at
the
speed
at
which
the
developers
can
introduce
functionality
into
your
applications,
you
need
a
security
process
that
can
keep
up
with
that.
So
it's
about
securing
the
supply
chain,
securing
the
infrastructure
and
making
sure
that
your
workloads
that
that
that
process
fits
in
with
the
developers
and
the
containerization
techniques
that
you
have
so
that
you
can
securely
scale
and
I'm
not
going
to
go
too
much
into
these
slides.
C
But
it's
just
about
delivering
continuous
security
and
fitting
into
the
process
that
you
have
right,
because,
if
you've
adopted
kubernetes
in
any
sense
taking
a
security
solution
like
acs,
you
might
be
hey
like.
How
are
we
going
to
implement
this?
So
we'll
show
you
and
really
it's
about
just
full
life
cycle
security
of
the
things
that
you
have
to
take
care
of
which
cloud
platforms,
kind
of
leave
up
to
you
in
a
shared
responsibility
model
you'll
see
on
the
different
providers
that
are
out
there.
B
B
You
know
what,
when
you
say,
application
supply
chain
that
it's
it's
really
nice
to
have
an
analogy
right
and
that's
like
the
analogy
of
like
you
know,
you're
talking
about
the
assembly
line,
how
there's
no
like
dev
assembly
line
right,
like
the
you
know
like
if
you
think
about
like
henry
ford
and
like
building
a
car
like
building
a
car,
the
assembly
line,
they
don't
there's
no
like
dev
version
of
that
somewhere.
Maybe
r
d
is
the
dev
version.
B
Who
knows
but,
like
you
know
like
there
is
no
devs
qa,
like
all
that
happens
in
that
in
that
same
supply
chain
right.
So
in
that,
in
that
same,
it's
all
that
same
process
like
it
shouldn't
have
to
be
an
afterthought.
It
shouldn't
have
to
be
something
you
do
on
the
side
right.
It
needs
to
be
all
inclusive,
so.
C
C
And
then,
just
in
terms
of
the
layers
for
red
hat
you'll
see
that
advanced
security
and
management
are
sort
of
that
top
layer.
That
you'll
see
because,
like
a
lot
of
platforms,
really
kind
of
only
only
give
you
the
kubernetes
specific
part
of
that
right.
So
how
do
you
grow
and
scale
your
cluster?
Then?
How
do
you
secure
your
own
applications?
That's
something
that
a
lot
of
you're
gonna
normally
need
to
go
to
an
extra
service
unless
you
have
bought
into
the
specific
cloud
provider,
but
that's
enough
slides.
A
B
B
C
C
C
C
Have
a
couple
applications
installed
on
here.
I
think
I
was
actually
given
some
pretty
insecure
ones
and
I
haven't
seen
them
yet
so
interested
to
see
what
pops
up
now.
This
is
just
the
main
dashboard
which
I
should
probably
zoom
in
on
again
to
200,
so
everybody
could
see,
and
we
only
have
one
cluster
if
you
had
multiple
clusters.
Obviously
this
would
show
up
here
you'll
see,
system
violations,
compliance
standards,
it's
your
clusters
at
a
glance
dashboard
and
just.
B
A
B
Right
like
what
was
supposed
to
show
you
how
how
how
the
how
kubernetes
the
whole
ecosystem
has
has
evolved
like
now,
we
can
do
things
like
this.
It's
like
oh
man,
things
as
common
as
someone
accessing
something
getting
an
alert
now
seems
like.
Oh
that's,
really
cool
it.
You
would
think
that
would
seem
like
intuitive
that
you
would
have
in
the
platform,
but
sure
maybe
not,
but
well
I
mean
kubernetes
was
so
young
back
then
right.
It's
like
now
we're
we're
at
that
point.
B
C
Yeah,
that's
it
there's,
like
cube,
exact,
really
commands
that
show
that
either
somebody's
in
production
or
somebody's
in
your
developer,
like
trying
to
access
secrets
or
trying
to
get
into
a
container.
Those
are
things
you
want
to
alert
on,
which
is
why
the
severity
is
high
and
obviously
it's
not
enforced
right
now,
so
by
default,
acs
doesn't
enforce
anything
because
you
have
to
go
and
install
an
admission
controller
to
do
that,
and
there
are.
C
There
is
security
aspects
of
doing
that
as
well
right
there.
It's
actually
part
of
the
miter
attack
framework
of
exploiting
admission
controllers,
specifically
mutating
ones
right.
So
it's
your
choice,
whether
you
want
to
do
that
and
then
how
you're
going
to
enforce
it.
You
need
to
make
sure
that
you
are
aware
of
that
as
well.
So,
just
by
default,
it's
hey
come
in.
Take
a
look
around
understand
where
your
high
risk
deployments
are
and
go
from
there.
C
I
forget,
but
let's
say
there's
specific
categories
or
a
specific
policy:
it
doesn't
have
to
be
high,
so
you
can
create
and
edit
things,
if
you
let's
say
you
disagree
with
the
severity
of
something
or
it's
a
dev
cluster,
and
you
don't
care
that
much
all
these
policies
can
be
changed
and
configured
accordingly.
So
it's
we
can
have
comments.
So
if
a
violation,
pops
up
and
it's
something
that's
continuously
there-
you
can
leave
comments
for
the
next
person
to
come
in
and
you
can
export
all
these
policies
as
well.
B
That's
pretty
cool,
so
you
can
say
like
hey.
This
was
me
right.
Like
oh
hey,
it
was
me
I
accessed
this.
That's
actually
how
you
wouldn't
think,
like
that's,
actually
really
smart
like
because
I
would
have
never
thought
to
have
put
like
that
in
like
if
I
was
like
designing
this,
but
like
as
an
afterthought,
I'm
like
oh
yeah,
like
that.
That
would
be
cool
to
put
like
just
some
information
for
someone
else.
That's
taking
a
look
at
the
violation.
C
Yeah
and
a
lot
of
a
lot
of
this
tool
is
about
baselining
when
we
get
to
the
network
graph,
you'll
see
it
as
well.
It's
there
are,
you
have
to
accept
an
inherent
amount
of
risk,
and
that's
why
risk
is
such
a
cliche
thing
to
say
in
in
security
right
and
just
risk
in
general
to
define
so
it's
here's,
the
information,
here's
the
best
practice,
the
things
that
you
need
to
worry
about,
and
then
it's
up
to
your
security
team
as
to
how
you
want
to
enforce
it.
C
We're
not
going
to
some
security
tools
tend
to
be
very
opinionated
about
what
you're
supposed
to
enforce
and
that
can
lead
to
like
false
positives
or
breaking
builds
that
you're,
not
that
you
don't
necessarily
want
to.
So
we
tend
to
err
on
the
kubernetes
approach
to
hey,
come
into
the
cluster
everything's
pretty
much
wide
open,
and
then
you
can
go
from
there
and
and
really
secure
right,
because
if
we
had
network
policies
enforced
by
default
and
kubernetes,
I'm
pretty
sure
it
would
not
have
got
adopted
right
away.
B
C
And
a
lot
of
I
don't
want
to,
let's
just
say
that
certain
tools
and
certain
providers
and
things
like
that,
it's
just
here's
the
cv.
You
need
to
be
aware
of
it,
but
then,
if
you're
using
rel
or
something
like
that,
it
should
be
okay.
We
really
don't
need
to
let
you
know
about
every
single
cve,
that's
out
there.
These
are
specific
to
you.
C
These
are
the
things
that
really
matter,
or
I
mean,
even
even
if
you
have
vulnerabilities
in
your
images,
it
doesn't
necessarily
mean
that
they're,
exploitable
or
really
active
at
any
aspect
in
your
container
are
being
used.
So
there's
there's
things
that
you
can
do
to
basically
say
hey.
These
are
the
fixable
aspects
like
these
are
some
things
that
you
can't
fix,
but
do
you
really
need
them
in
the
container?
Are
there
other
options
so
yeah?
It's
just
about
triaging.
Accordingly,
right.
A
C
C
B
C
B
C
That's
a
great
question,
so
you've
identified
a
cve.
If
there
is
maybe
it
just
needs
an
upgrade.
So
maybe
you
push
to
your
devs
and
you
say:
hey
build
this
pipeline
right
now
or
maybe
you
you
understand
that
you
need
to
change
versions
or
something
like
that.
If
there's
a
quick
fix
normally
when
cves
are
released,
they
tend
to
come
with
the
fix
associated
with
them
by
the
application
developers,
if
something's
major
most
likely.
That
will
so
if
a
new
cve
comes
out
and
it's
something
that's
high
level,
you
you'll
get
an
alert
that
hey.
C
This
is
something
that
that
can
be
fixed
and
is
relatively
new.
It
just
needs
an
update,
that's
one
example:
another
one
would
be.
There
could
be
a
vulnerability
that
doesn't
necessarily
it
might
be
rated
as
low
or
you
need
a
specific
exploit
like
you
need.
Let's
say
you
need
to
have
access
to
port
80
or
something
like
that.
Well,
python,.
C
Yeah
you're
screwed
yeah,
but
realistically,
if
you
have
the
the
configuration
file
in
your
deployment
set
up
properly
and
your
network
policy
is
set
up
so
that
that
port
can't
be
accessed,
it's
not
really
an
issue
right,
so
there's
more
to
just
hey.
I
have
a
vulnerability
to
push
it
so
that
we
can
make
the
change
at
the
build
stage.
You
don't
you
might
not
need
to
and
that
you
might
want
to
get
to
that
eventually.
But
that's
not
high
priority
for
the
team
right.
So
there's
more
conversation,
there's
more
context.
C
B
Like
this
one
here,
like
I'm
looking,
this
looks
like
this
image
here
by
the
way
it's
my
image,
I
know
I'll
I'll
admit
it.
This
is
one
of
my
test
images,
but
mike
was
like
well
do
you
have
you
know
some
some
test
images?
Oh
like
oh,
I
have
some
images
that'll
light
up
like
a
christmas
tree,
but
it
looks
like
some
of
these.
It
looks
like
I
just
need
to
rebuild
the
container
right
like
I
should
do.
C
Yeah
so
have
been
updated
with
the
new
collections,
so
you
need
to
do
an
update
basically
and
then,
if
you
want
the
full
cv
description
to
understand
a
little
bit
more,
you
can
go
there
as
well
and
and
really
that's,
if
you're,
to
go
to
the
overview.
If
I
were
to
go
back
to
the
main
screen,
if
we
sort,
if
we
view
all
and
we
sort
by
fixable,
these
are
the
the
ones
that
we
want
to
focus
on,
especially
the
recently
detected
ones.
So
the
biggest
thing
about
acs
is
the
longer
it
runs.
C
The
more
you
get
a
baseline
for
what
your
services
should
be
network
images
that
are
running
users
and
you'll
start
to
see.
Okay,
there's
a
change!
There's
a
new
cve
from
the
newest
update,
it's
a
fixable
one.
This
is
probably
something
that
has
recently
come
out
that
just
needs
an
update
or
a
patch
to
do.
Let's
prioritize
that
right.
B
A
B
B
B
C
Sweet
and
then
well
since
we
were
talking
about
fixable
cves,
I
figured
I'd,
show
you
this
dashboard.
We
can
look
specifically,
we
can
sort
by
fixable.
We
can
also
snooze
ones.
So,
let's
say,
as
your
security
team,
you've
installed
things
and
you're.
Obviously,
there's
a
ton
of
containers
running
really.
What
you
want
to
focus
on
are
things
with
a
high
cvss
score
things
that
have
high
impact
that
can
be
exploited
and
also
we
want
to
look
at
the
amount
of
components
and
deployments
that
are
associated
with
it
right.
Is
this
something
the
more
prolific?
C
That
would
have
a
big
impact
to
fix
right.
That's
something
that
it's
like:
hey
everybody
team
wide.
We
need
to
just
go
and
upgrade
this
specific
part,
or
we
need
to
pull
a
different
base
image
to
make
sure
that
this
is
that
this
has
changed
and
that
will
have
a
significant
impact.
So
this
extra
information
helps
you
triage.
B
Yeah,
you
can
also
like,
I
think,
mitigate
that
with
like
ubi
right,
like
if
you're
using
red
hat
ubi-
and
you
know
you
know
like
your.
Your
cluster-
is
like
well
you're
vulnerable
but
like
if
all
your
images
are
based
on
ubi,
you
can
probably
just
update
your
base
image.
You
know
at
one
place
right
and
it
should
cascade
right
across
your
environment.
C
Definitely,
I
don't
think
I've
actually
done
this
yet,
but
yeah
configuration
management
this.
This
is
the
other
aspect.
This
is
when,
when
we
talk
about
risk
in
this
dashboard,
we're
pairing
vulnerability
management
and
the
images
themselves
with
the
configuration
of
your
application
in
the
cluster,
so
there
are
other
things
that
and
policies
that
violate
basically
best
practice
here
so
curl
in
an
image
right
being
able
to
pull.
C
C
Yeah,
so
you
can
see
the
policies
that
are
being
failed,
and
this
is
this:
is
cluster
wide,
so
yeah,
maybe
you
make
an
exception
for
specific
ones,
but
in
general
this
is
a
policy
that
you
want
to
have
and
of
course
you
can
change
the
the
format
you
can
make
it
120
days.
You
can
make
it
60,
you
can
make
it
two
if
you
wanted
to,
and
just
there
are
also
little
things
you
know
like
required
labels
and
owners
right,
so
you
can
enforce
best
practice,
and
this
can
be
done
earlier
in
the
pipeline
too.
C
If
that's
something
that
you're
interested
in,
but
it
all
culminates
with
basically
a
risk
assessment,
that's
highlighting
the
riskiest
deployments
and
it's
giving
you
a
priority
score
of
what
you
need
to
focus
on.
So
we
have
some
very
severe
violations,
environment,
variables,
containing
secrets
and
some
fixable
severity.
Some
fixable
vulnerabilities
that
you
need
to
to
get
to.
C
And
as
we
go
down,
there's
so
there's
a
little
bit
about
the
service
configuration,
so
no
capabilities
were
dropped.
So
assuming
that
there's
no
security
context
on
this
deployment,
which
means
it
has
full
capabilities,
not
great
volumes,
are
mounted
with
read,
write
ports
exposed
components
that
are
useful
for
attackers.
C
C
Yeah,
so
this
is
obviously
a
larger
image,
there's
227
components.
So
basically
we
scan
the
docker
file
and
you
get
a
list
of
all
the
components
to
to
go
and
take
a
look
at
and
then
you
obviously
have
the
default
service
account
as
well.
So
this
is
probably
one
of
the
riskiest
things
you
could
ever
do
in
the.
C
C
The
nice
thing
is
on
the
event
timeline.
You
have
no
policy
violations
of
actual
running
processes.
So,
even
though
you
have
a
specific
process,
they're
running
you
haven't
violated
anything,
but
if
we
were
to
view
the
graph
we
can
see
when
specific
processes
were
run
in
the
event
time
and
what's
useful
about
this,
is
you
can
set
up
alerts?
A
C
B
C
Yep
and
if
you,
because
we
use
the
admission
web
controller
for
enforcement,
let's
say
there
was
a
process
that
you
didn't
want
to
run
and
you
wanted
to
stop
that
process.
Well,
all
we
do
is
we
just
kill
the
pod,
because
unless
you
want
to
kill
the
deployment,
you
kill
the
pod
of
that
process.
The
service
is
still
up
and
it
just
goes
and
brings
up
another
one.
So
something
as
simple
as
simple
as
that.
C
If,
if
an
attacker
was
able
to
get
access
to
the
pod,
they'd
only
be
able
to
run
one
command,
they
get
kicked
out
right
away
and
then
they
can
try
again
and
they're
going
to
keep
getting
kicked
out,
but
then
you're
going
to
get
notified
and
you're
going
to
make
an
adjustment,
and
it
just
allows
you
another
sort
of
layer
to
to
respond
without
having
to
shut
everything
down.
That's
an
option.
C
C
B
C
Yeah,
I
don't
know,
but
there
you
go.
I
do
I
do
want
to
show
the
network
graph
and
a
little
bit
of
the
pipeline.
I
set
up
before
we
get
caught
up
on
time,
so
yeah
this
is
the
network
graph.
It
would
look
a
lot
cooler
if
I
had
a
load
to
run
against
this
cluster,
but
since
it's
pretty
new
we
don't
have
a
lot
of
connection
information.
C
Typically,
you
have
this
active
and
allowed
view,
so
you
can
do
both
so
connections
that
are
allowed
and
active
ones
that
are
currently
being
in
use.
The
blue
sort
of
signifies
that
a
network
policy
has
been
set
up.
Red
means
it
hasn't,
so
these
are
ones
that
you
definitely
want
to
go
to
and
say,
hey,
there's
an
anonymous
flow
and
we
need
to
make
sure
that
network
policies
are
set
up
for
these
right
now.
There
isn't,
and
there
are
a
bunch
of
updates
available
too.
C
So
this
is
definitely
a
cluster
that
needs
some
work
and
one
of
the
best
things
about
this
honestly
is
the
the
baseline.
So
this
is
baseline
traffic.
Let
me
go
back
here,
yeah,
so
for
the
scanner,
the
scanner
database,
there's
two
baseline
flows,
it's
basically
scanner.
This
is
expected
right.
Ingress
in
the
namespace
stack
rocks.
What's
not
expected
to
the
ui
is
all
of
the
network
flows
in
the
cluster.
C
C
C
C
B
C
C
Yeah,
if
it's
in
the
cluster,
you
would
get
like.
Let's
say
an
an
application
was
using
some
network
tool
to
get
at
stack,
rocks
right.
That
would
come
up
as
a
violation
of
runtime
in
that
application
in
the
cluster,
so
that
would
be
logged
right
if
it
was
an
external
entity
trying
to
get
at
the
api.
A
A
B
C
What
you
can
do
is
when
that
runtime
process
initialization
is
known.
Well,
you
can
flag
it
as
a
baseline
to
say
this
is
a
normal
runtime
process.
This
is
for
this
team.
This
is
expected
and
then
alert
on
anything
that
isn't
those
right.
So
it's
it's
kind
of
one
of
those.
It's
that
you
need
the
flexibility.
You
can't
just
say
anytime,
that
we're
going
and
reaching
out
of
the
cluster
for
for
packages
or
dependencies.
We
want
to
stop
that
right
and
yeah.
C
No,
your
apps
will
break
yeah
and
and
what
some
dashboards
I
should
say
when
they
have
network
tools
that
don't
actually
use
kubernetes
specific
functionality,
they
might
be
in
a
dashboard
and
just
say:
hey!
Well,
there's
this
weird
network
reach
out.
Okay,
you
know,
let's
just
block
that
ip
address
or
that
that's
specific
right.
So
there's
no
real
conversation
between
where
the
firewalls
are
what's
getting
blocked.
C
What
isn't
and
it's
like
a
box
around
the
cluster,
not
letting
things
in
so
there's,
there's
just
a
different
layer
and
that's
not
saying
that
you
can't
use
that
tool
and
acs
right.
You
can
have
the
external
firewall
and
then
you
can
have
the
network
policies
and
the
functionality
in
the
cluster
right.
C
B
C
C
So
I
was
thinking
like
how
do
I
sort
of
build
this
process
where
we
can
enforce
the
policies
of
acs
in
the
build
process
for
developers
or
maybe
not
enforce,
but
educate,
well,
we're
still
letting
them
deploy,
and
then
we
can
come
back
and
say:
hey
watch
out.
These
are
things
that
you
need
to
fix
before
the
next
release
and
you
can
consistently
notify
them
over.
Let's
say
the
next
six
weeks,
and
if
they
don't
fix
them,
then
you
say:
hey:
okay!
C
C
C
C
Well,
you
can
take
roc
ctl
and
go
and
install
it
at
the
end
of
these
processes
and
then
pull
the
security
information
close
to
them
and
display
it
to
them
without
actually
enforcing
anything.
And
so
then
you
can
have
that
conversation
about
these
are
some
serious
vulnerabilities
that,
if
you
do
not
fix,
you
will
not
be
able
to
push
to
production
right.
These
are
the
high
ones.
C
C
C
So
what
this
is
going
to
do
is
it's
going
to
reach
out
to
the
ui
hub,
pull
the
policies
that
are
set
up
and
it's
going
to
run
them
against
the
deployment
yaml
that
we
have
so
this
one
basically
just
fails
right
away,
because
there's
a
bunch
of
stuff
that
isn't
set
up
and
you
can
choose
whether
or
not
you
want
it
to
fail
or
not.
I
have
this
as
continue
on
failure,
because
we
don't
want
to
break
the
pipeline.
We
don't
want
to
impede
developers
right.
C
B
C
Yeah,
I
would
take,
and
really
what
I
would
probably
do
is
I
just
take
jq
pipe
it
into
a
file
and
then
just
you
can
literally
have
it
automatically
sent
as
an
email
to
a
developer
on
the
build
right
or
something
like
that,
depending
on
what
you
use
for
your
ci
process,
but
it
it's
just
kind
of
a
hey.
Is
everybody
aware
this
this
build
just
you
know?
Maybe
it's
not
merged
into
the
main
branch,
but
this
is
a
pr.
C
C
B
That's
this
the
whole
get
workflows
thing
where
it's
like.
Okay,
you
know
your
your
ci
told
you
that
you
know
here's
vulnerabilities
you
need
to
fix
before
we'll
even
allow
you
to
merge
this
feature
branch
into
the
the
main
branch.
So
this
is
that
which,
which
is
pretty
cool
right.
It's
all
about
information.
It's
all.
C
C
Yeah
and
the
reason
that
we
designed
it
as
rock
ctl-
I
don't
know
if
it's
going
to
turn
into
acs
ctl,
like
I
kind
of
like
rock
ctl-
is
so
that,
because
it's
a
binary,
you
can
go
and
install
it
in
a
lot
of
different
ci
pipelines,
and
you
don't
need
to
worry
about
integrations
it's
pretty
much.
You
know
plug
and
go
in
a
bunch
of
different
setups
and
because
we
want
to
be
cube
native
and
be
applicable
to
a
lot
of
different
use
cases.
It
just
made
sense.
C
C
C
C
But
now
it's
like
okay,
well,
which
layer
matters,
because
if
the
developer
doesn't
care,
they're
always
just
going
to
leave
it
as
root?
Okay.
Well,
is
that
a
practice
that
we
want
to
stop
with
the
developers
so
again
like
not?
Every
policy
is
important
and
it's
up
to
you
to
kind
of
figure
out
and
have
the
conversation
with
the
team
and
say
maybe
we
should
drop
root,
because
you
know
we're
leaving
your
security
context
wide
open.
You
can't
have
both
right.
B
A
C
Still
got
to
work
on
the
pipeline
a
little
bit,
but
what
what
I
kind
of
wanted
to
show
is,
if
you
let's
say
you,
you
have
that
github
pipeline
and
it's
continue
on
failure
and
then
argo
cd
automatically
goes
and
pulls
it
into.
Let's
say
your
test
environment:
if
there
are
certain
processes
that
you
really
care
about
or
certain
policies
you
want
to
enforce.
Well,
then
you
just
go
into
that
ci
process
and
say
we're
not
going
to
continue
on
failure
anymore
right,
so
part
of
the
implementation
is.
C
Maybe
it's
here
are
the
policies
you
need
to
worry
about.
You
have
three
months
to
come
into
compliance
and
then
we're
going
to
stop
allowing
this
continue
on
failure
into
your
test
environment
right.
So
there's
there's
like
a
given
and
taken.
You
don't
necessarily
need
to
come
in
and
enforce
everything
right
away,
and
you
can
be
a
little
flexible
in
how
you
set
it
up.
Yeah.
C
C
C
And
we
ran
rock
ctl
against
it.
We
found
three
alerts
found
based
off
of
it,
so
as
as
part
of
your
pipeline,
as
you
can
do
a
lot
more
honestly
in
this
than
you
can
to
github
actions
and
I'd
I'd
recommend.
This
is
the
next
thing
I
want
to
work
on
is
just
the
build.
The
check
check,
mark,
okay,
config
good.
C
Are
you
ready
to
deploy
and
then
that's
the
manual
stage
at
which
you
say
yes,
so
you
basically
have
parallel
pipelines
between
configuration
and
image,
you're
violating
them
all.
Are
you
violating
them
all?
You're
checking
you're,
checking
them
all
against
your
policy
standards
and
then
and
then
you
can
choose
manually
to
deploy
it
or
not.
C
Anything
else
any
other
questions
and,
of
course,
from
a
management
standpoint.
You
can
look
at
your
different
clusters.
All
the
system
policies
are
here,
you
can
re-assess
them,
you
can
import
specific
ones.
You
can
create
new
ones,
policies,
summary
severities
and
you
you
can
export
them
all
through
the
api
as
well.
If
you
want
to
to
back
up
and
go
and
redeploy
somewhere
else
so.
C
A
C
So
the
yeah
the
image
signatures
and
is
in
the
road
map.
Binary
authorization
is
already
thing.
I
think,
really
only
google
has
it
operationalized
at
this
point,
right
cool
that
I'm
aware
of
otherwise
I
mean
you
could
you
can
obviously
do
an
open
shift
with
sigstor
as
well?
That's
right!
It's
been
it's
been
an
option
for
the
last
year
and
a
half,
I
believe
so
cool.
But
yes,
the
integration
into
acs
is
on
its
way.
A
B
And
you
know,
that's
like
that's
like
a
big
thing
right
like
I
want
to.
I
want
to
know
like
there's,
you
know,
there's,
there's
alerting
right
and
like
there's
a
kind
of
like
kicking
back
sort
of
thing,
but
like
there's
also
flat
out
like
stopping
even
before
even
touches
my
cluster
right
yeah.
So
I
know
that's,
that's
gonna,
be
that's
gonna,
be
big
because
that's
I
know
a
ton.
A
ton
of
people
been
asking
that
for
a
while.
So
it's
great
that
it's
on
the
roadmap.
B
B
B
A
A
C
I
also
would
probably
get
in
trouble.
I
really
should
show
this
a
lot
more,
the
so
the
policy
violations
and
cis
docker
standards,
and,
and
all
this
that
it
comes
up.
You
can
export
all
these
as
well.
So
when
you
have
audits
or
things
that
pop
up,
it's
very
very
useful.
If
we
look
at
some
policy
violations,
you
can
see
the
categories
here,
of
the
violation
of
the
the
policies
that
they're
violating
so
for.
C
Cis
and
docker
cis
4.1,
and
you
know,
ensure
that
a
user
for
the
container
has
been
created
every
time.
So
there
was
a
couple
that
were
running
as
root
right
that
we
saw
where
there
was
no
user.
That
obviously
violates
the
the
benchmarks,
and
so,
if
you
got
audited
for
that
standard,
you'd
fail.
Here's
the
here's,
how
you
rectify
it
make
sure
that
all
your
docker
files
aren't
rude.
So
we
were
talking
about
that
as
part
of
the
ci
process
too.
So
that
was
a
it's
like
hey.
C
A
B
C
Oh
yeah,
completely
the
if
you
wanna
check,
I
don't
wanna,
go
to
help
docs
right
now,
but
the
documentation's
online
and
has
all
the
the
api
documentation
as
well
that
you
can
pull
from
and
so
part
of
the
the
policies
that
you
create.
So
these
system
policies
is
that
you
can
export
them,
clone
them
and
edit
them.
So
you
can
pull
them
into.
Json
format
have
them
all,
and
if
you
want
to
make
changes
to
the
policy,
you
don't
even
have
to
go
into
the
ui.
B
C
C
Can
turn
them
off
right,
garbage
them
disable
policy
right.
So
that's
pretty
much
all
you
and
then
so.
Yeah
take
the
defaults
edit
them.
The
best
thing
about
exporting
is,
if
you
have
one,
have
two
different
uis,
so
you
have
like
a
ton
of
different
clusters
or
maybe
you
have
database
specific
clusters
and
then
you
know
your
state,
stateless
applications
and
you
like
to
separate
them.
C
Whatever
the
use
cases,
it
might
be
useful
to
basically
pull
the
the
rules
and
then,
if
anything
ever
happens,
because
you've
created
all
these
very
unique
policies
and
you
need
to
go
and
reconfigure
it.
You
have
them
all
in
json.
You
can
just
go
and
hey
take
this
and
then
all
the
policies
will
pop
pop
back
up
sort
of
your.
C
B
B
C
C
A
B
B
So
yeah
that's
this
is
so
I
don't
know
if
you
wanted
to
show
anything
the
last.
You
know
eight
minutes
that
we
have
here
in
the
last
few
minutes
here
I
don't
know
if
you
want
to
show
anything
or
like
if
you
want
to.
You
know
talk
about
where
people
can
learn
more
about
acs
or
where
they
can
find.
You
know
more
more
information,
more
something
to
read
something
to
watch.
C
C
C
C
So
for
the
the
documentation
everything's
up
online,
if
you
want
to
check
it
out,
you
want
to
get
started
with
rock
ctl.
You
can
download
it
as
well.
It's
it's
all
there
backup
restoring
upgrading,
operating
building
into
ci
pipelines.
Everything
you
need
is
in
the
docs
I
have
from,
and
there's
there's
a
community
site
as
well
stack
rocks
is
going
to
be.
You
know
our
hcs
is
going
to
be
open
sourced
in
the
future.
B
C
B
A
A
A
B
B
So
yeah
so
there's
another
if
you're
in
the
here
I'll
I'll
copy
and
paste
the
link
here
in
the
chat,
so
cncn
cncf
slack.
So
now
not
only
is
stack
rocks
on
there.
Actually,
the
argo
city
folks
are
on
there.
So
if
you're,
if
you
have
questions
about
argo
cd,
all
the
engineers
and
all
the
community
members
are
there
as
well
so
and
the
get
ops
working
group
is
there.
So
it's
not
just
that
shocking.
A
B
B
B
B
B
B
A
B
Right,
oh
you've
been
eliminated,
you've
been
eliminated,
nope,
that's
and
then
we'll
take
off
so
anyways.
Thank
you
mike
for
coming
on
showing
us
it's.
It
was
fun
you
made
me
a
fan
of
you
know.
Right
saw
it
for
the
first
time
a
couple
weeks
ago.
So
a
lot
of
the
times
you
get
bogged
down
in
your
own
little
world
and
you
can't
really
like
you
know
once
you
start
seeing
other
stuff
that
the
community
is
doing,
and
you
know
stuff
that
red
hat's
doing
like.