►
From YouTube: SIG-Auth Bi-Weekly Meeting for 20220803
Description
SIG-Auth Bi-Weekly Meeting for 20220803
A
All
right,
hello:
everyone
welcome
to
august
3rd
2022
meeting
of
sigoth.
Let's
kick
it
off.
We
have
one
item
on
the
agenda.
Let's,
let's
get
started
I'll
share
my
screen.
Unless
jim
you
want
to
share
your
screen.
Actually,
okay,.
B
B
All
right,
let
me
pull
that
up:
okay,
yeah,
so
just
quick
context
and
background
and
then
I'll
hand
off
to
hotel
for
the
demo
itself.
B
So
what
we
wanted
to
demonstrate
and
get
some
feedback
and
discuss
is
a
feature
where
you
know
planning
to
put
into
kivarna
around
pod
security
admission
and
integrations
with
right.
So
I
think
most
of
the
folks
probably
have
already
you
know,
heard
or
have
some
background
on
pod
security
admission
and
some
of
the
trade-offs
related
to
it,
which
were
discussed
in
quite
a
lot
of
detail
during
the
design
and,
of
course,
there's
feedback
from
users
in
the
community
as
well
right.
B
But
what
we
were
trying
to
figure
out
is
with
pod
security,
admission
now
being
enabled
and
the
default
implementation.
What
could
we
do?
As
you
know,
from
from
a
policy
engine
perspective?
B
B
B
So
what
we
were
trying
to
do
with
this
feature
and
what
we
you
know,
what,
if
you
will
demonstrate,
is
just
showing
how
in
kubernetes
just
integrating
with
bot
security
admission?
Is
there
a
way
to
easily
address
some
of
the
concerns
and
issues
raised
by
the
community,
mostly
around
the
finer
grained
exceptions?
B
And
that's
where
the
you
know,
new
policy
construct
that
we
are
proposing
is
something
like
this.
Where
you
know
tiberno
already
has
like
validate
mutate
generate
rules.
The
new
rule
type
here
would
be
under
validate
for
pod
security,
and
it
would
follow
the
pod
security
standards
as
well.
As
you
know,
the
profiles
related
there
and
internally,
the
implementation
of
this
rule
type,
will
reuse
the
library
created
for
pod
security
admissions.
B
So
the
idea
would
be
to
then
you
know,
specify
the
profile
level
required
and
then
have
finer
grain
exclusions
or
exceptions
which
you
know
the
user
may
want
to
configure.
B
C
No,
I
think
it's
good,
so
I,
if
you
don't,
have
any
questions
I
can
go
through
the
the
demo.
C
So
tell
me
if
you
can
see
my
screens
with
my
the
terminal
and
then
this
code.
A
C
Okay,
good
so
yeah,
so
I'm
I'm
working
on
this
feature
on
extending
the
security
mission
as
part
of
the
alefix
mentorship.
C
So
I
have
a
little
demo
to
to
show
you
so
for
the
sake
of
the
demo,
I
I
have
already
created
some
some
namespaces,
so
I
will
show
you
that
so
the
first
one
is
the
staging
psa
baseline
with
kubernetes
namespace.
C
So
if
we
look
at
at
the
part
on
the
right
here
that
we
want
to
create,
basically,
if
you
go
through
the
the
manifest,
we
can
see
that
we
don't
drop
all
the
capabilities.
C
Next,
and
so
we
will
try
to
create
that
on
the
namespace,
where
we
have
the
restricted
with
the
kubernetes
and,
of
course,
it's
forbidden,
and
it
tells
us
that
he
violates
the
security,
because
we
didn't
drop
all
the
capabilities
right
and
so
now
we
will
look
at
the
kirana
policy
that
we
have
on
the
left
here
so
reduce
the
size
here.
So
what
we
do
here
is
that
we
want
to,
since
we
already
have
the
baseline
on
the
namespace.
C
So
if
we
try
to
create
this
part,
what
the
policy
will
do
is
just
that
it
will
exclude
and
ignore
all
the
errors
or
the
check
results
regarding
the
capabilities
role.
So
we'll
try
to
do
that.
The
first
thing
we
have
to
apply
the
cuban
policy.
C
And
you
can
see
that
the
part
was
created
because
we
excluded
this
particular
control
for
all
the
containers
running
with
the
image
nginx
and.
A
C
Do
you
have
any
questions
until
now.
D
Let
me
just
clarify
a
little
bit
for
the
viewers
here
at
show
kill,
so
you
notice
that
the
control
name
field
rather
than
asking
users
to
know
precisely
which
fields
are
codified
in
the
upstream
controls,
we're
giving
them
helpful
names
that
we
put
under
control
names.
So
capabilities
underscore
restricted.
D
Caverno
understands
all
of
the
fields
that
are
required
as
in
order
to
satisfy
that
control,
and
so
it
reduces
the
burden
on
users
to
have
to
go
and
look
at
upstream
controls
and
key
all
the
fields
in
make
sure
that
they're,
the
right
type,
etcetera,
etcetera
now
kaverna
will
allow
that
to
provide
even
more
fine-grained
control.
But
in
this
way,
just
by
specifying
a
handy
string
of
which
we
would
obviously
provide
the
list
of
the
control
names
and
they
would
be
a
one-to-one
mapping
to
the
pss
controls.
D
It
allows
users
to
to
quickly
and
more
easily
exclude
if
the
level
of
granularity
just
needs
to
be
the
control
itself
and
something
like
an
image,
they
don't
have
to
go
and
put
all
the
fields
in
they
just
put
the
reference,
the
name
we
understand
what
all
the
fields
are.
We
make
the
exemption
if
they
need
more,
more
more
fine
grained
control.
They
can
specify-
and
it's
not
shown
here,
another
field
which
shows
exactly
which
fields
will
be
exempted.
C
So
maybe
if
you
don't
have
questions,
I
can
show
you
another
demo.
Maybe.
D
That
or
also
giving
you
the
ability
to
make
alterations
to
the
fields
that
are
part
of
the
control.
So,
for
example,
if
one
control
said
and
and
many
of
the
controls
are
applicable
for
containers
and
that
containers
and
ephemeral
containers,
let's
just
say
for
demo
purposes,
that
you
wanted,
you
wanted
to
ensure
that
the
control
was
enforced
for
all
containers.
C
Yeah
yeah
sure
so
so
in
this
case,
as
trump
said,
if
we
specify
only
the
control
name,
it
will
extrude
the
restricted
fields
regarding
this
control.
So
the
second
demo
that
I
have
here
so
in
this
one
we
have
some
other
fields.
C
C
So
on
the
right.
This
is
the
part
that
I
I
will
try
to
create
and,
as
you
can
see,
we
have
the
sysadmin
value
on
the
capabilities
there
and
normally,
if
we
don't
exclude
any
values
for
that,
it
will
be
forbidden.
So
let's
try
to
do
that.
C
So
in
this
namespace
I
only
have
cubano,
there
is
no
psa
activated,
so
you
can
see
that
the
pod
was
was
created
and
imagine
that
I
would
delete
the
pawn.
C
C
Yeah,
so
we
have
a
message
here,
so
this
is
not
well
formatted
for
the
time
being,
but
it
say
it
says
that
we
have
the
system
and
this
time
on
the
capabilities
at
values,
and
we
have
to
exclude
all
these.
D
And
any
feedback
on
this
as
well.
I
I
think
a
question
was
raised
in
sigoth
channel
to
solicit
some
feedback
and
some
criticism
on
this,
and
I
don't
think
that
we
saw
one
response,
so
it
would
be
good
to
good.
To
kind
of
understand
is
this:
do
people
see
this
as
beneficial
valuable?
Do
you
see
obvious
holes
in
it,
problems
curious
for
any
and
all
feedback.
D
E
It
seems
like
it's
mostly
used
for
it,
or
it
seems
like
it
would
be
most
useful
for
punching
specific
holes
in
the
policies,
which
was
something
we
put
a
lot
of
thought
into
when
designing
pod
security
admission
and
explicitly
didn't
want
to
do
a
lot
of.
E
And
I'm
worried
that
people
are
going
to
be
inclined
to
say.
Well,
you
know
I
just
I
know
I
need
this
one
piece
and
my
container
is
not
running
so
I'm
going
to
you
know
just
punch
this
one
hole
in
the
standard
to
get
this
container
running
without
really
understanding
the
implications
of
that.
D
Yeah,
that's
a
fair
criticism
and
that's
that's
something
that
you
know
we're
also
concerned
about.
Obviously
you
know
when
you
provide
capabilities
such
as
this
and
and
many
many
other
things
that
are
in
the
purview
of
external
admission
controllers.
There's
always
that
possibility,
and
it's
kind
of
a
caveat
emptor
moment
where
you
know.
D
I
mean
we
all
know
that
that
that
just
happens
in
real
life,
and
so
in
some
cases
there
are
cases
where
they
need
to
punch
those
holes
through.
But
it's
not
because
hey,
I
have
an
admin
who
built
a
container
and
we
really
aren't
keeping
tabs
on
what
he's
doing
with
it.
So
we're
going
to
just
go
ahead
and
trust.
That's
that's
fine.
I
think
that's
the
more
minority
use
case
than
saying
you
know.
D
You
know
best
practices
that
pod
security
admission
codifies,
but
this
other
two
percent,
where
we
have
to
rely
on
these
ecosystem
tools
with
these
vendor
products
like
we
can't
really
control
that,
but
we
still
need
those
to
run.
So
let
us
be
very
focused
in
the
holes
that
we
punch
so
that
we
only
let
those
vendor
or
ecosystem
tools
through
and
not
just
anybody
who
wants
to
run.
D
You
know
a
container
without
you
know
any
of
these
any
of
these
field
sets,
I
think,
that's
the
goal
and
that's
kind
of
what
we're
and
that's
what
we
see
quite
often
in
the
community
is
people
asking
and
having
use
cases
for
how
to
make
those
strategic
exclusions
based
on
the
tooling
that
they
need
to
use
which
really
isn't
the
same
as
their
internal
workloads.
Just
that
they're,
you
know
too
lazy
to
control
and
provide
oversight
for
them.
E
Yeah,
that
makes
sense.
I
just
think
it's
hard.
I
I
definitely
understand
the
use
case
and
the
motivation.
I
just,
I
think
it's
hard
to
get
it
right.
So,
for
example,
if
you're
excluding
the
engine
x
image,
I
think
the
standard
nginx
image
is
built
on.
E
I
don't
actually
know
what
the
base
image
is
off
the
top
of
my
head,
but
I
think
it's
got
a
full
shell
in
there.
So
you
could
say
you
know,
run
the
nginx
image,
but
for
the
command
don't
actually
run.
Nginx
run
run
a
shell
script
that
I'm
going
to
give
you,
and
so
that's
the
sort
of
piece
where
you
need
to
kind
of
to
really
do
it
safely.
E
You
need
to
have
some
fixed
combination
of
the
image,
ideally,
the
image
kind
of
tag
inversion,
but
also
the
the
command
line
that
that
image
is
executing
life
cycle,
hooks
probes,
think
about
side,
cars
and
restricting
ephemeral
containers
and
think
about
how
exact
permissions
are
going
out,
and
so
it
kind
of
like
quickly
bubbles
up
into
this
sort
of
difficult
case.
D
Yeah-
and
those
are
all
good
points
to
mention-
I
I'll
just
call
out
that
all
of
those
things
are
possible
to
restrict
today
with
something
like
caverno.
Obviously,
there
are
other
other
things
that
but,
for
example,
caverno
has
the
ability
to
reach
in
and
look
at
container
metadata
and
do
exactly
that.
So
it's
not
that
this
would
be
the
one
all
the
end-all
rule
for
anything
having
to
do
with
security.
D
That
would
be
the
image
name
that
you
could
put
here
and
then
you
might
have
another
policy
that
just
totally
forbids
pulling
images
that
don't
come
from
docker
hub
or
totally
forbids
use
of
a
latest
or
a
non-specified
tag,
and
even
going
so
far
as
to
say
you
must
have
an
immutable
digest.
So
those
are
all
additions
that
can
be
used
to
fortify
and
protect
against
those
angles,
and
in
this
we're
not
trying
to
use
one
new
rule
type
to
you
know,
try
and
obviate
the
need
for
all
those.
D
And
this
works
perfectly
well
by
the
way
with
those
others.
It's
not
like.
You
know
it's
an
either
or
thing
so
this
is
just
another
validate
rule
and
there's
nothing
whatsoever
to
prevent
another
validate
rule
from
saying
nope.
You
know
we
said
that
you,
you
know
the
policy
author
said
it
was
cool
to
run
nginx,
and
so
that
was
allowed.
But
then
another
evaluation
said
no.
You
actually
can't
run
nginx,
it
has
to
be
from
corp.org
registry
and
so
we're
going
to
deny
the
request
so
they're
additive
in
nature
and
one
can't
counter
man.
E
B
Yeah,
I
think
the
other
thing
we
were
trying
to
figure
out
while
designing
this
type
of
policy
rule
is
what
would
be
the
alternative
right
and
it
seemed
like
the
only
other
alternative
would
be
to
turn
off
pod
security
admission
and
just
completely
fall
back
to
an
admission
controller
like
kevon
or
opal
gatekeeper,
which
didn't
seem
quite
as
nice
right.
So
it
seemed
like
you
still
want
to
leverage
pod
security
admission,
at
least
for
a
baseline
and
then
use
finer
grain
exclusions
or
exceptions
as
needed
in
you
know,
in
the
right
areas.
B
So
one
one
quick
note
on
the
implementation-
and
maybe
here
girl-
has
more
information
on
this
to
add
in
is
currently
we
are
using
the
library
itself
directly
in
caverno
and
if
I
recall
correctly
yoko,
there
were
some
questions
and
discussions
around
the
return
types,
and
I
think
you
had
asked
that
on
one
of
the
channels.
Fear
rights
is
there
something
that
we
want
to
kind
of
discuss
or
propose
on
that.
C
Yeah,
so
we
are,
we
are
using
the
the
psl
library
to
get
the
check
results
and
we
we
saw
that
the
written
message
is
not
formalized.
C
So
in
the
case
where
a
control
name
is
is
forbidden,
it
would
be
nice
to
have
the
all
the
forbidden
values
so
that
we
can
pass
it
more
easily
because
for
the
time
being,
it's
just
in
the
forbidden
detail
message
and
it's
pretty
hard
for
us
to
to
pass
it.
B
So
is
that
something
you
know
that
and
happy
to,
of
course,
create
or
get
a
pr
created
for
that.
But
you
know
maybe
we
can
discuss
this
a
little
bit
more
offline,
but
that
was
yeah
just
the
one
challenge
that
we
encountered
when
using
the
library.
C
Yeah
sure
so
maybe.
E
Sorry,
just
a
follow-up
question
on
that,
so
there's
the
the
forbidden
reason,
which
should
be
like
that's,
maybe
not
formalized
in
terms
of
there's
const
that
you
can
compare
it
to,
but
this
should
be
more
machine
readable.
E
A
C
So,
for
the
time
being,
what
we
have
so
we
have
the
allowed
forbidden
reason
and
the
forbidden
detail,
and
the
thing
is
that
it
would
be
nice
to
have
you
know
another
object
inside
the
check
result
where
we
will
have
an
array
of
the
all
the
forbidden
values
and
maybe
also
the
restricted
field,
because
when
you
see
now
here
is
pretty
hard
to
pass
it
right
to
get
all
the
forbidden
values
and
the
research.
E
Yeah,
that
makes
sense
if
you
want
to
file
an
issue
in
kubernetes.
A
D
Nice,
so
tim
is
that
something
that
that
you
all
would
potentially
be
amenable
to
if
we
just
went
ahead
and
also
created
a
pr
to
try-
and
you
know-
assist
on
this
area,
in
addition
to
the
issue
of
course,
but
do
you
think
that
that
would
be?
Does
this
sound
like
something
that
the
sig
off
would
be
amenable
to
accepting.
E
Yeah,
I
think
so
I
think
we'd
want
to
discuss
it
a
little
more
and
so
that's
why
I'd
suggest
opening
the.
A
E
First,
with
some
examples
and
okay.
A
E
If
other
folks
in
the
work
are
open
to
it,
definitely
we
welcome
a
pr
for
that.
A
E
Also,
since
this
would
be
this
isn't
like
end
user
facing
it,
doesn't
touch
the
kubernetes
api
at
all.
I
think
I
don't
think
we
would
need
a
kept
process
for
this.
B
No,
I
think,
we've
covered
everything.
Yes,
certainly
happy
to
get
more
feedback
or
questions
or
thoughts
of
folks
out.
A
A
Thanks
all
right,
I
think
that's
the
only
item
on
the
agenda
today.
So
if
there's
nothing
else,
I
think
we
can
in
this
call
today
thanks.
Everybody
have
a
good
one.