►
Description
Kubernetes Auth Special Interest Group KMS Plugin Meeting for 20220104
C
B
Okay,
cool
all
right,
so
this
is
the
canvas
meeting
for
january
4th
2022,
that's
gonna!
It's
gonna
take
a
while
to
say
consistently
right
all
right,
so
we
were
looking
at
the
envelope
encryption
code
inside
of
kubernetes
to
remind
ourselves
of
how
data
encryption
keys
were
used
so
kristoff.
I
have
found
that
code
and
the
answer
is
that
we
use
aes
cbc.
B
A
B
I
am
unaware
of
any
such
requirement
with
pips,
as
as
far
as
I
know,
phipps
hasn't
caught
up
to
that.
Yet
because,
if
you
look
at
lips
for
tls,
I
don't
think
they
recommend
any
of
the
ciphers
that
have
our
aids
right
there.
They
still
are
they're.
I
think
they're
they're,
roughly
in
the
time
frame
of
2008-ish
land,
something
around
2010,
maybe
and
a
it's
became
deployed
in
2012
and
13.
B
they're,
okay,
they're
a
little
behind.
If
I
remember
correctly,
I'm
I'm
not
exactly
sure
the
dates,
but
as
far
as
I
understand
they
haven't
caught
up
to
that.
Yet
so
that's
that's
my
understanding
there
now
to.
I
suspect
I
suspect
that
is
why
this
actually
uses
the
cpc
transformer
just
because
they're
like
eh.
It
doesn't
matter
that
much
because
there's
no
there's
no
like
actual
attack
vector
that
involves
you
tweaking
data
inside
of
ncd,
for
a
one-time
use,
key
and
hoping
that
you
managed
to
do
something
bad
like
that's.
B
A
B
I
was
going
to
confirm
to
myself
that
audit
id
from
the
kubernetes
sense
is
what
I
think
it
is.
So
I'm
gonna
I'll
share
this
piece
of
code
too
right,
which
is
this
all
right.
So
this
is
the
v1
version
of
audit
event
right.
So
this
is
the
thing
that's
json
serialized
and
sent
to
your
audit
sync
right
so
got
to
make
sure
that
that
is
what
we
think
it
is
right.
It
comes
from.
B
B
B
B
E
B
B
E
E
A
A
B
B
B
The
the
issue
is
that
they
didn't.
They
didn't
build
a
trust
chain
to
say
that,
like
the
thing
that
is
setting
the
id
is
actually
trusted
to
set
an
id,
they
didn't
build
that
concept.
They
just
said
it's
on
the
request.
It's
probably
fine,
don't
don't
trust
it
blindly,
but
I
was
like,
but
what's
if
I
can't
trust
him,
then
what's
the
point
of
it.
E
B
B
B
A
E
And
I'm
also
like
a
quick
question:
is
the
audit
id
even
here
right?
It's
mostly
used
only
for
logging
right,
like
it's
not
actually
part
of
storage.
I
mean
if
it's
an
event,
the
event
is
stored
in
hdd,
but
other
than
that.
It's
not
something
that's
explicitly
stored.
So
I'm
saying
I'm
thinking
even
for
kms.
It's
the
same,
even
though
we
generate
the
audit
id
it's
not
that
we're
going
to
store
it
with
the
encrypted
data,
but
rather
it
would
just
be
part
of
the
event
right.
B
I
mean
yeah
in
the
general
sense.
I
think
you're
right,
but
I
feel
like
that's
completely
up
to
the
kms
right
you
can.
It
can
choose
to
store
it
if
it
has
some
need.
I
guess
so
in
the
same
way
that,
like
your,
your
audit,
sync
could
decide
to
save
some
events
and
throw
some
events
away
right
on
its
own
notion
of
whatever
is
important
to
store
or
might
have
just
different
retention
policies
for
different
data.
E
Yeah
as
an
event,
I
think
it's
fine
and
then
also
like,
probably
like
audit
logs.
It
shows
up
right,
but
again,
none
of
these
audit
ids
are
persistent,
like
all
of
these
get
generated
for
a
request
and
then
they're
used
by
different
components
to
log
and
after
that,
that's
it
they're
gone
they're
like
not
stored
anywhere.
B
D
But
when
only
bad
people,
just
assuming
that
that
malicious
people
would
set
it
to
one
you,
you
would
also
can
contract,
because
all
the
other
normal
users
would
have
uids.
I
would
guess,
and
those
who
have
bogus
data
you
would
see.
Okay,
this
is
something
is
up
there
and
you
would
maybe
actually
look
out
for
those
ids.
D
The
only
issue
would
be
when
you
would
try
to
pass
it
as
uid,
and
you
have
an
error
and
the
only
thing
that
you
add
and
into
the
order
that
you
would
be
some
error
message,
but
still
then,
as
most
of
the
users
have
proper
uids
that
help
you
to
track
from
the
client
to
the
database
what's
happening.
I
think
it's
still.
Okay,
isn't
it
I
mean,
even
if
you
would
sit
every
time
at
one
or
two
at
three
or
five.
D
B
Right
but
remember,
the
audit
id
doesn't
have
an
api
schema.
It's
just
a
string
right
so
today,
being
a
uid
is
an
implementation
detail
right,
there's
no,
there's
no
requirement
that
it
stays
that
way.
If
kubernetes
decides
to
change
that,
I
think
that's
totally
fair
right,
so
I
mean
there's
still
the
potential
of
dos
right,
because
you
can
still
set
it
to
multiple
megabytes
right
so
that
then
that'll
put
pressure
on
your
your
back
end
for
no
good
reason
really.
B
Also,
if
you
happen
to
learn
audit
ids
of
a
different
user
somehow
or
different
component,
and
you
can
set
yours
to
match
theirs
and
it
makes
it
really
hard
to
figure
out
which
request
was
being
made
by
who
right
like
it's
just
to
me,
really
strange
and
difficult
once
you
can't
trust
it
as
just
a
random
value
per
request.
That
cannot
be
spoofed
right,
that
that
last
part
is
important
right
and
I'm
wondering
if
that's
why,
like
admission
web
hooks
and
stuff,
don't
let
you
pick
because
they
they
wanna.
B
E
B
No
there's
a
there's
a
bunch
of
magical
intel
like
all
of
guaranteed,
update
inside
of
the
scd
code.
Will
it
can
invoke
for
the
same
request
more
than
once
right,
because
that
we
we
maintain
an
in-memory
cache
of
data,
and
then
we
use
that
for
optimistic,
concurrency
right,
but
sometimes
that
leads
to
failure
right.
So
then
we
do
a
re-get
out
of
scd
and
then
do
a
re-update
onto
it
right.
B
So
we
we
might
do
it
more
than
once
for
the
same
request
as
far
as
our
image
now
all
right,
so
they
yeah.
So
I
mean
that
seems
important
to
know
right
they're,
like
all
of
this,
was
happening
and
like
it's,
not
the
user,
doing
something
funky,
it's
just
the
system,
behaving
as
it
is,
and
still
one
request.
Logically,
from
the
user's
perspective,
it's
just
multiple
calls.
They
can't
ask
for
that
same
request,
but
probably
the
first
one
was
dropped.
Yes,
all
right.
In
the
sense,
the
encryption
data
was
dropped.
E
B
Yeah,
I
let
me
find
the
code
so
that
way,
I'm
like
not
telling
you
guys
a
lie,
but
yeah.
That's
what
I
remember
being
the
case
and
I
was
confused.
I
was
like
well,
we
have
this
cool
audit
id.
Why
don't
we
use
that?
One?
Okay,
fine,
maybe
there's
a
good
reason,
but
I
mean,
as
far
as
I
understand
you
know,
I
was
not
involved
in
any
of
the
like
the
design
of
that
stuff.
So
I
cannot
say.
E
Yeah
I
mean
if
admission
request
is
doing
it,
then
we
could
do
the
same
similar
one
in
kms
right
like
at
least
start
off,
we
can
say
like
we
would
generate
an
audit
id.
So
at
least
we
are
able
to
correlate
between
the
originator
that
basically
from
the
api
server
and
then
like
at
least
kms
plugin,
and
then,
if
there
is
ever
a
use
case
where
users
say
they
also
want
to
string
it
all
the
way
to
their
request,
which
caused
this
call
to
be
made.
E
B
B
B
Well,
so
what
I
was
saying
is:
should
we
internally
for
every
request
for
kms's
purposes,
generate
a
uid
for
every
request
and
have
that
as
part
of
the
kms
call,
but
then
also
pass
in
the
audit
id
that's
already
there.
So,
basically,
you
would
have
two
ids
right,
one
that
you
know
is
generated
by
the
api
server
guaranteed
to
be
unique
for
a
request
and
one
that
you
know
is
probably
generated
by
the
api
server
but
can
be
manipulated
by
the
client.
So
they
choose
to
for
good
or
bad
reasons.
E
B
B
It
requires
an
mtls
connection
from
the
kubernetes
api
server,
with
a
particular
client
certificate
signed
by
a
particular
ca
and
the
cn
on
that
client
certificate
has
to
match
a
particular
name
right.
Once
all
of
that
is
correctly
set,
then
it
says
cool
I'll
trust,
those
headers
to
tell
me
any
identity
they
want.
So
this
is
the
kubernetes
api
server
talking
to
me
right.
Otherwise,
it's
like
no.
B
C
B
B
B
Might
be
in
a
different
file,
but
there
there's
a
function
called
verify
admission
response
that
takes
in
the
that
you
that
in
memory
uid
and
verifies
that
the
the
web
hook
responded
correctly.
With
that
same
reality,
because
that's
the
contract,
the
web
hook
has
to
reply
with
that
uid
to
assert
to
us
that
it's
keeping
track
at
least
a
little
bit.
C
C
B
B
I
mean
it's,
so
we
couldn't
just
do
it
we
would
have
to.
We
would
have
to
have
some
way
of
retaining
the
backwards
compatible,
behavior
right
for
at
least
some
amount
of
time
right,
which
is
today,
you
can
just
set
it
right.
So
if
you,
if
you
today,
have
a
series
of
proxies
in
front
of
your
api
server,
they
can
just
set
this
value.
B
Yeah,
so
I
mean
I'm
trying
to
understand
what
the
use
case
was
like
why
I'm
missing
some
history
here
for
like
why
we
felt
we
needed
this
exactly
right,
because
if
it's,
if
the
only
case
is
like
a
front
proxy
that
is
like,
like
the
other
front
proxy
stuff
we
have
today,
we
have
a
ton
of
machinery
to
validate
those
connections
right.
So
if
that's
the
case,
then
this
could
use
that
same
machinery
right
to
say
that
hey
in
in,
if
I
got
a
request
id
from
the
user,
that
user
better
be
that
same
user.
B
That
is
the
front
proxy
user
right.
If
that's
the
case,
yeah,
that's
totally
fine.
It's
totally
straightforward
and
easy,
because
machinery
already
exists.
I
mean
we'd
have
to
rejigger
some
ordering
and
stuff,
because
this
runs
first
in
the
request,
handling
and
authentication
learns
later
technically,
but
that's
fine
like
we
could.
We
could
make
it
all
work,
it's
totally
doable
and
you
know
we
could
even
make
it.
We
could
even
make
it
backwards
compatible
by
making
a
best
effort.
E
B
B
B
Yeah
totally
totally,
we
can
do
that
so
because
you
know,
if
you
know
david
will
probably
be
there,
so
we
can
ask
him
hey.
Why
do
admission
web
hooks
make
up
their
own
uid
and
send
it
through?
Why
do
why
did
we
think
that
was
totally
fine
for
admission
web
books
is?
Is
there
no
desire
to
correlate
a
user's
request
with
the
web?
Hooks
behavior,
like
directly
right,
like
mo,
does
create
pod.
What
were
the
web
books
that
handled
create
pod
and,
like
you
know,
what
did
they
do
like?
B
Is
that
is
that
not
important
there
there's
also,
I
I'm
honestly
completely
unfamiliar
with
what
this
code
does,
but
I
think
it
was
added
relatively
recently,
but
there's
also
this
like
api
server
tracing
code,
which
is
behind
a
feature
flag,
that's
alpha
in
122,
so
it
it
does
something.
It
adds
some
tracing
stuff.
B
E
B
E
B
E
Not
as
part
of
the
api,
but
most
of
this
would
be
overloaded
as
part
of
the
grpc
request
context
right
so
like
the
request
id
and
all
those
I
mean
at
least
for
the
trace
span,
will
be
included
in
the
context
and
then,
if
all
the
kms
plugins
implement
tracing
with
open
telemetry,
then
as
a
user,
I
would
just
be
able
to
visualize
that
which
component
is
taking
how
much
time.
But
I
think
that
still
gives
you
the
data
on
how
long
things
are
taking,
but
in
terms
of
actually
being
able
to
order
it.
E
B
E
Right,
but
I
I
don't
know
if
this
is
the
way
forward
like
we
can
check
that.
If
this
is
the
way
forward,
then
what
you're
saying
is
absolutely
right,
because
there
should
be
some
way
to
correlate
what
you're
sending
so
it's
possible
that
they
are
actually
passing
the
audit
id
in
the
spam
itself
like
rather
than
generating
a
random
id.
B
B
Well,
with
kms,
it's
only
exposed
over
units
domain
socket
right,
so
we
cheat.
We
say
that
the
unix
domain
socket
should
only
be
accessible
on
the
host
with
post-level
permissions
and,
like
se,
linux.
If
you
want
to
go
fancy
and
that's
how
you
control
access
to
it,
but
it's
not
supposed
to
be
exposed
on
the
network
right
admission.
Web
hooks
have
the
problem
of
being
exposed
on
the
network.
C
B
I
mean
that
that
is
certainly
an
option
for,
if
you
know,
if
one
wanted
to
harden
that
right,
it's
not
not
necessarily
against
that
to
say
that
yeah
I
want
I
get
this
over.
Unix
demand
socket,
but
I
also
like
want
further.
The
problem
becomes
then
like:
where
does
the
authentication
credentials
come
from
right?
How
do
you
specify
them
to
the
kubernetes
api
server
and
then
how
is
that
any
safer
than
the
unix
domain
socket
or
like
if
they're
a
file
on
this
like
it
gets
really
wonky?
B
We
have
other
things
we
want
to
talk
about,
so
for
for
a
kept
that
we're.
Considering.
Writing
right
now
would
just
be
observability
improvements
for
canvas,
so
that
would
that
basically
comes
down
to
these
set
of
questions.
So
we're
not
talking,
it
might
involve
changes
to
the
grpc
api
and
those
would
be
backwards
compatible
because
it's
just
extra
fields
right
and
the
old
kms
plug-in
will
just
ignore
them
and
do
nothing
with
them
and
we're
not
storing
anything
and
we're
also
really
not
asking
the.
B
B
B
B
B
B
Oh,
that's,
a
real
pain
but
yeah.
So
the
reason,
the
reason
we
didn't
do
this
is,
while
everyone
was
fine
with
the
change
we
were
like,
but
don't
we
want
to
just
change
the
format
altogether
to
like
a
nicer,
structured
format
that
we
didn't
just
make
up
ourselves
so
like?
Maybe
we
should
just
do
that,
but
it
does
seem
like
we
were
okay
with
changing
this
to
gcm
and
that
that
somebody
remind
me
gcm
is
an
aide
right.
I
think
it
is
right.
It
is
authenticated.
B
Encryption,
remember
manuscript!
Yes,
it
is
yeah,
that's
what
I
thought
right.
So
that
would
give
us
that
benefit
and
in
because
we
use
it
for
a
single
right.
At
least
today,
there's
no
reap
like
replay
attack
or
just
whatever.
What's
the
term
too
much
encryption
per
key?
Whatever
the
attack
is
right
now,
I'm
blanking
the
name
but
yeah
so
like
we
never
did
this,
then
maybe
we
should,
but
again,
like
all.
B
D
C
B
E
B
Could
do
like
you
know,
like
data
recovery
disaster
recovery
without
literally
having
to
use
the
kubernetes
api
server
in
that,
in
that
structural
change
we
would
if
there
was
either
a
hard-coded
cipher
or
a
configurable
cipher.
We
would
make
sure
that
this
was
at
least
the
default
cipher
or
something
like
it's
the
better
way
of
doing
it,
but
we
would
basically,
if
we
were
gonna,
make
a
really
large
structural
schema
change.
B
It
didn't
make
sense
to
also
do
this
tiny
little
change
and
just
you
know,
go
through
the
effort
of
that
rollout
because
it
it
just.
Doesn't
it's
not
it's
a
lot
of
work
for
not
much
gain
right,
because
if
it's
only
used
for
a
release
or
two,
then
what
was
the
point
of
doing
all
that
roll
out
work,
because
it
still
requires
like
a
ton
of
tests
and
stuff
right,
because
you
gotta,
you
gotta,
write
the
test
to
make
sure
that
aj
would
work
but
yeah
you're
right
that
we
never.
D
There's
already
a
wishes
what
we
could
add
to
this
aad,
so
the
unencrypted
additional
data
that
you
can
put
into
the
a
ead
in
the
document
about
kms
plugging
error,
some
improvements.
So
someone
already
mentions
what
we
could
add.
That's
also
maybe
it's
a
bigger
topic.
Then,
when
we
switch
to
to
sg7
how
it
would
look
like
right.
D
E
B
Yeah,
so
I
I'm
I'm
I'm
I
I
dislike
cipher
configurations
pretty
greatly,
especially
in
like
the
ls.
All
I
find
is
giant
foot
guns
for
people
to
take
the
wrong
ciphers,
but
I
I
do
think
that
at
the
bare
minimum
we
should
have
a
better
schema
for
how
we
store
things
on
disk
and
if
we
should
probably
leave
ourselves
some
space
to
have
the
ability
to
fix
between
some
some
ciphers.
B
A
B
Yeah
there's
like
key
size
requirements
and
various
other
bits
and
pieces
right
now
and
obviously
you
would
have
to
have
a
the
fips
compiler
for
your
api
server
and
your
kms
would
also
have
the
d5
compliant
et
cetera,
but
like
it's
all
technically
doable
today.
Right
and
I
realized
we're
like
three
minutes
over
time
and
actually
late
for
my
next
meeting,
but
we
need
to
drop
but
yeah.
Let's,
let's
just
focus
on
the
observability
stuff
tomorrow
and
you
know:
let's
see
if
we
can,
we
can
nail
down
something.