►
From YouTube: Why do I want to run my application as non-root?
Description
This is a video clip from Elastisys Compliant Kubernetes office hour #1, November 23, 2021.
Cristian Klein, Architect of Elastisys Compliant Kubernetes, explains why it is so important to make sure that your application does not run as root, and what you should do in the cases where an exception is needed.
B
A
very
good
question,
simon:
we
try
to
document
a
bit
our
rationale
in
the
safeguard
section
in
pretty
much
preventing
forgotten
routes
where
people
can
also
in
detail
find
out
what
iso
27000
controls
this
might
map
to,
and
also
behind
the
rationale.
But
to
put
it
to
summarize
it,
your
regulators
want
to
see
that
you're,
taking
security
seriously
and
taking
security
seriously
is
not
only
about
vulnerability
management
and
things
like
that.
But
it's
also
about
reducing
the
blast
radius
right.
B
Each
thing
should
have
just
the
right
amount
of
permissions
to
perform
its
task,
whether
that's
a
system
component,
an
application
or
with
a
user.
It
should
not
be
able
to
do
more
than
is
necessary.
So
then
it's
your
responsibility
to
ensure
that
it
gets
just
the
the
right
amount
of
permissions
now
running
an
application
as
root.
Pretty
much
means
you
can
do
whatever
you
want
to.
B
Fortunately,
you're
running
the
applications
in
a
container,
so
it's
not
not
quite
as
much
that
it
can
do
as
running
roots
directly
on
a
vm
or
directly
on
a
server
or
things
like
that.
But
nevertheless,
let
me
just
put
like
that.
There
are
constantly
discovered
linux
kernel
vulnerabilities
that
can
only
be
exploited
if
you
have
code
running
as
root.
Sometimes,
even
if
your
code
is
running
as
root
inside
the
container.
A
B
Often
what
you
can
do
is
if
you
have
a
proper
deviation
management
program
within
your
organization,
you
might
be
able
to
buy
yourself
some
time
in
order
to
say,
for
example,
okay,
we
have
this
deviation,
we're
running
certain
containers
root
in
production,
but
we
plan
to
fix
this
deviation
within
two
months.
Sometimes
you
can
do
that,
but
some
regulators
might
see
that
as
an
unacceptable
risk,
and
you
should
that
you
really
avoid
and
also
my
opinion-
is
that
often,
if
you're
starting
to
have
this
kind
of
exception
culture,
then
eventually
these
exceptions
become
the
rules.
B
So,
yes,
you
could
do
it,
but
I
strongly
recommend
against
it.
Now
there
are,
let's
say,
more
or
less
legitimate
use
cases
for
running
containers
as
root,
sometimes
you're
having
more
system
components
that
really
need
better,
tighter
integration
with
the
online
operating
system
or
that
are
providing
services
to
your
application
containers,
and
in
that
case,
what
we
suggest
our
users
is
just
to
read
the
the
section
on
demarcation
that
we
have
also
entitled.
B
Can
I
and
where
we
pretty
much
say
that
you
know,
strictly
speaking
as
long
as
you
do
not
violate
the
general
principle
of
compromising
or
working
around
access,
control,
logging,
monitoring,
backuping
and
alerting
off
the
platform
we
allow
you
to
do
anything
right.
We
just
cannot
give
you
permissions
to
do
those
things
directly
and
we
have
actually
gone
so
far
as
to
state
the
specifics
of
things
that
you
cannot
do
in
complex
by
default.
B
But
if
you
really
need
to-
and
we
I
have
seen
quite
a
few
legitimate
use
case
for
that,
some
people
might
want
to
run
a
special
operator
for
the
application
that
that
delivers
service
to
your
application,
or
you
might
have
a
very
special
backup
system
that
requires
very
deep
integration,
kubernetes
and
the
host
operating
system.
Then
please,
let's
get
in
touch
with
your
committee's
administrator.
B
They
will
case
by
case,
make
a
risk
reward
analysis,
and
then
they
will
pretty
much
go
through
some
something
like
a
mini
audit
of
what
it
means
to
add
that
particular
new
component,
and
if
they
deem
that
you
know
it
seems
like
the
benefit
that
you're
getting
out
of
installing
this
compressed
root,
outweighs
the
risks
that
it
brings
by
installing
these
components
root.
Then
they
will
be
very
happy
to
say
yes
and
to
and
to
allow
you
to
sorry
to
install
that
component
for
you.
B
But
that
being
said,
don't
see
your
administrators
as
your
enemies,
don't
try
to
pressure
them
to
make
an
exception
for
you,
because
you
know
down
the
line.
This
might
have
more
severe
consequence
for
your
organization
right
if
a
regulator
picks
up
on
the
fact
that
there
is
a
huge
exception
culture
and
that
there
are
constantly
deviations
being
produced
just
in
order
to
hit
deadlines
that
might
put
the
whole
organization
at
risk.
So
try
really
to
have
an
open
conversation
with
your
administrators
explain.
What
is
the
situation?
Go
through?