►
From YouTube: Journey to Cloud-Native, K8s and Trying to Secure It. - Graham E. Chukwumaobi, Independent
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.
Journey to Cloud-Native, K8s and Trying to Secure It. - Graham E. Chukwumaobi, Independent
There are so many resources online about containers, Kubernetes, and Cloud security available to anyone who wants to know/learn about these technologies; this can be a good thing but can also be very confusing and chaotic, especially for people who are new to Cloud-Native and Open-source technologies/software. The first results returned by Google aren't usually the best for someone starting down their path in Cloud-Native Technology. It is even more challenging if you come from a very under-represented background in technology, where it is difficult to ask random people questions without feeling like a burden. This talk aims to guide newbies in their journey into Cloud-Native technologies such as Linux, containers, K8s, Iac, and securing clusters.
A
Good
morning
everybody
nice
to
meet
you
guys.
My
name
is
gray
I'm
chukumo
B,
that's
my
Twitter
handle
I'm,
not
I.
Think
I've
barely
been
on
Facebook
for
a
while.
So
that's
why
I
didn't
bother
putting
that
ball
yeah.
You
can
find
me
on
Facebook,
with
my
name
and
on
Instagram,
so
today,
I'm
going
to
be
talking
to
you
guys
about
my
journey
to
Cloud
native
kubernetes
and
trying
to
secure
it.
So
this
talk
is,
you
know,
I'll
say
for
the
newbies
people
trying
to
delve.
A
You
know
into
the
whole
Cloud
native
bandwagon,
the
ecosystem
and
then
just
to
give
you
like
a
route
on
how
to
go
about
learning
these
Technologies.
So
for
me
it
all
started.
You
know,
with
the
workshop
when
I
was
still
in
uni
during
my
final
year,
studying
software
engineering
at
Cardiff
met
so
and
I
think
it
was
six
of
my
friends.
We
had
like
a
friend
group
where
we
try.
You
know
to
attend
as
much
workshops
and
seminars
as
possible.
A
You
know
possibly
ones
that
will
give
us
some
badge
to
add
to
our
LinkedIn
profile
to
help
us
with
our
job
search
and
job
hunt.
So
that
was
how
we
came
across.
You
know
the
kubernetes
workshops,
and
you
know
we
all
jumped
on
it
and
then
you
know
it
was
I'll
say
it
was
a
good
experience.
Then,
even
though
you
know
everything
was
so
vague
and
you
know
so
alien
to
us
at
the
time
so,
but
they
instructed
a
very
good
job.
A
You
know,
starting
to
explain,
give
us
an
overview
about
the
different
architecture
and
the
monolithic
architecture
and
the
micro
service
architecture.
So
for
me,
at
the
time
I
got
to,
you
know
understand
that
all
the
soil
I've
been
developing.
You
know
using
the
monolithic
architecture
without
even
now,
knowing
about
it.
You
know
went
on
after
the
research
to
after
the
workshop,
to
do
my
own
research
to
really
get
to
understand
this
different
architectures.
A
So
you
know
for
me,
I
was
like
if
we've
been
developing
using
this
architecture
and
everything
has
been
working
fine,
so
why
the
need
for
the
whole
microservices
and
kubernetes,
because
everything
sounded
so
difficult.
So
I'm
just
going
to
touch
on
some
of
the
advantages
of
Monolithic
architecture
and
you
know
the
disadvantages
and
then
we'll
move
from
there.
So
I
guess
one
of
the
key
advantages
of
the
monolithic
architecture
will
be
that
you
know
it's
very
easy
to
develop.
You
know
you
could
develop
an
entire
application
and
get
it
to
Market.
A
Multi-Complica
applications
have
fewer
parts,
so
so
there
are
fewer
components
to
manage
and
to
fix-
and
you
know
all
in
all
everything
is
self-contained
in
and
it
makes
it
easier
to
deploy
your
application.
Sorry
and
then
uncomplicated
testing
and
debugging
testing
and
debugging
is
you
know
a
very
big
part
of
the
debate
of
Monolithic
architectures
versus
the
microservice
architecture
debates.
You
have
to
test
all
the
parts
of
an
applications
of
an
application
separately
in
regards
to
your
microservices.
A
You
have
to
test
that
they
work
properly
and
also
test
that
each
service
fits
together
and
communicates
properly,
and
then
you
also
have
the
case
of
cash.
Caching,
dependencies
and
data
assets.
Forgive
my
pronunciation.
English
is
not
my
first
language,
so
you
know
that,
but
with
regards
to
monolithic
architecture,
these
these
are
not
the
case,
because
the
application
is
fitted
as
a
single
unit
and
works
together
as
a
whole.
A
You
can,
you
know,
do
everything
quickly
and
easily
from
a
central
login
system,
but
it
also
has
its
own
disadvantage
in
the
sense
that
you
it's
less
scalable.
So
it's
the
monolithic
architecture,
because
the
software
is
tightly
coupled.
You
know
it
can
be
very
difficult
to
like
scale
the
software
for,
for
instance,
if
you
wanted
to
like
Advance
a
particular
feature
or
part
of
your
application,
you
literally
have
to
take
down.
You
know
the
whole
application
just
to
alter
a
single
feature,
it's
difficult
to
adapt
to
new
technology.
A
As
mentioned
it's
it's
a
tightly
coupled
architecture.
So
if,
for
instance,
you
take
a
music
application,
for
example,
where
the
you
have
your
catalog
is
tightly
coupled
to
like
the
purchase
and
the
the
Play
services,
if
you
wanted
to
like
just
maybe
alter
the
features
of
the
catalog
or
the
play
purchase
like
I
said
earlier,
you
still
have
to
like
you
know,
take
the
whole
application
down
just
to
be
able
to
alter
that
feature,
and
then
there
is
very
high
dependencies
between
the
functionalities
of
the
monolithic
architecture.
A
A
Again,
if
you
know
one,
one
of
them
should
go
down.
The
whole
application
will
be
affected
so,
but
in
with
regards
to
the
microservice
architecture,
which
is
you
know,
basically
a
style
of
a
large
application
built
as
a
collection
of
small,
independently
Deployable
Services.
As
you
can
see,
you
know
in
with
this
example,
so
these
Services
communicate
with
each
other
through
apis
and
are
designed
to
be
Loosely
coupled
you
know
so
that
they
can
be
developed
and
tested
and
deployed
independently.
A
Microservice
architecture
also
enables
faster
development
and
scalability
and
makes
it
easier
to
evolve
and
maintain
your
application
over
time,
because
you
know,
as
you
can
see,
with
the
different
Services,
each
service
can
be
developed
or
you
know
managed
by
a
different
team,
and
they
can
make
use
of
what
that,
whatever
technology,
that
they
are
very
comfortable
with,
and
then
you
know
it
also
has
his
course
comes
with
his
own
pros
and
cons.
You
know
regards
to
microservices
it's
very
scalable,
it's
easier
to
scale.
A
A
It
improves
the
deployments
of
your
application.
Microservice
can
be
deployed
independently
in
to
allow
it
for
faster
and
more
frequent
release.
It's
flexible
allows
for
greater
flexibility
in
choosing
technology
Stacks.
So,
like
I
said
earlier,
each
of
the
services
can
be
created
using
whatever
technology
Stacks,
that
the
team
or
the
developer
is
comfortable
with,
but
it
also
has
its
own
disadvantages.
A
You
know,
which
includes
complexity,
microservice
architecture
at
you
know,
complexity
in
terms
of
communicating
and
testing
and
deployment
dependency
management
between
the
micro
Services
need
to
be
managed
carefully
to
avoid
errors
and
delays,
and
we
also,
you
know,
comes
with
the
issue
of
network
latency.
Increased
Network
calls
between
these
Services
can
lead
to
slower
performance
and
debugging
is
also
more
complex.
In
microservices,
with
and
environment
issues
can
span
between
multiple
service
and
also
testing
micro,
a
micro
service.
You
know
application
can
be
more
demanding.
A
You
know
you
have
to
test
the
individual
service
on
on
their
own
and
also
test
that
they
communicate
with
each
other
as
intended.
So
when
stacked
up
together
side
by
side,
you
start
to
understand.
You
know
why
microservice
started
becoming.
You
know
more
popular
for
me,
you
know
being
I'll,
say
relatively
new
within
the
industry.
I
can't
really
tell
how
far
you
know
back.
You
know
we
could
go
with
microservices,
but
in
some
real
monolithic
application
is
built
as
a
single
unified
unit.
A
While
you
know,
microservices
is
a
collection
of
smaller,
independently
deployables
and
service.
So
in
the
case
of
the
example
we
gave
above,
for
instance,
if
you
wanted
to
go
about,
you
know,
program
or
developing
such
service
you're
going
to
have
like
your
rest,
API
crowd
for
the
account
DB
or
the
user
DB.
Whatever
case
it
may
be,
you
know
programmed
like
in
this
case
I.
Just
you
know,
try
to
sketch
or
like
call
it
a
draft
code,
for
you
know
the
account
DB
using
fast
API.
You
also
have
your
rest.
A
Api
crowd
for
the
event
inventory,
rest
API
and
then
for
the
shipping
too.
So,
as
you
can
see
here
in
the
project
directory,
all
the
different
service
or
rest
API
are
in
their
own
directory.
This
is
just
to
show
you
know
that
this
service
can
be
developed
by
a
different
team
on
its
own
and
you
know,
be
a
full-fledged
application
on
its
own.
A
You
know,
but
as
long
as
like
the
design
or
the
requirements
for
the
application
is
followed
and
then
the
apis
are
able
to
communicate
with
each
other,
both
on
Endeavor
and
in
prod.
So,
as
you
can
see,
for
each
service
in
its
own
directory
has
its
own
requirements.txt
file
its
own
Docker
file.
But
in
this
case
you
also
have
your
Docker
file
for
the
whole
application
and
your
Docker
compose
file,
or
you
know
going
to
explaining
those
down
the
slide.
A
A
Observability.
Sorry,
monitoring
and
collecting
data
from
applications
and
services
to
gain
insights
about
their
behaviors
and
performance,
and
also
it
also
encourages
resilience
and
designing
applications
to
be
highly
available
and
withstand
failure
issues.
So,
but
before
we
go
into
details
with
container
containerization
of
application,
I'll
just
like
to
like
touch
on
I'm,
not
really
go
into
full
details,
but
just
you
know
I'm,
so
you
can
see
the
difference
between
VM,
virtual
machines
and
containerization,
because
VMS
was
the
solution
before
containerization
became
a
thing.
A
So
VMS
is
basically
a
software
implementation
of
a
physical
machine
which
allows
multiple
operating
systems
to
run
on
a
single
host.
Each
VM
runs
on
its
own
operating
system,
which
provides
an
isolated
environment
for
your
application
to
run.
While
the
container
is
a
lightweight,
Standalone
executable
package
that
contains
everything,
an
application
needs
to
run,
including
your
code,
your
runtime,
your
system
tools,
your
libraries
and
your
settings.
Containers
uses
the
host
operating
systems
Canal,
which
makes
them
more
lightweight
and
efficient
than
VMS.
So
in
summary,
VMS
a
VM
is
a
full-fledged
and
virtualized
environment.
A
While
your
container
is
a
lightweight
isolated
environment
that
just
shares
the
host
canals
operating
system,
so
in
in
this
case,
from
our
example,
a
micro
service
application
you'll
see
that
each
of
the
surveys
it's
on
its
own
separate
container,
specified
by
the
black
rectangle.
So
containerization
has
really
become
a
popular
approach
for
packaging
and
deploying
applications
in
recent
years.
It
offers
several
benefits
like
portability.
A
Containers
can
run
on
any
system
as
long
as
that
system
supports
containerization
technology
in
makes
it
very
easy
to
move
application
between
different
environments,
such
as
from
development
to
production,
containers,
support
isolation.
They
provide
a
level
of
isolation
for
applications,
which
means
that
they
are
isolated
from
each
other
and
from
the
host
system.
This
reduces
the
risk
of
conflict
between
different
applications
and
their
dependencies.
A
A
It
can
be
version
controlled,
container
image
can
be
versioned
and
stored
in
a
container
registry,
and
you
can
easily
roll
back
to
a
previous
version
and
with
all
these
things
about
containers
and
the
features
they
bring
to
the
table
like
they're
scaling
up
and
down
you
know
of
your
containers
depend
depending
on
the
changing
change
of
Demands.
You
know
how
do
we
go
about
implementing
all
these
things,
I'm,
making
sure
that
you
know
everything
works
as
intended.
We
can
scale
up
and
down.
You
know
as
required.
A
This
really
is
where,
as
you
must
have
guessed,
you
know,
kubernetes
comes
in
so
kubernetes,
which
is
often
called
KS
for
for
in
shorts,
is
a
container
orchestration
system
for
automating
the
deployments
scaling
and
management
of
containerized
application,
I
hope
I'm,
not
far
behind
that
time.
I
think
I
started
this
slide
too
early.
A
So
my
time
I
think
is
wrong,
so
it
was
originally
developed
by
Google
and
is
now
maintained
by
Cloud
native
cncf
kubernetes
provides
a
platform
agnostic
way
to
manage
and
orchestrate
containers
allowing
developers
to
focus
on
writing
code
instead
of
managing
infrastructure.
It
also
provides
some
of
the
following
features.
Like
automatic
bin
packing
or
you
automatically
schedules,
containers
to
run
on
the
most
appropriate
nodes
available,
it
provides
self-healing
capabilities.
Containers
can
automatically
detect
and
replace
field.
Sorry
kubernetes
can
automatically
detect
and
replace
field
containers.
It
provides
service,
Discovery
and
load
balancing
capabilities.
A
It
has
a
built-in
service,
Discovery
mechanism,
which
allows
containers
to
automatically
discover
and
communicate
with
each
other.
It
also
provides
loads
balancing
capabilities
that
automatically
distributes
traffic
amongst
multiple
replicas
of
a
container.
He
has
the
automated
rollouts
and
rollback
features
that
allows
for
Auto
method,
rollbacks
of
rollouts,
of
new
versions
of
an
application
which
makes
it
easy
to
update
applications
without
downtime.
It
also
has
the
secret
and
configuration
management
features
that
allows
to
that
allows
for
the
Secure
Storage
of
your
secret
password
and
the
increase
encryption
keys.
A
A
So
for
me,
at
the
time
you
know,
with
this
whole
knowledge,
you
know
from
the
workshop
and
from
personal
research.
It
was
back
to
you
know
usual
for
me,
but
luckily
I
started
studying
my
masters,
which
was
in
cyber
security
and
was
a
two
years
program.
So
we
had
the
option
of
doing
our
third
I
think
it
was
the
third
semester
you
either
research
on
the
topic
or
you
go
for
an
internship,
so
I
I
I
went
for
an
internship
and
I
was
lucky
enough.
A
I
got
three
of
us
two
for
software
engineering,
then
one
for
a
cloud
native
devsecups
internship
and
as
you'd
have
guessed
I
went
for
it
so
for
it
was
really
an
opportunity
for
me
to
really
get
hands-on
experience
with
Cloud
native
Technologies
like
kubernetes
and
Docker,
and
you
know
really
delve
into
it.
Big
time
and
I
mean
it's
been.
A
You
know
for
me,
Cloud
native
since
then,
and
I'm
doing
the
luxury
of
experienced
colleagues,
you
know
during
my
internship
I
was
able
to
ask
them
the
best
approach
and
best
route
or
the
best
way
to
go
about
learning
these
tools
and
most
of
them.
You
know
we
are
like
of
the
opinion
of
getting
comfortable
with
the
Linux
system.
First
then
delving
into
containers
and
then
eventually
kubernetes,
so
yeah
I
brushed
up
on
my
Linux.
A
You
know
abilities
because
I've
always
been
a
Windows
guy
and
then,
after
that,
you
know
where
I
delved
head
deep
into
containers.
I
was
able
to
really
understand
containers
how
to
create
container
from
writing
your
Docker
file
for
your
application
and
then
creating
a
Docker
image,
a
container
image
from
your
Docker
file
using
the
docker,
build
command
and
then
eventually,
a
Docker
container
with
the
docker
run
command,
got
to
understand
how
to
pull
and
push
container
images
to
container
Registries.
A
Linuxware
of
the
I
think
the
main
one
was
the
upscale
20-day
upscale
channel
on
Reddit
and
then
some
YouTube
resources
and
then,
after
you
know,
getting
to
understand,
Docker
images
how
to
create
mine
and
how
to
make
use
of
images
already
available
on
container
registry.
This
is
just
an
example
of
a
Docker
file
and
then
really
understanding
the
specifications
for
building
containers.
You
know
how
to
make
use
of
like
Ci,
CIS
benchmarks
or
just
really
understanding
your
application
to
create.
A
You
know
to
be
able
to
write
a
Docker
file
that
is
going
to
really
run
your
application
properly.
The
way
you
want
it,
or
sometimes
just
following
you
know
an
intern
internal
specification
depending
on
the
organization
you're
working
for
so
you
know,
I
was
really
I,
would
say
very
comfortable
with
container
at
the
time
and
then
went
on
to
really
understand
kubernetes.
So,
for
this
is
just
a
basic
overview
of
the
features
or
architecture
of
kubernetes.
A
So
some
of
the
features
like
you
can
see
here,
the
master
node,
which
is
the
node.
The
master
node,
is
the
control
plane
node
of
a
kubernetes
cluster,
it's
responsible
for
maintaining
the
desired
State
and
ensuring
that
the
actual
State
matches
the
desired
State.
You
have
your
worker
nodes.
The
worker
nodes
are
the
machines
that
run
your
containerized
applications
and
and
they
communicate
to
the
master
node
to
receive
instruction
on
what
to
run
and
how
to
run
it.
A
Each
each
worker
node
runs
a
container
runtime
such
as
Docker
cubelet,
and
it
communicates
with
the
master
node
and
ensures
that
the
desired
state
of
the
cluster
is
always
maintained.
Then
you
have
your
Cube
API
server,
which
is
the
key
component,
one
of
the
key
components
of
the
kubernetes
control
plane
that
exposes
some
restful.
Api
endpoints
I
think
you
can
see
them
there
that
can
be
used
to
perform
various
operations
on
the
cluster,
including
some
crowd
operations
on
resources
such
as
Sports
Services
deployments.
A
It
communicates
with
the
hcd
data
store
to
retrieve
and
update
the
states
of
the
cluster
and
the
communicate
to
the
cubelets
on
each
worker
node
to
ensure
that
the
actual
state
of
the
cluster
matches
the
desired
State.
You
also
have
your
Cube
kubernetes
controller
manager,
which
is
a
component
that
runs
as
part
of
the
kubernetes
control
plane.
It
is
responsible
for
running
various
controllers,
like
your
replication
controller,
your
endpoint
controller,
namespace,
controller
service
and
token
controllers.
A
These
controllers
are
responsible
for
maintaining
the
desired
state
of
the
cluster,
for
example,
ensuring
that
the
number
of
replica
pods
desired
is
running
on
the
cluster.
You
also
have
your
kubernetes
scheduler,
which
is
a
component
that
runs
as
part
of
your
kubernetes
control
plane.
It's
also
responsible
for
scheduling
pods
on
worker
nodes
in
the
cluster.
The
scheduler
receives
specifications
from
the
cube,
API
server
and
the
size
assigns
them
to.
You
know
the
appropriate
worker
nodes
based
on
various
factors
such
as
available
resources,
constraints
and
Affinity
rules.
A
You
have
your
kubernetes
cubelets,
which
is
a
lightweight
agent
that
runs
on
each
worker
nodes
in
a
kubernetes
cluster.
It's
responsible
for
ensuring
that
the
desire
state
of
the
cluster
is
reflected
on
the
nodes
he
runs
on,
and
then
you
have
your
kubernetes
proxy,
which
is
a
component
that
runs
on
each
worker
nodes
of
your
kubernetes
cluster
and
responsible
for
maintaining
the
network
roads
rules
on
the
Node
and
for
forwarding
traffic
to
the
correct
Port.
A
Then
your
hcd,
your
hcd,
is
a
distributed
key
store
that
is
used
by
kubernetes
as
a
backing
store
for
all
its
for
all
its
cluster
data.
It
stores
the
configuration
data
for
the
kubernetes
control,
plane
and
all
objects
in
the
cluster.
You
also
have
your
container
engine,
which
is
the
the
software
responsible
for
managing
the
life
cycles
of
containers,
including
you
know,
starting
stopping
and
managing
the
con.
The
resources
of
the
containers.
A
So
in
a
situation
where
you're
creating
a
micro
service
like
that,
and
you
wanted
to
test
them,
you
know
you
can
make
use
of
the
docker
compose,
which
is
a
tool
for
defining
and
running
multiple
container
application,
container
or
Docker
applications.
It
allows
you
to
define
the
service
that
makes
up
your
application.
You
know
in
a
single
Docker
compost
file
and
then
you
can
start
start
them
and
manage
them
like
in
our
case.
A
I,
don't
know
if
you
can
see
it,
you
see
we
have
the
user
service,
the
shipping
service
and
the
inventories
service,
in
this
case,
they've
all
been
converted
to
a
Docker
image,
the
inventory
image,
user
image
and
shipping
image,
and
then
we
also
have
a
network
work.
You
know
for
to
ensure
that
all
the
services
are
running
within
the
same
network
and
we
have
our
database
there.
A
You
just
write
your
deployment
configuration
which
defines
the
desired
state
of
the
application,
the
resources
it
needs
to
run
and
then
using
the
kubernetes
command
line
or
the
or
the
API
you
create
and
manage
your
deployments,
the
the
configuration
that
can
include
information
such
as
the
number
of
replicas,
how
many
replicas
you
want
the
container
to
be,
and
then
the
resource
limits
and
your
environment
variables
to
run
your
services.
You
could
also
use
the
kubernetes
stateful
set
resource.
A
This
is
used
to
manage
deployments
just
like
your
deployments
file
or
but
in
this
case
for
stateful
applications.
A
stateful
application
is
an
application
that
you
know
it
requires
a
hostname
and
a
persistent
store
coverage
like
your
database,
for
example,
so,
and
unlike
deployment,
which
uses
replication
controller
and
replica
set
to
manage
the
scaling
and
availability
of
State
stateless
pods,
a
stateful
search
uses
a
unique
hostname
for
each
board
and
guarantees
that
the
poor
that
pods
are
created
and
deleted
in
a
specific
order.
A
This
ensures
that
the
Pod
maintained
the
same
network
identity
throughout
their
life
cycles,
allowing
them
to
maintain
stable
network
connections
and
stateful
set
also
provides
a
way
to
provision
persistent
storage
for
ports.
So
you
know
this
is
also
an
example
of
a
stateful
set
configuration
file.
It's
just
like
the
the
deployments
file,
but
in
this
case
this
is
more
suited
for
pods
or
containers.
You
know
that
require
persistent
storage
so
and
then
down.
A
You
know
the
configuration
file
you
see
where
a
service
configuration
for
a
service
is
specified,
like
I
said,
like
I
stated
in
our
Docker
compose
example
this
to
ensure
that
your
containers
and
Boards
you
know,
run
within
the
same
network.
So
armed
with
this
information,
you
know
with
so
far
you're.
Well,
you
know
on
your
way,
to
being
able
to
sit
for
the
cks
certification
and
then
you
know,
like
I
said,
this
is
basically
John,
it's
Cloud
native
kubernetes
and
how
to
secure
it.
So
where
does
security
come
into
all
this?
A
But
I
would
like
to
also
point
out
that
security
shouldn't
be
an
afterthought.
It
should
be
something
you
also
think
about.
You
know
in
the
process
of
implementing
and
designing
your
application,
but
for
me,
as
a
newbie
one,
one
of
the
very
important
place
to
start
with
with
regards
to
security
is
your
requirement.txt
file.
This
is
where
you,
you
know
I'll
say:
keep
track
of
record
of
all
the
libraries
plugins
and
in
third
party
softwares
or
whatever.
A
We
use
the
python
Python
3.4
Alpine,
the
first
API
and
then
the
uvicon
server.
So
I'm
do
this
information
you
could
easily,
you
know,
maybe
go
to
the
documentation
or
research
on
the
zero
day.
Vulnerabilities
announcement,
you
know
of
security
updates
and
patches,
but
you
know
something.
Another
thing
you
could
do
is
scan
this
image
using
some
open
source
and
freely
available
image
scanners,
like
you,
have
your
Aqua
trivi,
for
example,
which
is
what
I
like
I
use
regularly.
A
So
after
creating
your
own
Docker,
writing
your
own
Docker
file
and
creating
a
container
image
from
it.
You
could
easily
scan
your
own
container
image
or
scan
any
of
this
like
in
this
case.
We
scanned
the
python,
the
the
likely
the
python
library
or
the
python
software
itself,
and
so
and
then
the
the
good
thing
about
aqua
TVs
that
it
not
it
just
doesn't
just
give
you
the
vulnerability
report,
but
it
also
gives
you
the
installed
version
of
you
know
whatever
vulnerability
it
finds
in
your
container
image.
A
It
gives
you
the
install
version
of
that
library
or
Plugin
or
whatever
it
is,
and
then
the
fixed
version
of
it
so
I'm
with
this
information,
all
you
have
to
do
is
to
go
to
the
documentation
of
that
library
or
Plugin.
You
know
look
for
the
fixed
fashion,
download
it
and
implement
it
in
your
application,
but
you
know
just
to
put
it
out
there
when
you
scan
your
container
image
and
you
don't
get
a
report,
it
doesn't
necessarily
mean
that
you
know
your
app
or
products
is
completely
secure.
A
It
just
means
that
at
the
time
of
scanning
no
vulnerability
or
security
issue
has
been
reported,
because
the
way
Aqua
traffic
works
is
by
it
scans.
Your
your
container
image
checks
all
the
libraries
and
plugins
and
third-party
softwares
you're
using
and
that
scans.
This
goes
through
the
CV
database
to
know
if
anything
has
been
reported
on
those.
A
So
if
anything
has
been
reported,
it
throws
it
backs
back
at
you
and
gives
you
the
results
and
the
the
the
it
tells
you
if
it's
a
critical
vulnerability,
a
medium
one
or
a
low
One
But,
whichever
one
it
is.
It's
always
good
to
implement
the
patch
immediately
and
then
some
additional
tips
for
Securities
to
you
know
always
use
security.
Monitoring
and
logging
tools
to
you
know
quickly,
detect
and
respond
to
security
threats
is
always
make
it
a
duty
to
always
keep
your
softwares
and
systems
up
to
date.
A
You
know
with
later
security,
patches
and
Updates.
This
will
always
this
will
ensure
that
your
Cloud
resources
are
protected
against
non-vulnerabilities
Music,
Cloud
native
Security
Solutions,
such
as
service
mesh.
This
can
provide
security,
features
like
service
to
service
authentication
and
encryption,
make
use
of
role
and
based
Access
Control
to
limit
access
to
the
cluster,
to
only
authorize
users
and
rows,
use
kubernetes
security
context
to
limit
the
capabilities
of
your
pods
and
your
containers
running
the
cluster.
A
This
will
help
to
protect
the
cluster
and
these
resources
from
malicious
or
misconfigured
containers
make
use
of
kubernetes
network
policies
to
control
traffic
between
your
pods
and
use
of,
and
make
use
of,
kubernetes
security
policies
to
control,
pod
and
container
security
settings,
always
use
secrets
and
config
maps
to
securely
store
and
manage
sensitive
data
like
password
and
encryption.
Keys
use
kubernetes
audits,
login
to
track
and
monitor
activities
within
your
cluster.
A
You
start
party,
Security,
Solutions,
sorry,
I
know
this
is
more
of
like
use,
use.
You
start
practice:
Security
Solutions
as
kubernetes
Network
and
pod
Security
Solutions
to
provide
additional
security
features
and
protections.
This
can
be
helpful
in
providing
extra
security
layers
to
detect
and
prevent
vulnerability.
A
Like
I
said
earlier,
always
update
and
Patch
your
kubernetes
cluster
well
seek
help
from
experienced
and
professional
and
professionals
or
consult.
You
know
your
some
online
resources,
especially
the
official
documentations
of
whatever
third
party
security,
software
you're
using
or
libraries
and
plug-in,
and
then
always
be
vigilant
about
new
security,
trust
threats
and
best
practices
to
keep
your
Cloud
environment
safe.
One
of
the
tip
I
would
like
to
add.
There
is
to
always
link
your
codes,
especially
your
Docker
file
code,
to
make
sure
you're
following
industry
standard
in
the
in.
A
In
the
case
of
the
cafe,
for
example,
you
can
make
use
of
the
handling
I
you
don't
you
don't
really
need
to
install
it.
You
can
just
go
to
the
to
their
website
or
the
documentation
page
copy,
your
Docker,
your
codes
or
your
Docker
file
posted
there,
and
then
it
gives
you.
You
know,
correction
chance
to
make
how
to
implement
your
path,
and
you
know
the
base
images
to
how
to
specify
your
base
images
or
your
commands
that
helps
a
lot
and
then
I
guess
that's
it
so,
but
feel
free.