►
From YouTube: Self Healing GitOps: Continuous, Secure GitOps Using Argo CD, Helm and OPA - Upkar Lidder , Tenable
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Self Healing GitOps: Continuous, Secure GitOps Using Argo CD, Helm and OPA - Upkar Lidder , Tenable
Argo CD empowers the community to adopt GitOps for K8s. Argo CD triggers automated operations for cluster reconciliation by monitoring changes in git for images and artifacts such as Helm Charts. While Argo CD enables hyper-automation for cluster deployment, how can teams ensure they aren't slowed down by requirements such as security, privacy, and compliance? In this talk, Upkar Lidder will discuss how to leverage the power of the Open Policy Agent to automate the delivery of secure, compliant deployments. Argo CD with OPA can ensure that any Helm charts and container images to be deployed are compliant with the established policies. Upkar will also demonstrate a new approach of self-healing GitOps to the community which leverages OPA's Rego language to remediate risks and violations on the fly.
A
Let's
get
started
so
hey
everybody,
my
name
is
obcar
litter.
I
am
a
product
manager
at
tenable
at
Town
movie
provide
a
cyber
security
platform
that
you
can
use
to
analyze
your
exposure
and
risk
for
all
of
your
assets
in
one
place.
That
includes,
for
example,
risk-based
or
priority
and
risk-based
vulnerability.
Management
on
your
workloads,
configuration
management
or
misconfigurations
on
your
Cloud
resources,
including
kubernetes
and
Cloud
native
resources,
then
I
said
that
twice
web
application,
security,
identity,
security
and
a
lot
of
other
things.
A
So
all
of
that
coming
together
in
one
place,
because
that's
how
you
need
to
look
at
security,
not
in
silos
in
in
you
know,
one
vulnerability
at
one
resource
level:
I
primarily
focus
on
shift
left
and
container
security.
So
that's
the
area
I
play
in
and
that's
why
I'm
here
to
talk
to
you
today
about
embedding
policies
code
in
your
git,
Ops
and
CI
CD
builds
and
life
cycle.
A
I
have
the
slide
here
on
how
amazing
and
awesome
Cloud
native
is
and
kubernetes
is,
but
I
feel
like
I'm
preaching
to
the
choir
here
since
you're
all
here,
but
I.
Remember
a
story:
I
went
to
kubecon
North
America
first
time
ever
and
I
was
really
convinced
that
everybody
who
speaks
there
or
goes
there
as
an
attendee,
basically
can
code
an
operator
in
their
sleep
and
they
dream
about
crds
and
when
I
got
there.
I
was
presently
surprised
that
I
was
wrong.
People
go
there
who
are?
A
Are
newcomers
beginners,
go
there
to
learn
things,
and
so
that's
why
I
left
this
thing
here
right
because
I
know
we're
being
live
streamed
and
also
this
will
go
on
replay
later
so
for
folks
who
are
new
to
all
this,
the
point
I
want
to
make
here
is
cloud
native
infrastructure
is
feeling
Innovation.
There
are
two
main
reasons
for
that:
one
is
increased.
Velocity
in
less
process.
Friction
these
numbers,
you
know,
tell
the
same
story.
A
So
Cloud
native
apart
from
I,
don't
know
if
you've
seen
the
cloud
cloud
native
landscape,
where,
like
you
literally
need
a
magnifying
glass
in
order
to
see
the
little
cards
on
that
page.
But
apart
from
all
of
the
tools
and
Frameworks
Cloud
native,
brings
a
change
in
culture
as
well
as
processes
and
mindset.
Right,
that's
more
important
to
me
because
technology
comes
second
people
come
first,
it
provides
an
extremely
high
Pace
infrastructure
right.
We
all
know
this.
A
So
I've
worked
with
serverless
environments,
for
example,
where
it
almost
feels
like
I'm
back
in
the
Heroku
Cloud
Foundry
world,
where
am
I
local
code
and
I
use,
do
a
CF
push
and
it
pushes
my
code
under
the
theme
that
might
be
using
istio
for
service
mesh
I.
Think
the
one
I
used
used
Poquito
for
a
source
to
image,
build
Etc,
but
all
of
that
again
is
hidden
from
the
developer,
giving
them
an
easier
way
to
manage
runtimes
and
deploy
at
scale
on
the
cloud
right
sounds
great,
just
like
the
wallpaper.
A
What
room
is
this
anybody
yeah?
This
is
all
yeah.
However,
is
this
velocity
leaving
you
vulnerable
right?
This
is
the
Crux
of
the
talk,
so
it's
nice,
it's
nice
and
awesome
to
move
fast.
But
what
are
you
missing
out
of
specifically
from
the
kubernetes
point
of
view
and
and
coming
in
from
a
developer
lens,
because
I
was
the
developer
for
a
while
before
I
got
into
product
management?
A
Security
still
lies
in
with
the
security
teams
and
there's
a
big
gap
there
right.
So
with
that
disconnect
the
best
case
scenario,
is
you
slow
down
your
velocity
because
security
security
teams
will
not
let
you
will
not
allow
you
to
push
stuff
to
production?
That
has
a
vulnerability
worst
case
scenario.
Is
you
you
expand
your
exposure
service
and
attack
surface
because
you're
letting
things
go
into
production
right?
So
that's
number
one
easy
for
developers.
However,
security
takes
the
back
seat
and
it's
managed
in
my
experience
by
somebody
else.
A
Second,
is
default.
Configurations
are
not
secure
right
before
now
before
you
get
up
and
start
throwing
Tomatoes
at
me,
kubernetes
has
a
very
good
security
system
built
in
my
point
here
here
is
it's
not
turned
on
by
default
in
most
cases
and
that's
and
that's
the
problem
right
and
there's
a
reason
for
that
default.
A
Configuration
drive
a
certain
kind
of
behavior
right.
Kubernetes
is
built
for
Speed
performance
scalability,
and
that's
why
it
has
the
defaults.
It
has
and
like
I
said,
every
level
in
that
architecture
in
kubernetes
has
the
levers
and
control
built-in
for
security,
but
in
a
lot
of
cases,
I
see
developers
go
with
what
given
by
default,
and
that
generally
is
not
good
enough.
A
A
On
top
of
that
deploying,
for
example,
eks
and
AWS
AWS
has
its
own
policies,
user
groups,
Etc
and
then
kubernetes
comes
in
with
its
own
rbac
system
for
authorization,
and
so
you
have
to
be
very
careful
and
that
introduces
complexity
that
any
change
you
make
at
the
lower
layer
need
to
then
propagate
to
the
other
layer
as
well,
because
they
both
are
tied
to
each
other
right.
So
these
three,
in
my
viewpoint,
is
what
makes
kubernetes
difficult
our
security
difficult
in
kubernetes,
and
also,
if
you
talk
to
I've,
talked
to
many
customers.
A
If
you
read
these
white
papers
and
things
like
that
right
down
in
the
reads
like
what
are
the
top
concerns
that
security
people
have
so
one
is,
am
I
able
to
Define
consistent
policies
across
my
teams.
Right
second
is
once
I've
defined
that
am
I,
then
able
to
apply
these
policies
across
my
many
clusters,
as
well
as
many
Cloud
providers
right.
A
Every
customer
I
talk
to
usually
there's
a
public
cloud
provider
plus
there
is
something
on-prem
that's
going
on
right
and
you
want
to
be
able
to
apply
the
same
policy
consistently
across
and
the
third
thing
is:
how
do
I
get
my
developers
to
honor
the
same
policies
on
the
very
left
on
their
laptops?
Because
that's
where
everything
starts.
A
So
this
is
my
sort
of
recommendation.
If
you're
new
to
security
and
kubernetes
I
would
say,
look
at
these
things
first,
so
on
the
very
left
is
kubernetes
misconfigurations.
So
you
want
to
be
able
to
create
a
single
policy
framework
for
governance
and
access
control.
So
this
is
when
we
talk.
This
is
how
we
talk
about
policy
as
code
right.
You
want
to
be
able
to
say:
hey
here,
are
my
set
of
policies
and
Associated
benchmarks,
and
I
need
to
apply
this
again
consistently
consistently
throughout
that
life
cycle.
A
The
development
life
cycle
examples
could
include,
for
you
might
have
a
policy
that
says
that
you're
you're
not
allowed
to
run
any
root
container
in
your
cluster.
That's
an
example,
or
you
might
have
a
policy
that
says
your
kubernetes
API
server
cannot
be
publicly
accessible
right,
and
these
are
all
what
we
call
configurations
and
a
violation
of
such
a
policy
would
be
considered
a
misconfiguration
moving
a
little
bit
to
the
right.
A
Then
you
want
to
again
apply
the
same
policies
and
your
cicd
lifecycle
right
and
that's
when
let's
say
you
have
infrastructure
as
code
whenever
a
new
commit
comes
in
a
new
PR
is
open.
You
again
want
to
test
against
the
same
policies
and
disallow
that
PR
if
policy
is
violated,
but
that's
the
misconfiguration
side
of
things
right,
then
you
want
to
be
able
to
check
for
vulnerabilities
and
images
as
well.
A
I've
worked
with
an
open
source
project
called
it
was
called
PIRA.
They
were
based
out
of
Spain
Barcelona.
It's
a
great
team
to
work
with
and
I.
Remember
us
for
running.
You
know
whatever
comes
default
with
Docker,
that
the
vulnerability
scanner
and
then,
as
long
as
everything
looked
medium-ish,
it
was
fine
right.
So
that's
the
developer
cake
on
it
and
that's
why
policies
are
important
to
enforce,
to
avoid
that
kind
of
behavior
enforce
strict
policies
so
again
very
important
to
scan
your
images
before
they
get
into
your
runtime.
A
Obviously,
because
you
know
one
CBE
and
one
vulnerability
is
propagated,
multiple
times
in
your
production,
on
your
runtime
environment
and,
finally,
once
you
have
all
of
these
three
pieces
in
place,
then
it's
really
important
to
look
at
sort
of
the
whole
picture
together,
you
want
to
look
at
your
how
you
apply
your
exclusions.
I
can't
say
that
word
how
you
remediate,
putting
it
automated
processes
to
be
able
to
do
that
right.
That's
sort
of
the
last
step.
A
Okay,
I
think
I'm,
going
really
fast,
which
is
good.
I,
usually
am
slow,
okay,
so
just
strictly
looking
at
your
cicd
pipelines
and
security
guard
guard
rails
in
that,
in
that
context,
policies
code
is
again
a
perfect
way
to
do
it.
Policy
is
code,
so
if
you
know
infrastructure
as
code,
the
benefits
that
that
brought
to
the
infrastructure
layer
in
terms
of
repeatability
reducing
human
errors,
the
same
thing
is
is
brought
by
policies
code
through
your
regular
policy
files
into
your
into
your
policies
right.
A
The
the
main
power
of
policy
is
code
I've
listed
three
years,
so
the
first
is
low.
Friction
right
because
it's
policy
as
code
it
can
work
with
existing
development
environments
tools
and
Frameworks
right.
So,
if
you're,
using
your
Jenkins
or
Travis
or
GitHub
actions
or
whatever
you're
using
in
your
pipeline,
you
can
very
easily
embed
a
tool
that'll
check
for
violations
in
there.
The
second
one
is
more
secure
by
default.
A
Since
you
are
writing
these
policies,
even
before
you
actually
initialize
your
infrastructure,
you
bring
that
up
you're
by
default,
more
secure,
because
you're
checking
for
all
of
that.
Even
before
your
infrastructure
comes
up
and
then
finally
increase
security
visibility
because
its
policy
is
code,
you
check
the
policy
files
back
into
your
social
sem,
and
so
that
way
your
availability
availability
around
what
the
different
teams
are
doing
and
you
can
monitor
it
there
right
so
very
important.
A
So
if
there's
one
thing
that
I
keep
repeating
here,
that
you
should
go
away
with
is
policy
check,
it
doesn't
just
apply
it
one
place.
You
need
to
apply
the
same
policies
consistently
across
that
life
cycle.
All
the
way,
from
the
very
left,
on
your
developer
machine
to
your
CI
pipelines
to
your
CD
pipelines
and
then
apply
the
same
plus
additional
policies
on
your
runtime
containers
right
so
once
they
are,
they
have
left
sort
of
your
world
and
gone
into
your
production
environment.
A
Okay,
so
this
is
what
this
is.
Where
Terror
scan
comes
in,
it's
an
open
source
Solution
by
tenable.
You
can
see
it's
available
on
GitHub,
a
lot
of
driven
by
Community
a
lot
of
interest,
as
you
can
see
here
by
your
forks
and
stars
and
I
know,
that's
not
the
only
way
to
measure
that,
but
you
know
it's
one
way:
it
comes
with
500
plus
policies
out
of
the
box.
It
supports
ISC
engines
like
kubernetes
or
sorry,
I,
see
engines
like
terraform
Helm,
charts,
customized
Docker
files,
so
you
can
scan
all
of
those
plus.
A
All
right
so
get
Ops
like
how
many
folks
here
actually
practice:
github's,
Frameworks
and
okay-
very
cool
all
right.
So
this
is
a
more
of
a
simplified
version
of
what
a
github's
workflow
might
look
like.
So
you
have
your
engineer
on
the
left,
pushing
some
code
to
your
sem.
Maybe
that's
GitHub
once
that
code
gets
pushed
a
good
practice
might
be
to
run
a
GitHub
action
or
a
gitlab
runner
whatever
to
then
build
an
image.
You
want
to
run
all
of
your
unit
tests
and
then,
if
everything
goes
well,
you
get
all
greens.
A
You
want
to
then
push
that
image
into
an
image
repository
public
private
right
then,
at
the
same
time,
you
trigger
an
agent
like
Argo
CD,
which
is
looking
at
your
repository
to
start
your
git
Ops
process
right,
so
you've
got
a
quote-unquote
good
image
sitting
in
your
image,
repository
Argo
CD,
say:
oh
there's
there's
a
new
image
I
need
to
deploy.
It
then
tells
it's
got
that
information
and
it
tells
your
runtime.
So
in
this
case
maybe
it's
kubernetes
hey
go
get
that
image.
Do
your
thing
and
this
might
be
a
simple.
A
A
So
what
I'm,
suggesting
and
recommending
here
with
adding
your
security
policies
at
different
levels
in
this
life
cycle
is
first,
you
put
in
your
chair,
scan
checks
and
policy
checks
right
on
the
developer's
machine
right.
One
way
to
do
that
is
using
pre-commit
hooks
or
git
Hooks,
and
so
this
is
an
example
from
the
terror
scan
site.
I
have
to
say
some
so
I
have
not
tried
this
this
exact
code.
But
again
it
should
get
my
point
across
that
you
have
a
terraform
pre-commit
hook,
which
runs
before
every
time.
A
A
developer
does
a
git
commit
and
it
runs
the.
It
runs,
a
certain
set
of
policies
that
you
have
created
or
using
the
pre-built
policies
against
the.
In
this
case,
it's
the
IAC
files
you
can
see
down
here.
It
says
your
container
is
missing
liveliness
probe
and
also
some
of
the
resources
in
terms
of
memory.
It's
not
set
right.
A
The
second
one
is
on
the
CI
side,
so
in
your
continuous
integration
after
you've
done
your
linting
you've
done
your
unit
tests
and
whatnot,
then
you
put
in
checks
and
balances
there,
and
this
could
again
would
differ
based
on
what
your,
what
your
code
looks
like
for,
IAC
would
be.
A
different
set
of
policies
for
vulnerabilities
would
be
a
different
set.
A
way
to
do
that.
I've
shown
here
is
with
GitHub
actions.
So
there's
a
teraskan
job.
Yes,
okay,
wait
yeah!
A
This
is
correct,
so
there's
a
terror
scan
job
action
which
takes
in
certain
parameters.
So
your
repository,
what
kind
of
ISE
you're
checking
against
and
it'll
check
out
the
code
and
run
that
and
only
pass
the
build?
If
and
you
can
set
that
in
the
configuration
too,
because
that
might
depend
on
your
team
right,
so
you
may
want
to
be.
You
may
be
okay
with
a
certain
number
of
threshold
in
terms
of
low
medium,
high
and
critical
vulnerabilities.
A
Okay,
the
third
thing
is
to
introduce
the
same
set
of
policies,
are
extend
those
policies
in
your
CD
pipeline.
So
this
is
where
Argo
CD
comes
in
and
syncs
with
your
GitHub
repository
you
put
in
what
is
called
a
Argo
CD
web
hook,
but
it's
a
pre-think
type
of
Epic.
So
every
time
before
a
thing
happens,
it'll
check
out
the
code.
A
A
If
that
works,
okay,
so
I'm
in
my
Argo
CD
app
now
and
let's
create
I've-
got
two
applications
here.
I
can
actually
show
this
to
you,
even
if
the
demo
doesn't
work.
This
will
be
good
to
see
so
I've
got
my
this
is
by
the
way.
This
is
public
forked
it
from
my
colleague.
You
can
go
to
his
or
come
in
here
and
that
sets
up
Argo,
CD
and
mini
Cube.
A
It
sets
up
the
Terra
scan
job,
connects
it
to
the
admission
controller
so
every
time,
and
it
creates
that
think
the
precinct
webhook
with
Argo
CD.
So
every
time
you
come
in
and
it
starts
to
sync
it'll-
create
a
new
job
with
Terror
scan
and
do
the
do
the
scan
that's
what's
going
on
here.
The
deployment
file
is
what
I
was
looking
at
before.
So
this
does
all
of
that
and
the
demo
would
show
you
two
different
apps.
So
there's
a
test
app
good
and
to
be
really
Frank
with
you.
A
This
app
is
actually
not
no
I
want
to
show
you
the
bad
app
first.
So
if
I
go
to
test
app
pad
and
open
the
the
deployment
file,
I
was
going
to
say
to
be
really
Frank
with
you.
This
does
not
look
that
bad
to
me
right.
So
this
is
probably
what
I
would
do
when
I
was
starting
with
kubernetes
I've
got
my
liveliness
Pro,
my
Readiness
Pro.
Those
are
two
things
that
people
always
add
what
else
I've
got
some
labels,
which
is
always
nice
and
I've,
got
my
I'm,
not
hard
coding.
A
A
A
A
A
Okay,
let
me
let
me
move
over
I'm
going
to
show
you
the
video
which
does
the
same
thing
that
I
just
did
but
it'll
show
you.
So
it's
a
little
bit
blurry,
but
the
important
part
is
coming
next.
So
again,
this
is
my
bad
app
I'm
doing
the
thing
here
that
I
was
just
trying
to
show
you
and
you'll
see
two
jobs
come
up
on
the
side
as
pods
and
then
I'll
click
into,
and
you
can
see
me
on
the
top
right.
A
So
this
is
a
real
demo
right
there,
which
is
working
all
right,
so
I'm
trying
to
get
into
the
Pod
to
see
the
logs-
and
you
can
see
here.
This
is
the
output
that
comes
out
of
terrascape
right.
So
this
is
doing
the
scanning
and
looking
at
policy
violations
and
outputting
the
severity
I've
I
have
configured
My
Demo
to
only
fail
if
it
finds
High
severity.
If
it
finds
the
mediums
are
low,
it
won't
fail
so
again
moving
a
little
bit
forward
here.
A
So
it's
kind
of
hard
to
see,
but
I
can
see,
there's
low,
two
medium
11
High,
one
right
and
because
there's
a
high
severity,
it's
found
at
high
severity
right
before
sinking
and
pushing
a
bad
vulnerability
to
production.
It
doesn't
do
that
thing
and
it
stops
right
and
that's
that
sort
of
broken
heart
that
you
saw
up
top.
So
the
thing
didn't
happen.
My
cluster
is
still
secure
and
then
moving
to
the
other
side.
Let
me
show
you
what
the
good
app
looks
like.
A
So,
if
I
go
back
to
GitHub,
let's
go
back
one
back,
one
good
app,
so
you
can
see
I've
done
a
couple
of
things
differently
here.
So
I've
still
got
my
liveliness
probe
and
Readiness
probe,
but
now
I've
added
the
security
context
that
says,
do
not
allow
to
run
as
rude
run.
Only
as
a
specific
user
as
a
specific
group
and
by
the
way
down
here,
I've
also
stepped
some
restrictions
on
the
file
system,
so
read-only
file
system
Etc
right.
So
this
is
configuration
that
my
policies
are
checking
against.
A
So
in
this
case,
let's
go
back
to
the
video
again.
So
now,
when
I
run
the
theme
Argo
CD
sync
operation
on
the
good
app
here,
so
sync
sync
manually
and
it'll-
bring
up
the
same
pods
again.
So
it's
been
bringing
up
the
pre-hook
or
pre-sync
hook
jaws
and
it
usually
takes
a
couple
of
minutes
for
the
logs
to
come
back.
A
All
right,
so
you
can
see
on
top
the
there's
a
green
heart
instead
of
the
red
one.
So
it's
it's
letting
things
through
and
if
you
look
down
here
now,
I've
got
a
high
of
zero
medium
of
five.
So
that's
still
the
vulnerabilities
but
I've
met
my
threshold
to
pass
this
and
let
this
go
into
the
production
environment.
A
A
All
right
so
I've
got
one
folder
here
if
I
look
at
app.
So
again,
this
is
a
simple
deployment
right,
that's
something
you
might
do.
Nginx
also
looks
very
similar
right
here.
I've
got
a
couple
of
replicas
what
image
it
should
come
from
and
this
one
I
don't
even
have
the
liveliness
and
Readiness
probes
here.
So
this
is
really
bad
app,
but
I
can
say
Terror
scan
scan.
Let
me
show
you
the
help
real
quick,
so
you
can
tell
it
other
things
too
right.
A
So
what
kind
of
icy
things
you're
trying
to
go
at?
What
kind
of?
If
you
have
custom
policies,
you
can
tell
it
where
they're
coming
from
Etc.
You
also
have
skip
rules,
because
that
might
be
important.
That's
where
the
exclusion
policy
is
coming,
our
workflow
comes
in,
but
for
us
we're
just
going
to
leave
everything
the
same
and
just
say,
scan
and
you'll
see
it
comes
back
with.
It's
found
some
IEC
code
and
your
you
know
the
stuff
you're
missing.
A
So
it's
missing
some
resource
level
limits
somewhere
in
here
it'll
also,
so
this
is
admission
of
root.
Containers
is
what
we
saw
in
the
other
one.
It's
missing
the
read-only
permission
on
the
file
system.
Cpu
limits
are
not
set,
etc,
etc,
etc.
Right,
it's
got,
It's
got
a
couple
of
high
ones
as
well,
which
is
the
root
privilege
policy.
A
All
right
and
the
last
place
where
you
should
also
put
in
your
hair
scan
policy,
evaluation
and
checks
is
on
your
runtime,
so
you've
done
it
at
the
developer
on
the
developer
machine.
You've
done
a
CI
pipeline.
You've
done
it
in
your
CD
pipeline,
but
once
you're,
once
your
image
has
made
it
to
the
your
cluster,
then
tearscan
integrates
with
admission
controllers,
so
you
can
write.
You
can
write
a
hook
there,
which
says
Hey
at
this
point.
A
A
So,
lastly,
this
this
is
our
security
maturity
model.
You
can
see
everything
we
talked
about
today
falls
in
the
first
step
of
the
ladder
policy
as
code
right
when
the
so
automated
automated
continuous
assessment
with
your
policies,
custom
policies
and
also
benchmarks
that
policies
associated
with,
because
at
the
end
of
the
day,
then,
at
the
end
of
the
day,
you
want
to
see
which
team
switch
or
the
compliance
level
at
a
cluster
level
at
A
team's
level.
Whatever
that
may
look
like
for
you,
then
the
next
step
is
governance.
This
code
right.
A
So
that's
where
you
capture
your,
for
example,
your
governance
decisions
like
exceptions
that
can
also
be
codified
right.
It
should
be
codified
for
audit
purposes.
For
example,
next
is
drift
test
code.
So
now
that
you've
got
a
cluster
running,
you
still
want
to
see.
You
know
any
time,
there's
a
change
in
the
cluster
which
was
not
provisioned
by
you
on
the
very
left,
with
your
IAC
files,
Etc
or
your
images.
You
want
to
see
drift
between
your
kubernetes
running
kubernetes
versus
your
resource,
IC
files.
A
A
But
this
is
what
we
consider
as
a
you
know,
as
you
go
to
the
right,
but
what
I
showed
you
today
was
the
very
left
and
rare
I
think
it's
a
good
place
to
start
and
then
I
don't
know
how
much
time
you
have
left
I
think
they're
almost
there.
But
this
is
the
last
slide.
I
want
to
put
up
there's
a
QR
code
if
you
want
to
scan
that,
and
I
can
show
you
the
site
as
well,
but
this
is
tarot
scan
in
action
on
tenable's
site.
A
All
right
so
this
one
here,
so
it
gives
you
sample
files.
So
since
we
just
talked
about
Docker
I'll
pull
that
up.
So
this
is
a
simple
Docker
file
and
you
can
click
on
scan.
It'll.
Take
you
tell
you
the
there's.
It
says:
there's
one
medium
violation
here
you
can
click
on
that
to
get
more
details
as
well
right,
it
can
do
the
same
thing
with
let's
say
your
kubernetes
yaml
files,
so
it
supports
different
formats
as
well.