►
From YouTube: Who else is in your pod?
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
I
still
see
a
lot
of
people
joining,
which
is
great
but
we'll
we'll
go
ahead
and
get
started.
Welcome
to
week,
nine
of
our
ten
week
cube
sec
enterprise
online
webinar
series.
We've
had
just
tremendous
interest
in
this
program
and
you
know
we're.
A
We
will
do
it
again,
but
we're
excited
or
it'll
be
a
few
more
months
before
we
kick
it
off
again,
but
we've
had
some
great
sessions
and
today's
session
is
no
different.
We
will,
I
think,
you're
going
to
really
enjoy
it.
So
let
me
before
we
get
started.
Just
walk
you
through
a
little
bit
of
the
logistics.
We
are
have
everybody
on
mute,
we'll
be
taking
questions.
If
you
do
have
any
questions,
please
you
to
use
the
go
to
webinar
questions
panel
over
there
on
the
side.
A
So
if
we
in
advance
to
the
next
slide
I'll
walk
through
today's,
the
the
the
the
other
elements
here
so
go
ahead
and
use
your
questions
panel
and
we'll
you
know
we'll
we'll
we'll
take
them
that
way,
we'll
try
to
handle
them.
You
know
in
real
time,
if
they're
relevant
to
what
our
speaker's
talking
about
otherwise
we'll
save
it
for
q,
a
towards
the
end.
We
are
recording
today's
session
you'll
get
a
copy
or
you'll
get
a
link
to
that
recording.
A
You
know
after
today's
event,
and
you
can
share
it
with
some
others
on
your
team.
If
you
find
it
interesting
and
we're
very
we're,
also
very
interested
in
your
feedback
towards
the
end,
so
we
will
be
sending
out
a
survey
along
with
that
confirmation.
A
After
the
event,
we
we'd
love
to
hear
what
you
think
and
if
you'd
like
to
be
part
of
our
next
program,
you
know,
let
us
know
that
too,
we'll
keep
track
of
it.
If
you,
if
you
feel
like
you,
have
a
topic
that
would
be
of
interest
to
the
audience
for
our
future
series.
So
let
me
turn
to
today's
event.
A
Now
we're
excited
to
have
riaz
from
cloudell
here
with
us,
and
the
topic
that
he'll
be
discussing
today
is
is
really
interesting
in
that
you
know
a
lot
of
times
as
security
people.
I
think
we
take
the
perspective
of
let's
of
our
own
perspective.
How
do
we
lock
things
down,
but
one
of
the
best
ways
to
understand
what's
happening
is
to
look
at
you
know:
how
are
these
people
the
bad
guys?
A
You
know
aiming
at
your
your
your
environment,
how
are
they
getting
in
and
what
does
it
look
like
when
they're
in
and
riaz
will
be
walking
you
through?
You
know
exactly
what
people
look
at
when
they're
targeting
your
environment
and
and
how
does
it
look
in
your
systems?
From
your
perspective,
what
can
you
see
and-
and
of
course,
you
know
beginning
to
think
about
what
do
you
do
as
a
reaction?
So
with
that?
Let
me
turn
it
over
to
riyaz
today's
presenter
and
look
forward
to
to
any
of
your
questions.
B
All
right,
thank
you,
so
much
andy
for
that.
Okay,
good
morning
and
good
evening,
folks
for
people
joining
and
joining
with
us
from
different
parts
of
the
planet.
The
idea
of
today's
presentation
stem
from
an
internal
discussion.
We
had
right
where
we
were
trying
to
understand
from
an
attacker's
perspective.
B
What
is
it
that
is
visible
to
an
attacker
and
how
does
an
attacker
traverse
all
the
way
from
obtaining
initial
access
right
and
all
the
way
to
the
impact
that
the
attacker
wants
to
cause
within
the
cluster
interested
that
the
attacker
is
targeting
the
question
that
we
would
then
pose
to
our
customers
would
be?
Are
you?
Are
you
certain
right
that
you
know
who
exactly
is
in
your
report
or
to
rephrase
it?
Who
else
is
in
your
pot
right
and
the
whole
idea
was
to
get
an
attacker's
approach
to
community
security
right.
B
I'd
like
to
shout
out
to
my
co-founder
akash
and
my
team
here
as
well
as
matt.
If
you've
joined
us
thumbs
up.
A
B
B
Throughout
my
entire
career,
we
have
looked
at
applications
or
any
infrastructure
that
is
given
to
us
right,
regardless
of
whether
it's
any
new
tech.
The
questions
that
I
ask,
the
approach
that
I
have
always
taken
is
to
you
know,
align
myself
with
what
important
attacker
do
and
ask
relevant
questions
around
that,
so
that
you
could
apply
that
defensively
and
then
say:
oh,
if
you
are
an
attacker,
I
have
this
in
place
right,
so
the
defensive
parts
of
what
we
ask
also
become
clear.
B
I
would
say
with
with
us
starting
and
asking
the
question:
are
you,
or
rather
rephrasing
that
do
you
know
what
your
organization's
footprint
looks
like
on
the
internet
right?
Are
you
aware
of
what
your
organization
exposes
your
employees
expose
your
you
know,
influential
administrators
experts,
the
second
part
of
today
or
today's
presentation
will
deal
with
actually
asking
relevant
questions
around.
What
would
your
attack?
What
would
an
attacker
do
to
get
inside
an
infrastructure
or
attack
a
kubernetes
cluster
right?
B
You
know
the
threat
matrix
microsoft
has
created
and
we
spent
some
time
with
that
as
well
like
going
through
all
the
tactics
we'll
finally
end
the
presentation
with
the
last
section
being
around.
What
would
you
do
to
minimize
the
spread
of
an
attack
or
to
prevent
an
attack
in
the
first
place,
and
all
of
these
recommendations
that
we
will
talk
about
at
the
end
of
the
presentation?
A
Yeah
definitely
so
before
we
riaz
gets
into
his
talk.
We'd
be
we're
interested
in
you
know
what
you've
all
seen
so
go
ahead
and
select
one
of
the
answers.
Have
you
faced
any
internal
or
external
breaches?
You
know
essentially,
have
you
been
hacked?
You
know
specifically
in
your
your
kubernetes
world.
Here
I
mean
obviously,
if
you're
in
security,
you
go
back
20
years
to
to
network
hacks,
that's
different,
but
you
know
have
you
been
hacked
in
your
kubernetes
environments?
A
And
you
know
the
answer
is
multiple
breaches,
but
you
don't
have
to
tell
us
the
details.
You've
had
a
breach,
but
you
feel,
like
you
dealt
with
it.
Well,
you
know
you,
you
feel
like
there
were
attacks,
but
you
actually
were
able
to
prevent
them
and
then
wow
you've
never
been
breached.
We're
so
good.
A
You
know-
or
maybe
you
just
don't
know
and
so
go
ahead
and
pick
one,
and
you
know
I'll,
give
you
another
20
or
30
seconds
here,
just
to
pick
your
answers
and
then
we'll
share
the
results
and
and
see
how
we're
doing
so.
I
see
a
lot
of
the
answers
coming
in
here.
B
Because
when,
when
we
try
and
phrase
this
question
in
a
public
forum
right
and
the
answer,
changes
based
on
anonymity,
you
wouldn't
want
you
wouldn't
want
a
lot
of
folks
to
figure
out
the
day.
You
know
what
I've
been
pretty
but
yeah.
I
get
kind
of
embarrassed
about
it
because
we
left
our
keys
out
in
the
open
on
github,
for
example,
right
and
essentially
accepting
the
idea
behind
hey
I've
been
preaching.
This
is
what
I've
done
to
change.
Security
helps
in
learning
for
the
larger
community
as
well
right
so
yeah.
A
So,
interestingly,
you
know
about
half
the
audience
is
confident
that
you
know
so
far,
at
least
in
their
kubernetes
world
they
haven't
been
breached,
you
know,
and
or
you
know,
are
unaware
of
it
if
it
certainly
hasn't
had
a
major
impact
or
they
would
know,
but
you
know
and
and
a
number
of
people
are
pretty
confident
that
they,
even
if
an
attempt
was
made,
they
were
able
to
thwart
it.
Does
this?
B
Oh
they
kind
of
align,
but
then
that's
the
last
option.
That
is
that
they
never
breached
that's.
What
we
know
for
infraction
is,
is
you
know
a
little
misleading,
because
if,
if
you're
all
familiar
with
what
happened
with
the
latest,
the
solar
winds
attack
that
happened,
multiple
organizations
were
affected
and
they
did
not
know
for
a
long
time
that
they
would
give
an
attack
right.
So
that's
that's
always
going
to
be
the
case.
A
B
All
right,
the
poll
is
closed,
yeah
sure.
B
The
essential
idea
has
always
been
that
when
you
ask,
especially
when,
during
conferences
or
during
interactions,
when
they're
in
polls
as
well,
the
standard
response
has
always
been
the
more
common.
One
has
been
that
we
don't
have.
B
A
lot
of
you
know
stuff
that
we
expose
on
the
internet
we're
careful
about
what
what
we
do
right,
but
let's
take
a
look
at
what,
as
an
attacker
over
the
years
have
seen,
people
expose
right
and
attackers
tend
to
use
these
to
then
focus
channel
their
attacks
to
specific
regions
of
your
infrastructure,
trying
to
gain
access
to
a
bigger
set
of
the
pipe
that
exists
on
your
network
right
and
a
lot
of
these.
B
A
lot
of
this
information
occurs
to
you
as
an
organization
occurs
to
you
as
something
that's
required,
as
part
of
you
being.
You
know
for
your
existence
right,
but
for
an
attacker.
All
of
these
tend
to
become
pieces
of
information
that
they
can
chain
together
right.
The
most
common
information
pieces,
I've
seen
come
from
employee
information
which
exist
on
forums
or
linkedin
right.
B
The
profiles
contain
what
technology
that
you're,
using
within
your
organization,
internet
technology,
details
that
you
know
a
lot
of
companies
post,
detailed
job
postings
on
public
forums,
responses
to
stack
overflow,
developer
responses,
the
blog
post
that
companies
write
all
of
these
leak,
some
kind
of
technological
information
to
attack
us
a
common
source
of
information
for
attackers
by
bounty
hunters.
You
know
whatever
your
motive
is:
dns
records,
the
dns
ip
history,
ip
ranges
all
of
these
tend
to
become
a
lot
of
good
sources
of
information.
B
Tcc
battery
services
that
get
detected
by
internet
whiteboard
scans,
an
attacker
need
not
even
run
a
port
scan
against
your
internet.
There
are
services
that
provide
you
provide
details
of
what's
running
on
on
your
network,
simply
by
querying
for
your
ip
addresses
organization,
name,
showdown
being
one
of
them
right,
abstract.
The
os
server
version
information
by
http,
headers,
page
responses,
a
very
common
piece,
a
recurring
theme
we've
seen
is
for
a
lot
of
folks.
The
embed
developers
tend
to
embed
keys
and
secrets
inside
javascript,
and
then
they
assume
the
the
minification
or
the.
A
B
Know
compressed
format
of
javascript
to
become
an
obfuscation
technique
right,
but
attackers
can
easily
reverse
engineer
this
or
see
that
in
the
javascript
console
in
the
browser,
a
very
interesting
source
of
information
and
a
bunch
of
you
can
try
this
out.
Look
at
the
pdf
file
properties
that
exist
for
file
uploads
on
your
own
website.
Right
as
an
organization,
we
produce
a
lot
of
content,
we
may
have
ebooks,
we
may
have
spec
documents,
we
may
have
you
know
job
postings
documents
that
are
hosted
on
our
websites.
B
B
A
Oh
yeah,
we've
we've
had
some
data
from
our
own
threat,
research
team
at
aqua,
and
you
know
what
what's
fascinating
is
when
you
know
they'll
do
honey
pots
and
they'll
put
up
a
new
kubernetes
cluster
and
it's
a
matter
of
minutes
before
people
are
attacking
it
like,
like
you
said:
yes,
those
port
scans
and
everything
else,
the
dns
you
know
ib,
ranging
all
that
stuff
they've
automated
the
process
of
finding
new
places
to
go
so
yeah.
It
doesn't
take
much.
B
Yes,
a
lot
of
organizations
tend
to
you
know,
have
staging
and
environments
that
are
misconfigured,
because
they
don't
restrict
the
kind
of
traffic
but
sources
of
traffic
that
are
going
to
be
coming
to
those
end
points
right.
So
that's
that's
a
particularly
interesting
case
default
credentials
for
third-party
apps.
A
lot
of
large
companies,
you
know,
tend
to
pay
out
large
amounts
of
money
to
bug
bounty
hunters
because
they
found
an
endpoint
which
you
could
log
in
using
an
admin
and
admin
credential
right.
B
This
has
happened
in
the
real
world
as
well
the
tendency
to
use
older
and
vulnerable
software
packages
that
don't
you
don't
update
periodically
right.
That
also
becomes
an
attack
footprint
for
your
organization,
hidden
files,
configuration
files
repositories
and
github
bit
bucket
right.
All
of
these
comments
containing
secrets.
All
of
these
tend
to
become
your
source
for
the
attack
right.
Yeah
attackers
tend
to
gather
information
about
your
organization
using
these,
and
this
is
not
a
complete
set.
B
This
is
this
is
just
the
tip
of
the
iceberg
right,
but
do
folks
really
expose
stuff
online
right?
That's
that's
the
question,
regardless
of
the
claim
that
I'm
making
and
when
I
was
creating
this
presentation
I
tend
to
I
sat
out
to
see
I
let's,
let's
actually
try
and
answer
the
claim
rather
prove.
B
B
These
three
screenshots
show
the
first
one
shows
the
shows,
a
bunch
of
kubernetes
clusters
that
are
listening
to
the
internet
and
if,
if
a
kubernetes
cluster
has
been
started,
the
api
server
has
been
started
with
priority
and
fairness
features,
you
would
have
the
x
kubernetes
pf
flow
schema,
hyphen
uid
and
that's
a
unique
header
fingerprint
that
kubernetes
will
expose
to
the
internet
right
so
simply
searching
down
the
shoulder
shows
you
the
date
results.
B
This
is
a
search
that
I
did
for
deployment
analysts,
hoping
to
find
kubernetes
related
yaml
files
for
deployments
on
gray,
hat
warfare,
pretty
cool
search
engine
for
buckets
and
storage
on
azure,
and
this
is
a
vim
underscore
setting
so
jetbrains
the
file
that
contains
project
information.
Sometimes
the
history,
that
of
the
project
itself
and
sometimes
confidential
information
can
be
on
github.
But
this
is
the
appear,
search
and
guitar
that
was
done
and
then
just
to
just.
A
All
right
great,
so
you
know
I
think,
as
riaz
moves
into
the
next
section
of
his
talk.
You
know
the
question
comes
up
of.
You
know:
where
are
you
our
audience
in
terms
of
your
own
adoption
of
kubernetes?
And
you
know
I
think
you
know
the
question.
Is
you
know
you
know
some
of
you
might
already
be
there.
All
of
your
production
workloads
are
running
kubernetes
I'll,
be
surprised,
but
we'll
see
you're,
drawing
up
plans
and
you're
testing
some
apps
and
kubernetes
you're.
A
Thinking
about
you
know
what
your
infrastructure
looks
like
and
could
be
moved
there
or
I
love
this
one
regardless.
I
don't
need
no
stinking
kubernetes
right.
You
know,
that's
your!
I
don't
know
why
you'd
be
on
today's
webinar
if
you
felt
that
way,
but
let's
see
give
people
a
few
seconds
to
sign
to
pull
their
answers,
absolutely
yeah.
I
see
them
coming
in
and
we'll
give
you
about
10
more
seconds
and
share
them
there.
You
go
so
you're
kind
of
a
good
mix.
A
I
mean
people
are
either
in
production
already
and
with
a
you
know,
bulk
of
their
workloads
there
or
you
know
just
just
drawing
up
plans.
You
know
doing
some
apps,
maybe
in
pilot
modes,
but
you
know
definitely
you're
strong,
strong
in
the
first
two
sure
super.
B
Super,
let's
then
jump
into
the
the
end
of
today's
presentation,
taking
in
from
what
we've
learned
that
organizations
tend
to
expose
a
lot
of
information
right
and
attackers
when
they
want
to
focus
on
figuring
out
kubernetes
clusters
right
and
targeting
companies
that
run
kubernetes
on
production
or
valid
testing,
and
as
long
as
you
can
get
into
the
cluster,
you
would
begin
with
a
structure.
B
Okay-
and
this
is
this-
is
this-
is
something
I've
seen
over
the
last
decade
of
working
with
a
lot
of
other
security
folks,
especially
in
the
offensive
security
domain.
All
attackers,
irrespective
of
how
unstructured
they
are,
follow
a
set
of
tactics
right
to
reach
their
input.
I
am
extremely
unstructured
in
my
real
life
right
in
the
real
world.
I
tend
to
have
notes
all
over
the
place
and
extremely
with
a
very
short
attention
span,
the
regardless
of
what
your
structure
will
run.
So
you
know
whether
you
have
a
structure
or
not.
B
Attackers
will
follow
a
set
of
tactics
to
each
temple
right
and
each
of
these
tactics.
You
could
consider
them
as
milestones.
They
tend
to
have
techniques
by
which
their
tactic
is
fulfilled
right
and
I'm
trying
to
slowly
build
into
what
the
mitre
attack
framework
looks
like
right
and
depending
on
the
technology
that
is
being
targeted.
The
tactic
may
differ
but
often
aligns
with
you.
The
attacker
will
perform
initial
discovery.
There
would
be
some
amount
of
code
execution.
There
would
be
an
escalation
of
privileges.
B
You
want
more
right
from
your
access
that
you've
obtained
there's
going
to
be
persistence
in
some
form
or
the
other
there's
going
to
be
evasion
or
evidence,
removal
in
some
cases,
but
the
attackers
don't
want
to
know
that
they
don't
want
others
to
know
that
they're
there
and
eventually
ending
with
an
abuse
or
impact
of
whatever
access.
You've
obtained
right.
B
All
of
this
maps
to
what
the
miter
attack
threat
matrix
is
in
a
sense.
This
is
a
globally
accessible
knowledge
base
of
adversary
tactics
explaining
what
an
attacker
would
do
across
different
technologies
and
the
techniques
that
they
would
say
that
that
they
would
use
for
attacking
those
technologies
right
and
all
of
these
are
based
on
real
world
observations,
and
the
link
is
right
there.
If
you
want
to
take
a
look,
several
matrices
have
been
created
for
various
tech,
verticals
windows,
linux
being
the
most
popular
ones.
B
You
have
gcp
that
have
come
out
right
and
a
bunch
of
mobile
os
tactics
and
techniques
as
well.
These
can
be
used
by
both
offensive
security
folks,
as
well
as
defenders
right,
offensive
security.
Folks.
Obviously,
the
information
is
straightforward.
You
can
pick
up
a
technique
and
make
oh.
This
is
what
I
need
to
do
to
you
know
complete
this
tactic
within
the
within
the
framework
and
for
defenders.
The
information
is
equally
useful
to
identify
the
attack
path
that
an
attacker
would
take.
The
bad
guys
will
take
so
that
I
can
build
my
defense
in
depth.
B
A
B
B
You
know
in
the
framework
creating
one
for
kubernetes
right,
an
attack
like
threat
matrix
for
kubernetes
and
most
of
the
techniques
that
are
going
to
be
mentioned
within
the
tactics
right
bunch
of
them
are
repeatable
to
achieve
different
tactical
milestones.
B
Okay,
so
a
simple
way
to
read
this:
if
you're
looking
at
this
or
the
first
time,
a
simple
way
to
read
this
table
is
the
ones
in
blue.
The
initial
access
execution,
persistence
are
tactics.
Each
tactic
has
techniques
that
attackers
use
right
and
this
particular
table
is
focused
on
kubernetes,
okay,
let's
jump
into
taking
a
look
at
what
and
I'm
going
to
cover
examples
from
I'm
not
going
to
cover
all
techniques.
That's
just
going
to
be
a
whole
day
session.
B
B
Okay
from
initial
access:
let's
take
a
look
at
one
of
the
most
common
ones,
which
is
the
exposed
dashboard
right
in
initial
access
for
the
tactic
to
become
a
platform,
you
have
an
attacker
figuring
out
an
exposed
dashboard
right
for
the
kubernetes
question
when
you
say
export
dashboard,
we're
talking
about
the
kubernetes
dashboard
right,
the
screenshot
on
the
screen
right
now
that
you
can
see
was
taken
by
the
you
know
the
amazing
folks
at
redlock.io
right
when
they
were
researching
what
kind
of
dashboards
or
kubernetes
dashboards
are
visible
on
the
internet
and
they
ended
up
on
this
particular
dashboard.
B
This
dashboard
belongs
to
tesla
right
and
this
did
not
have
any
authentication
or
authorization
simply
browsing
to
that.
Endpoint
allowed
them
to
browse
the
kubernetes
cluster
configuration
right
and
from
the
secret.
They
were
able
to
pick
out
aws
sd
credentials,
and
this
was
pretty
popular
back
in.
I
think
this
was
last
year
right,
covered
by
a
lot
of
major
news
agencies
where
tesla's
kubernetes
dashboard
was
exposed,
and
that
was
the
news
that
came
out
and
I'm
going
to
come
back
to
this
dashboard
again.
B
At
the
end,
with
an
interesting
story
with
the
impact
that
they
were
trying
to
discover
right
with
some
things
around
crypto
mining
and
we'll
touch
upon
that
when
we
reach
the
last
tactic
in
the
you
know
the
threat
matrix,
and
but
this
is
what
an
expert
dashboard
looks
like
on
the
internet,
and
you
could
reach
this
either
by
scanning
the
entire
internet,
and
there
are
tools
available
to
do
that
or
there
are
services
like
showdown,
for
example,
and
if
you
craft
your
search,
query
properly,
you'll
be
able
to
find
a
bunch
of
these
on
the
internet
right.
B
This
is
another
example
of
initial
access
where
an
attacker
was
able
to
gain
access
to.
You
know
the
files
required
to
create
your
own
cube,
config,
okay,
using
an
ssr
and
the
in
the
boundary
community.
This
is
a
really
popular
bug,
because
this
this
was
an
etsy.
The
ssrf
was
used
to
extract.
You
know
image
by
image
from
the
image
itself,
the
attacker
was
able
to
extract
client
certificate,
the
private
key
right.
The
token.
B
All
of
that
then
became
part
of
the
query
that
he
made
using
queue
cuttle
and
was
able
to
then
gain
access
to
the
cluster.
At
least
specific
mean
spaces
right.
If
you
look
at
the
bottom
most
screenshot,
you
can
see
that
the
attacker
was
able
to
get
a
shell
into
one
of
the
parts
that
were
running
right,
so
application
vulnerability
definitely
is
a
way
to
get
initial
access
inside
your
kubernetes
cluster
and
multiple
large
companies
have
in
the
past
we've
seen.
This
have
exposed
their
communities
dashboard
without
authentication
of
the
internet.
B
Which
is
read,
write
you
can
make.
You
can
use
a
curl
request
to
start
a
part
in
in
the
name
space
in
indian
space,
using
if
two
10
to
50
is
open
at
10
10
to
55
from
older
kubernetes
they're
still
exposed
10
to
55
allows
you
to
read
kubernetes
configuration,
that's
what
you
don't
report
right
and
both
of
these
are
widely
still
accessible
for
older
versions
of
communities
running
out
there.
Application
vulnerabilities
is
one
of
the
most
common
ways
by
which
attackers
can
gain
access
to
your
cluster
and
you're.
B
Looking
at
vulnerabilities
like
anybody
that
especially
can
make
a
network
request,
because
you
then
use
that
to
read
configuration
data
and
you
know,
essentially,
you
need
either
the
access
to
a
dashboard
or
you
need
access
to
the
group
configuration
file
right
so
balanced,
like
ssrif,
your
lfis
part
traverses,
arbitrary
file
downloads
right.
All
of
these
vulnerabilities
that
allow
you,
access
to
the
back
end,
would
give
you
some
level
of
access
to
the
cluster.
So
that's
what
your
initial
access
is
about
right.
B
Moving
on
to
the
next
tactic
that
attackers
use
an
execution
being
the
eventual
outcome
of
this
and
you've
gained
some
level
of
initial
access.
Now
you
want
to
move
to
executing
your
custom
port
and
the
screenshot
that
you
have
that's
visible
on
screen.
The
left,
screenshot
is,
is
a
yaml
description
of
a
pod
that,
when
applied
to
your
cluster,
would
give
you
access
to
the
underlying
mode
itself
right
and
because
the
host
pid
is
shared
right,
the
host
period
is
set
to
true
it's
shared
with
the
underlying
node
that
is
running
the
pod.
B
You
can
actually
access
the
process,
that's
running
on
the
underlying
mode
right
and
new
container
being
the
technique
that
I'm
talking
about
under
execution
once
the
ability
to
interact
with
the
cluster
is
obtained
right,
regardless
of
how
express
dashboard
keep
config
file-
and
this
is
a
hilarious
and
common
one
by.
B
A
client-side
vulnerability
right
or
secret
liquid
application
vulnerability.
Attackers
will
attempt
to
gain
a
shell
access
to
the
cluster
right.
Sometimes,
the
tactic
can
also
lead
to
privilege
creation
like
in
the
screenshot
that
we
saw
you
then,
from
using
a
single
execution
you'd,
be
able
to
gain
access
to
the
underlying
node
itself
right
so
from
the
node.
B
Then
you
could
move
on
and
use
docker,
for
example,
to
if
that's
the
container
runtime
your
people,
who,
regardless
of
what
the
content
runtime,
is
actually
use
that
to
see
what
other
parts
and
containers
are
running
like
access
logs,
you've
already
gained
those
privileges
inside
the
cluster
right,
so
execution
can
overlap
with
privileged
legislation
right
next,
we
look
at
persistence.
That's
the
next
obvious
technique.
B
According
to
the
threat
matrix
and
the
example
that
I
have
is
of
a
kubernetes
cron
job
and
the
screenshot
on
the
left
shows
a
property
scrum
job
that
runs
every
minute
and
as
soon
as
it
runs
it's
going
to
get
you
a
reverse
shell
on
the
ip
address
that
you
specified
within
the
channel
right,
and
this
is
a
standard
bash.
If
you
folks,
you
know,
there's
a
standard.
A
B
Shell
that
you
have
or
one
liner
dash
that
allows
you
to
gain
initial
execution
capabilities
to
an
end
point.
This
yaml
is
because
it's
a
cron
job
crown
jobs
create
pods
when
trying
to
complete
the
task
that
they're
supposed
to
do
the
you
what
you
will
have.
If
you
look
at
the
right
side
of
the
screen,
the
screenshot
there
shows
you
have
a
reverse
shell
that
has
coming
from
the
pod
onto
the
attacker
machine
right.
B
The
attacker
mission
is
what
is
specified
as
a
conjunct,
and
this
is
persistence
you
would
have,
even
if
somebody
is
sweeping
through
the
cluster,
tends
to
look
at
name
spaces
and
pods
the
crown
job,
even
if
they
disconnect
any
outbound
traffic.
The
kronzer
ensures
that
the
reverse
shell
jumps
back
to
life
every
minute
right.
So
there's
some
level
of
persistence
that
is
created
through
the
cron
job
for
the
attacker.
A
Riyaz
in
your
experience,
you
know
what
are
people
doing
when
they
get
in
I
mean:
do
you
have
a
sense
of
the
kinds
of
of
malicious
activity?
Is
it
you
know?
I
know,
there's
been
a
lot
of
crypto
mining
and
things
like
that,
but
any
other
types
of
attacks,
or
what
do
you
see,
sick.
B
Because
the
the
the
feature
or
the
capability
of
a
cluster,
the
most
important
capability
of
a
cluster,
that
is,
you
know
that
attracts
attackers
is
the
ability
to
scale
right.
So
if
which
is
by
crypto
mining,
is
such
a
popular
outcome
of
an
attack
on
on
your
cluster,
because
when
an
attacker
runs
their
deployment,
that
is
actually
going
to
do
mining
based
on
resources
automatically
equal
to
scale
right
and
that's
profitable
to
the
attacker.
B
Apart
from
that,
you
also,
you
know,
if
you,
if
you
have,
if
you
have
any
jump
boxes
connected
to
the
cluster,
for
example,
an
attacker
might
want
to
jump
back
into
a
different
section
of
the
network.
Right
and
data
is
definitely
something
that
attackers
go
after
and
that's
been
forever
right.
Since
the
day
the
first
attack
was
launched.
Right
data
is
something
that
attackers
will
obviously
go
after.
A
B
And
the
interesting
thing
is
that
for
extremely
large
enterprise
environments,
right
where
their
aws
and
azure
or
gcp
builds,
are
anyways
in
the
tens
of
thousands
of
dollars.
B
Starting
a
deployment
that
does
crypto
mining
would,
you
know,
would
not
raise
a
lot
of
eyebrows,
because
the
the
the
builds
that
would
come
out
would
essentially
be
it.
Look
like
it's
part
of
the
workload
build
that
they
would
get
in
every
month,
anyways
right
so
they're,
hiding
in
plain
sight.
That's
the
kind
of
dressing
that
I'm
trying
to
make.
A
B
Yeah,
that's
it
yeah.
So
yes,
the
kubernetes
crown
job
is
a
very
nice
example
of
how
assistance
could
be
maintained
and
other
ways
that
attackers
do
but
they're
not
limited
again.
This
is
from
experience
of
mapping
them
back
from
the
infra
based
days
back
to
work,
cluster,
adding
ssh
keys
to
the
underlying
node
once
you've
gained
access.
That's
that's
an
easy
win
for
an
attacker,
creating
jobs,
cron
jobs
again
reversal!
That's
what
we
saw
shadow
admins.
B
Definitely
an
attacker
would
create
a
cluster
role
or
role
that
has
the
ability
to
administer
the
entire
cluster
and
they
would
use
names
that
you
know
would
mimic
something
that
the
organization's
infrastructure
team
has
created
right
and
we'll
see
a
couple
of
examples,
as
well:
user
writeable
spot
bound
to
gain
access
to
code
to
config
files
that
the
application
is
possibly
hosting
reuse
secrets
and
a
lot
of
organization
is
trying
to
get
to
this.
A
lot
of
organizations.
Individuals
organizations
tend
to
reuse
secrets.
B
You
know,
depending
on
what
kind
of
workload
they're
it
could
be,
an
app
could
be
keys
that
their
you
know,
ability
to
have
across
different
staging
environments,
or
you
know,
in
different
manners,
but
key
reuse
and
secret
reviews
is
a
definite
thing
that
a
lot
of
our
organizations
still
deal
with
right,
storage
of
secrets
inside
conflict
maps,
for
example,
which
is
not
recommended
because
config
maps
are
supposed
to
show
configuration
information,
but
some
examples
on
the
internet
definitely
show
secrets
being
stored
inside
config
maps.
So
developers
tend
to
do
that
as
well.
B
B
Whatever
is
available
for
the
organization
and
we're
going
to
see
a
couple
of
examples
of
lateral
escalation
right
later
on
in
the
slides,
or
it
could
be
simply
symbolic
collection
of
networks
that
they've
compromised.
A
Do
you
see
people
actually
sharing
any
of
this
on
the
dark
web
I
mean,
is
it
has
it
reached
a
point
where
people
will
say
hey,
I
got
into
this
one
and
you
know
letting
other
other
other
hackers
have
that
same
way.
In.
B
There
have
been
cases
in
the
past
and
then
you
know
leaks
that
have
occurred
on
which
accidentally
other
attackers
have
stumbled
upon
because
they
found
it
or
pasted
on
facebook
or
something
like
that
with
active,
live
backdoor
credentials
to
something
to
a
possibly
large.
You
know
network
that
was
there.
Facebook
had
a
bounty
that
they
paid
out
for
an
application
that
was
compromised
by
a
bug,
bounty
hunter,
but
what
the
buck
bounty
hunter
realized
was
post
him
compromising
the
application.
B
He
saw
a
lot
of
shells
that
were
already
planted
inside
the
application
right,
and
this
this
was
also
covered
in
the
media
right.
So
it's
I
think
it's
a
definite
possibility
that
attackers
do
share
trusted
attackers,
especially
they
shared.
You
know
their
their
trophy
meetings
are
there
or
if
you
need
some
kind
of
access
to
a
different
network
environment.
Hey
here's
one
like
take
this
off
my
shoulders
and
so
that
that's
possibly
that's
that's
something
possibly
is
happening
out.
There.
B
All
right,
so
we
have
the
next
tactic,
which
is
privileged
escalation,
which
is
the
example
that
I
have
here
is
of
a
cluster
admin
binding
right-
and
this
is
on
my
home
cluster-
that
I
was
running
and
I
created
like
a
bunch
of.
B
B
Attacker
is
able
to
gain
access
to
a
cluster
role
right
that
has
the
ability
or
whether
it
is
bound
to
the
cluster
admin
cluster
binding.
The
token
that
is
generated
from
the
secret.
The
token
of
the
extractor
from
the
secret
would
give
them
complete
access
to
the
entire
kubernetes
cluster,
and
you
could
use
this
token
inside
your
curl
request
that
fit
the
api
server.
B
You
could
create
a
config
file
right,
but
essentially
giving
you
access
to
the
entire
cluster,
and
a
lot
of
you
know
third-party
software
that
you
install
any
workloads
that
you
deploy
right,
keep
flowing,
one
of
them,
for
example,
which
is
a
standard
mlai
workflow
based
product
on
top
of
kubernetes.
B
When
you
deploy
that
onto
your
cluster
and
if
you've
not
counted
the
number
of
cluster
roles
and
roles,
it
creates
inside
the
name
spaces
that
it
creates
about
four
or
five
name
spaces.
The
default
installation
path,
and
it
creates
over
about
70
to
80
different
cluster
groups
and
it's
understandable
because
it
does
a
lot
of
activity
and
it
requires
this
kind
of
credential.
But
a
lot
of
those
cluster
rules
have
privileges
that
they
they
ideally
should.
B
B
But
if
an
attacker
is
able
to
gain
access
to
that
token
game
over
that
they
have
access
to
the
entire
cluster
from
there
escalation
of
privileges
is
an
important
step
right
for
an
attacker
to
gain
access
to
additional
resources
or
if
the
attacker
wants
to
be
in
stealth
mode.
This
is
where
they
would
sit
around
right.
A
couple
of
examples
where
these
attackers
can
escalate
privileges,
reading
secrets
tokens
credentials
to
pull
them
out
to
try
it
out
on
a.
B
They
have
a
service,
token
mapped
to
dim
platform
right.
This
is
accessible
at
the
mouth
point
inside
the
board.
If
you
gained
access
to
a
pod
there's
an
attacker
inside,
you
would
then
be
able
to
access
to
the
service
account
and
the
token
itself,
detecting
which
pods
are
running
as
privileged
parts
and
then
using
an
except
to
gain
access
to
those
parts
from
there
moving
down
to
the
node
right
and
then
from
there
moving
using
a
docker
command
to
move
to
a
different
section
of
the
cluster.
That's.
A
B
Tend
to
do
is
especially
for
managed
clusters,
if
you're,
if
they've
gained
access
to
a
pod
access
to
the
instance.
Metadata
can
allow
reading
of
im
credentials
if
they
have
been
attached
to
the
instance,
for
example,
right
if
you're
running
aws.
B
B
But
I
want
to
ensure
that
I
remain
hidden
or
my
traces
of
all
the
attacks,
the
commands
that
have
been
trying
to
erase
right
the
example
that
I
have
the
screenshot
here
again.
The
ml
on
the
left
is
of
ubuntu
part
that
is
being
created,
but
with
the
name
that
maps
or
matches
something
else,
that's
running
inside
cube
system.
B
If
you
have,
if
you
have
core
dns
right
interactive
system,
if
you
do
a
couple
get
parts,
you
would
see
a
bunch
of
code,
dns
pods
running
right,
but
if
an
attacker
creates,
which
is
what
the
right
side
of
the
screen
shot,
is
if
an
attacker
uses
this
camera
file
and
applies
this
to
your
cluster,
a
pod
is
going
to
be
created
with
the
same
name
as
a
similar
name
as
other
code.
B
Dna
spots
running
and
it's
going
to
be
very
difficult
to
figure
out
which
ones
the
actual
and
which
is
the
attacker
sitting
in
playing
hiding
in
plain
sight
right
so
for
a
partner.
Similarity
is
a
definite
defensive
issue
that
attackers
do
try
the
others
being
the
ability
to
delete
logs
that
parts
create
by
gaining
access
to
the
underlying
node
and
all
mod
have
all
pods
generate
logs
that
are
stored
in
wire,
lock,
pods
and
system,
like
that.
B
The
underlying,
if
you
have
access
to
the
underlying
node
you'll,
be
able
to
pick
this
part
from
delete
the
log
files
from
from
the
directory
right
cuddle,
delete
events.
Hyphen
all
is
a
very
dangerous
dimension.
I've
never
been
unknown,
but
this
it
kind
of
erases
the
entire
event
log
of
kubernetes
right
across
all
main
spaces.
B
The
attacker
could
also
launch
parts
and
reserve
name
spaces
to
match
up
the
workloads.
That's
what
we
saw
with
core
dns
and
the
technique
that
the
threat
matrix
also
talks
about
is
to
hide.
A
B
Rootage
and
ipad
diseases
using
process
right
moving
on
to
credential
access
coming
to
the
you
know,
the
final
parts
of
what
the
attackers
tend
to
do,
they've
now
gone
from
obtaining
access
executed,
their
code
they've
persisted
using
a
backdoor
using
a
current
job.
B
They've
escalated
their
privileges
using
a
cluster
admin
binding
their
divided
defenses
by
starting
a
pod
with
a
similar
name
right
now,
they're
going
to
essentially
try
and
be
comfortable
inside
their
cluster
that
they've
compromised
they're
going
to
now
try
and
see
what
else
is
visible
inside
the
cluster
in
terms
of
secrets.
Right
credentials
are
extremely
beneficial
to
attackers.
B
From
the
viewpoint
of
that,
you
can
reuse
credits
if
required,
and
also
they
allow
access
to
regions
that
you
might
not
have
access,
regardless
of
it,
that
your
status
is
a
plus
statement
or
not
right
applications,
for
example,
if
you
want
to
access
the
application
and
from
there
access
data
right.
So
what
you
have
on
the
left
is
me
trying
to
access
the
kubernetes
api
endpoint
without
any
token,
and
then
on
the
right.
I
am
using.
B
Alternate
regions
once
they've
gained
some
level
of
access.
They
will
look
at
resources.
What
is
visible?
What
else?
Can
you
see
from
your
vantage
point
inside
your
network
right?
They
try
and
reach
protected
regions
which
may
require
credentials.
That
would
you
know
otherwise
they
would.
They
would
hit
the
401
unauthorized
summary
places
where
attackers
tend
to
find
secrets
and
credentials.
The
kubernetes
store
itself
using
the
service
principle
mounted
within
the
underlying
load,
which
is
what
the
example
you
saw.
B
The
pod
upon
mounted
container
sales
account
token
after
everything,
config
maps
spot
descriptions,
hard
coded
within
application
files
right
any
of
these
places
where
secrets
can
reside
would
be
a
good
place
for
credential
access
to
for
the
tactic
to
be
completed,
discovery
is
a
little
I
mean
in
my
personal
opinion.
B
Discovery
comes
a
little
too
late
inside
the
threat
matrix
right-
and
I
say
this
because
most
of
the
techniques
that
this
tactic
has
are
pretty
much
useful
to
an
attacker
if
they're
done
at
the
beginning
of
the
threat
matrix
right
and
for
the
sake
of
completion.
Let's
cover
this
as
well.
What
I
have
here
is
a
screenshot
of
and
a
bash
prompt
inside
a
pod
running
on
akx
right
and
now,
because
the
the
pod
has
privileged
it's
running
in
the
previous
container.
B
I
now
have
access
to
the
underlying
node
right
and
if
you
can
see
the
host
name,
a
case
agent
pool
right,
I
am
from
there
using.
I
actually
didn't
need
to
do
this,
because
the
attacker
pod
itself
would
be
able
to
access
the
metadata
instance
endpoint
address,
which,
for
aws,
azure
and
gcp
is
the
same
169
254,
168
254
and
then
extract
metadata
instance.
Information.
The
metadata
instance.
Information
is
extremely
well
documented
by
all
three
cloud
providers
right
and
you
know
aws
recently
implemented
the
version
two
right.
B
That
requires
a
header
that
has
to
be
passed
to
the
token.
But
if,
as
long
as
you
have
a
shell
access
to
a
place
where
the
168
254
address
is
going
to
be
accessible
right,
it
doesn't
matter
what
header
requirements,
your
you
know,
instance
that
it
requires
you'd
still
be
able
to
gain
access
to
the
instance
manager.
Why
is
this
interesting?
The
instance
penetrates
because
this
provides
information
about
the
instance
that
is
running
like
the
node
being
an
instance.
B
B
If
you
have
im
a
role
attached
to
the
instance,
you
can
actually
extract
the
credentials
from
the
instance
metadata
itself,
which
you
can
then
reuse
into
an
aws
command
right,
the
secret
key
and
access
and
token
that
is
going
to
be
available
through
these
transmitter
data,
another
common
vector
that
it's
actually
the
most
common
attack
vector
if
you
have
pod
access
inside
an
aws
environment.
B
Right,
as
I
said,
this
technique
is
described
too
late
in
the
threat
matrix,
because
most
of
the
attackers
will
obviously
perform
additional
discovery
in
the
earlier
stages.
A
lot
of
these
techniques
are
already
covered.
B
You
know,
in
the
beginning
of
the
tactic,
the
threat
matrix
itself,
either
via
a
cube,
config
or
service
tokens
access
to
the
a
cadence
api
service
obtained
right.
If
an
attacker
has
reached
this
far
already,
the
privileged
access
level
is
received.
At
this
point
of
time,
we
also
saw
the
tcp
ports
to
15
to
250
and
10
to
55
that
give
the
attacker
read,
write
privileges
to
the
cube
api
server,
depending
on
what
port
is
accessible
and
what
kind
of
authorization
is
applicable
to
them.
B
Right
attackers
also
tend
to
perform
additional
network
mapping
using
tools
like
nmap
again,
some
attackers
tend
to
do
this.
Some
attackers
simply
would
read
the
service
and
end
point
information
using
using
the
api
itself
right.
That
is
pretty
approximate
of
what
that's
actually
exactly
what
is
running
within
the
network,
so
you
don't
need
to
do
an
in-app
scan
in
the
on
the
part
of
the
service
network
from
your
access
that
you've
obtained
right
for
management
is
again.
Access
to
the
underlying
cloud
platform
is
possible
through
you
know,.
A
B
Account
that's
mounted
right
or
secret
saturday,
through
the
instance
metadata
api
endpoint
from
moving
from
pod
to
the
node
or
from
port
to
the
cloud
directly
right.
So
that's
that's
what
you'd
end
up
doing
in
your
discovery
tactic.
As
I
said
a
lot
of
those
repeats.
The
same
applies
to
lateral
movement
as
well.
B
If
you
notice,
the
techniques
that
I
mentioned
in
lateral
movement
are
a
bunch
of
things
that
we've
already
covered
in
the
past
right
because,
as
an
attacker,
when
you're
moving
from
initial
access,
all
the
way
to
impact
you
tend
to
end,
you
tend
to
do
a
bunch
of
lateral
movement.
Things
parallely,
while
you're
moving.
A
B
The
attack
matrix
right
this
is
an
example
of
a
dashboard
access
that
I've
had
once
I
have
gained
access
to
cubeconfig.
I
can
simply
you
know
proxy
the
proxy
access
to
the
dashboard
and
access
it
from
my
local
machine,
and
then
the
dashboard
itself
allows
you
to
gain
access
to
a
pod.
You
can
gain
a
shell,
and
then
you
have
access
to
any
configuration
information
from
their
own.
Using
this
shell,
you
can
gain
access
to
the
cloud
provider
if
this
is
hosted
on
a
managed
cluster.
B
A
B
Yeah,
okay,
so
the
question
I
think
we're
talking
about
right
at
the
beginning
of
initial
access.
Right,
as
I
mentioned,
to
gain
initial
access.
The
attacker
requires
some
sense
of
where
the
cluster
is
located.
I
could
run
an
internet
wide
sweep
to
figure
out
common.
B
You
know
standard
the
apis
hosted
on
six
four
four
three
exposed
to
the
internet,
all
four
four:
three:
it's
an
http
server,
it's
like
any
other
api
server
on
the
internet
right,
but
identifying
that
it's
a
kubernetes
dashboard
is
a
tricky
one,
because
there's
for
the
default
kubernetes
apes,
server,
there's
no
teletale
sign
in
the
headers.
That
tells
you
it
is.
B
It
is
an
you
know,
a
kubernetes
endpoint
right,
but
I
showed
you
an
example
at
the
beginning
or
where,
if
you
have
priority
and
fairness
for
example,
features
enabled
a
specific
header
comes
up
in
the
in
the
responses
that
tells
you
that
this
is
the
kubernetes
transform.
Sorry,
this
is
a
kubernetes
api
right
and
in
most
cases
you
do
require
authorization.
B
But
there
are
a
bunch
of
examples
on
the
internet
live
right
now
that
don't
require
authorization
to
access
the
apism,
and
this
could
simply
be
honeypot
sitting
out
there
for
people
like
you
and
me
trying
to
figure
out
what
exploring
right,
but
the
fact
that
not
all
of
them
indianapolis
is
a
definite.
You
know,
possibility
right
and
again
obtaining
access
to
a
cubeconfig
file
because
you've
compromised
a
developer
laptop
you've
compromised.
B
You
know
an
application,
that's
hosted
on
kubernetes
from
there
you've
the
example
that
I
gave
was
the
ssrf
bug
in
etsy
from
there
accessing.
You
know
the
environment
variables
that
contains
the
certificates
right.
You
could
construct
your
own
config
and
then
access
the
apis
level.
So
by
finding
the
endpoint
is
port
scan
away
or
using
an
open
source
of
information
like
in
and
authorization
is?
B
That
piece
requires
some
work
where
you
have
to
either
find
an
express
dashboard
or
a
compromised
image
in
a
registry
that
those
are
the
techniques
that's
listed
there
and
my
favorite
being
the
application
vulnerability.
You
know
using
an
ssrf
or
something
similar
that
allows
you
to
gain
access.
Shell
access,
possibly
to
a
pod
running
inside
the
community's
cluster.
A
B
Yes,
because,
let's
see,
if
you're
talking
about
an
application,
vulnerability,
an
application,
that's
running
on
top
of
kubernetes,
the
authentication
layer
is
never
reached
right
because
you're
using
the
application,
which
is
running
on
kubernetes
as
your
window
right
you,
you
compromise
the
app
you're
already
inside
the
cluster.
You've
gained
shell
access
to
the
pod
right
and
you're
already
inside
the
cluster,
and
once
you're
inside
the
cluster.
You
can
access
a
bunch
of
things
based
on
where
you
are,
you
could
use
the
service
token,
you
could
gain
privileges,
go
to
the
node
use.
A
B
Yeah
I'll
just
wrap
this
up.
The
the
miter
attack
framework
reaching
the
impact
tactic
right.
The
essential
idea
is
for
every
attacker,
as
I
said,
could
be
a
symbol,
a
trophy
in
their
bucket
of
clusters
that
have
compromised,
which
is
the
rarer
version,
but
there
is
obviously
some
motive
that
attackers
go
with
right
and
we're
looking
at
either
access
to
data
they're
looking
at
resource
hijacking.
B
In
this
particular
case,
this
is
tesla's
dashboard
communities,
dashboard
which
the
folks
at
red
lock
when
they
gained
access
to
the
kubernetes
dashboard,
and
they
realized
that
there
was
already
a
crypto
mining
deployment
that
was
running
on
inside
the
cluster
right
and
the
it
took
time
for
the
folks
at
tesla
also
to
discover
this.
They
actually
figured
it
out
when
dreadlock
folks
told
them
essentially,
because
the
deployment
that
was
running
did
not
start
any
large
instances
or
was
not
using
a
lot
of
resources.
So
they
wanted.
B
The
attackers
wanted
the
crypto
mining
to
happen,
but
they
kept
the
footprints
really
minimal
so
that
it
didn't
flag
any.
You
know
monitoring
that
they
had
in
place
right,
so
that
kind
of
little
stealthy.
So
this
was
hijacking,
definitely
something
that
you
and
I
spoke
about
right.
So
this
this
is
a
definite
outcome
of
what
attackers
would
look
for
right.
B
The
potential
end
games,
some
of
them
documented
data
destruction
by
rolling
back
deployments,
removing
volumes
claims
if
you're
a
cluster
admin,
you
could
possibly
bring
down
the
entire
cluster,
highlighting
the
resources
to
perform
monitoring
tasks
ordering
any
state
to
create
a
denial
of
service
right.
Any
of
these
could
be
the
impact
that
the
attacker
would
be
looking
for.
B
Okay,
that's!
This
is
our
attack
tactic
that
we've
taken
the
route
that
we've
taken
release
to
the
impact
right
and
we
have
a
quick
poll
landing.
We
want
to
get.
Let's
see
what
everyone
says.
A
All
right,
great
yeah,
this
is
our
last
poll
and
you
know
so
you
know
I
guess
the
question
here.
Is
you
know
how
do
you
ensure
security
of
your
cloud
infrastructure
and
cluster
today?
You
know
what
are
you
already
doing
so?
Do
you
rely
on
the
cloud
platform
providers
to
protect
it
and
trust
the
defaults?
A
Are
you
doing
any
kind
of
you
know,
pen,
testing
and
internal
reviews?
Have
you
done
any
perimeter
hardening
hardening
or
implementing
least
privileges?
You
know,
following
cis
best
practices,
there's
a
kubernetes
cis
benchmark
out
there
that
we,
for
example,
aqua's
cube
bench,
will
help
you
with
and
then
you're
doing,
both
numbers,
two
and
three
with
log
monitoring
analysis
and
alerting
you're
all
over
this.
So
let's
go
ahead
and
give
folks
10
or
20
seconds
here
to
answer
the
poll
and
then
we'll
share
the
results.
A
Sure
looks
like
we
still
have
some
numbers
coming
in
yeah.
I
think
this
been
a
great
talk,
riyaz.
I
know
we'll
wrap
up
here
in
a
minute,
but
I
think
been
a
lot
of
questions
along
the
way
we'll
get
to
q
a
before
we
before
we
go.
So
let's
go
ahead
and
share
those
results.
A
People
are
pretty
confident
that
they're
they're
there,
you
know
more
than
half
saying
they
they've
got
this
down
and
then
a
bunch
more,
I
would
say,
relying
on
you
know
some
core
best
practices
in
terms
of
hardening
and
privileges
yeah.
This
is
what
do
you
think
about
these
answers?
They
consistent
with
what
you
see
in
the
real
world.
B
Yes,
so
nobody
trusts
the
cloud
platform
itself
to
to
do
the
job
completely
right,
so
that
was
just
a
filler
option
that
now
this
is
what
I
see.
What's
the
distribution
around
two
three
and
four
four
being,
I
think,
in
my
opinion,
the
least
that
people
would
do
in
the
personally
people
that
I've
spoken
to
right.
I
can't
see
the
shadow,
so
what
what's
the
option
with
the
fourth
one?
What
was
the
spread.
A
A
Yeah
yeah
you're,
looking
at
your
slides
in
your
video,
it's
always
tricky
anyway,
all
right
great.
Let's,
let's
get
on
to
the
recommendations.
What
do
you?
How
do
you
suggest
people
deal
with
this.
B
Right
so
I
have
a
bunch
of
tips
and
tricks
that
you
know
over
a
period
of
time.
I've
collected,
especially
when
I
was
trying
to
figure
out
the
whole
kubernetes
technology
right
and
coming
from
an
offensive
security
world.
What
would
kubernetes
administrators
do
that?
Would
you
know
prevent
me
from
gaining
access
of
figuring
out
what?
What
is
the
state
of
the
cluster
right?
Keeping.
B
Updated
is
a
no
brainer.
This
is
something
that
your
cloud
providers,
you
know
if
you're
trying
it
as
a
managed
cluster.
This
is
something
that
they
would
take
care
of
as
long
as
you
only
upgrade
bit
right.
I
think
this
version
1.20.4,
which
is
currently
what
kubernetes
is
right
and
they
have
different
patch
metrics
right,
so
some
of
them
they
support
patches
over
here,
I
think
version
1.18
and
below
is
for
nine
months
right,
just
just
be
conscious
of
water
version
of
humanities
and
try
and
keep
it
updated.
B
Restricting
the
access
definitely
to
the
nodes
to
only
trusted
hype
addresses
is
something
that
you
should
definitely
practice
using
network
policies
to
prevent
attackers
from
jumping
between
name
spaces
right.
If,
even
if
the
attacker
has
compromised
one
part
of
the
cluster,
they
should
not
be
able
to
see
something
else,
or
even
in
c
they
should
not
be
able
to
gain
access
to
it.
Using
you
know,
lateral
movement
within
the
cluster
network
policies
comes
to
you
right.
There
definitely
audit
your
roles,
binding
service
accounts.
I
am
access,
look
for
shadow
admins
use.
B
You
know
the
cluster.
The
command
is
classified
judiciously
right
audit.
All
your
cluster
roles
and
you
know
any
role.
Binaries
other
than
specific
service
accounts
might
have
created,
scan
images
in
your
pipeline,
using
tools
3d,
as
I
mentioned,
and
a
wonderful
tool
to
identify
vulnerabilities
that
your
images
may
have
that
may
become
potential
security
hazards,
remove
deployments
that
are
no
longer
required
and
definitely
run
pods
with
a
security
context
where
you
have
a
user
defined
right,
say
definitely
say
no
to
that
today.
B
If
you
go
back
and
look
at
your
cluster
and
if
you
do
a
git
pods
see
how
many
of
them
describe
your
points
and
see
how
many
of
them
are
running
right
so
that
that
itself
could
be
a
problem,
use
namespaces
to
create
logical
segregation.
Segregation
do
not
store
secrets
in
environment
variables,
especially
pod
description,
if
you
have
them
ensure
minimum
visibility
from
the
outside
right.
It's
like
a
defensive
approach
that
you
take
definitely
take
application
security
consideration.
B
You
could
have
the
most
hardened
cluster,
but
if
your
application
is
vulnerable,
the
attacker
has
a
direct
door
inside
your
cluster
right
being
battery
of
suspicious
looking
outbound
traffic
use,
hardening
guidelines,
cis
benchmarks,
highly
recommended
for
kubernetes
and
tools,
like
bench
that
you
mentioned
earlier,
to
identify
potential
use,
configurations,
monitoring
and
you
know,
creating
an
actionable
roadmap
right
like
what
a
cluster
is
doing.
B
Who
has
what
kind
of
access
what
privileges
different
components
have
and
actioning
any
monitoring
alerts
that
you've
got
is
a
definite
way
to
ensure
your
cluster
remains
hard
and
insecure.
At
the
end
of
the
day,
I
plan
on
writing
a
blog
post
with
expanding
on
all
the
tips
that
I've
mentioned
here
with
examples
on
how
you.
B
A
A
Go
ahead
and
a
couple
more
questions
that
we
can
look
at
here.
You
know
we
have
just
a
few
more
minutes,
but
you
know
again,
you
know
thank
you
for
sharing
sharing
this.
We
did
have
a
number
of
people
say
they
thought
this
was
great,
and
can
they
get
a
copy
of
it
so
there
we
will
be
sending
that
out.
After
so
people
will
be
able.
B
To
see
that,
and
just
just
to
add
sorry
just
to
add
the
xaml
files
that
I
described
in
the
presentation,
I'll
be
tweeting,
you
know
like
a
github
repository
where
all
the
answers
are
hosted,
so
you
can
try
them
out
in
your
test
clusters
at
home
right
and
our
twitter
is
right
here
on
the
screen.
That's
my
twitter
handle
and
you
can
definitely
reach
me
on
my
email
address
at
cloud.com.
Take
a
look
at
our
blog
as
well.
We
have
a
lot
of
interesting
blog
posts
that
we've
written
and.
B
Miter
thread
framework
as
well
right.
So
that's
what
everyone's.
A
So
there
was
a
question
thanks
for
that.
I
think
people
have
your
email
and
then
you
can
reach
out
a
couple
of
questions
here,
one
in
a
managed,
kubernetes
environment.
So
you
know
something
like
aks
or
eks.
A
Isn't
the
node
managed
by
the
cloud
provider
and
in
that
case,
would
the
instance
metadata
endpoint?
You
know
end
up
giving
up
cloud
managed,
node
details.
B
That
that's
a
good
one.
So,
even
though
the
cluster
is
managed
by
aks
and
aws,
the
the
master
node
is
what
you
don't
have
access
to
right,
but
the
worker
nodes.
Definitely
you
can
get
a
shell
and
that's
the
screenshot
I
had
earlier
of.
B
Let
me
try
and
figure
out
see
what
it
is
yeah.
This
is
a
shell
that
I've
obtained
on
the
worker
node,
and
this
remains
at
a
managed
cluster
on
a
case
right.
So
the
instance
information
is
aligned
is,
is
off
the
worker
node
of
the
managed
customer,
and
so
the
information
definitely
is
part
of
the
managed
kubernetes
environment,
but
there
are,
there
is
definitely
going
to
be
some
information
that
is
going
to
become
useful
to
the
attacker
based
on
how
you've
configured
this
right.
A
All
right,
we
have
one
more
question
we're
running
out
of
time,
but
what's
the
someone
said
they
were
looking
for
your
recommendations
on
the
best
option
for
secrets
management
on
aks,
any
any
suggestions.
B
I
don't
have
any
personal
favorites
okay,
because
I'm
yeah,
I'm
coming
from
the
offensive
background
right.
So
I've
heard
world
is,
is
a
good
use
case,
but
I'm
not
sure.
A
All
right,
yeah,
I
think
a
lot
of
people
are
using
vault
in
that
environment
as
well
all
right.
Well,
let's
go
ahead
and
wrap
up,
but
thanks
again
you
know
great
talk.
You
know,
I
think
it's
just
so.
You
know
it's
so
great
to
see
the
from
the
perspective
of
the
attacker
and
what
it
looks
like,
and
you
know
the
really
technical
presentation
in
terms
of
how
things
really
look
and
work.
A
A
Our
tenth
of
this
series
and
you'll
have
that
to
to,
and
you
have
the
link
to
register
as
well,
so
you
can
stop
by
the
aquasec.com
website
and
just
sign
up
as
if
that's
easier,
but
thanks
again,
riyaz-
and
I
appreciate
you
sharing
your
knowledge
with
with
with
our
audience
and
everybody
have
a
great
day
and
stay.