►
From YouTube: Kubernetes SIG Auth 2022-01-04 KMS #2
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 2022-01-04 KMS #2
Meeting Notes/Agenda: https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/preview
Find out more about SIG Auth here: https://github.com/kubernetes/community/tree/master/sig-auth
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
So
in
that,
in
that
case
you
are
correct
that
it
is
not
authenticated
because
it
does
not
it's
not
a
negative.
It
does
not
support
that.
A
D
Such
a
basic
recommendation
from
from
the
nest
that
I
was
surprised
that
we
don't
do
it
and
I
was
curious
if,
if
there
is
not
a
hard
requirement
from
some
auditors
for
compliance
and-
and
this
was
basically
my
question,
for
example,
if
if
it's
part
of
hip's
requirement
to
have
this
authenticated
encryption.
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
It's
a
it's
a
really
hard
attack
vector
and
if
you
can
write
data
to
lcd,
it's
kind
of
you're
kind
of
host.
At
that
point,
it's
not
really
really
anything.
We
can
do
anyway,
so
I
suspect
that's
why
this
was
chosen
and
I
can't
do
it
get
blamed,
but
I
suspect
this
is
probably
like
from
the.
A
D
And
maybe
we
should
continue,
as
you
mentioned,
we
have
don't
have
that
much
time
to
write
a
cap.
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
So
I'm
trying
to
make
sure
like
did
we
just
at
some
point,
just
move
that
code
like
I
was
I'm
not
obviously
seeing
it.
So
we
are
if,
if
it's
already
in
the.
B
E
B
B
E
Yeah,
we
probably
don't
want
to
use
that,
but
that
also
means
we
cannot
string
it
all
the
way
from
the
request
that
originated.
So
if
we
actually
decide
to
not
do
this
and
generate
an
audit
id
right
before
the
game
is
plug-in
is
called
then
that
that
would
still
be
there.
E
B
Now
so
I
suppose
to
some
degree,
there's
precedence
for
not
using
this
id,
because
it's.
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
The
the
point
of
having
the
uid
on
admission
request
is
to
make
sure
that
when
the
mission
web
webhook
responds
that
it
responds
with
its
set
in
the
response,
so
that
the
api
server
can
understand
that
the
admission
web
hook
knew
which
request
it
was
responding
to
and
also
admission
web
hooks
can
be
called
more
than
once
for
the
same
request
right
so
admission
web
folks
need
to
know
for
some
amount
of
time,
if
they're
being
recalled
for
this,
like
if
they're
stateful
right
for
kms
that
doesn't
matter
as
much,
because
I
don't
think
we
ever
have
a
flow
where
we
would
recall
you.
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
So
like
don't,
don't
use
it
for
guaranteed
something
but
like
it
might
help
you
correlate
something
if
you
really
want
to.
But
it's
it's
like
a
best
effort
thing.
I
don't
know
if
that
just
causes
more
trouble
than
it's
worth.
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
And
then
we
could
pass
both
of
these
ids
and
then
let
the
kms
plugin
decide
if
it
wants
to
log
both
of
it
or
if
it
wants
to
pass
it
to
the
external
secret
store,
but
probably
start
off
with
request
id
which
is
uniquely
generated
for
every
encrypted
call,
so
that
we
can
correlate
at
least
from
api
server
to
kms
plug-in
to
secret
store.
E
B
B
You
have
to
come
up
with
some
way
of
saying
you
can
and
cannot
set
this
just
this
header
right
like
there
has
to
be
some
so
as
a
for
example,
when
you're,
when
you're
an
aggregated
api
server
and
the
kubernetes
api
server
makes
a
request
to
you
in
the
back
end,
it
sets
a
set
of
headers
the
front
proxy
headers
that
tell
the
aggregated
api
server,
who
the
calling
authenticated
user
wheelchair
so
like.
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
I
don't
trust
those
haters
right
to
me.
This
is
all
of
equivalent
importance
right
absolutely,
but
for
some
reason
we
were
okay,
just
saying
it's
fine
everybody
can
set
it.
That's
really
strange.
B
I
mean
if,
if
you're
you
know,
if
you're
on.
C
B
Then
it
becomes
really
hard
to
abuse
in
any
any
particular
way.
Yeah.
Okay,
so
I
finally
found
the
code
for
mission
as
we
were
talking.
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.
B
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
Right
and
it's
okay.
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.
B
These
are
untrusted
requests,
that's
kind
of
strange,
but
at
least
they
would
know-
or
I
would
know
that
hey
someone
was
trying
to
tamper
with
audit
id,
not
necessarily
maliciously,
but
someone
did
set
it
on
their
own
instead
of
letting
the
api
server
do
it,
and
I
guess
in
a
sense
that
even
that.
B
I
mean
maybe
the
smallest
change
would
be
that
we
we
could
just
enhance
this
code
to
tell
to
also
inside
the
context,
make
it
clear
when
audit
id
was
set
as
a
header
versus
not
right,
and
we
would
only
pass
it
through
when
it
wasn't
set
as
a
header.
E
B
B
B
Oh
yeah
totally,
we
can
it's
it's
it's
more
of
if,
if
we
want
to
use
that
time
to
try
to
get
a
little
bit
more
high
bandwidth
consensus,
I
think
that's
totally
fair,
especially
since,
if
no
one
else
has
anything
to
talk
about
yeah.
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
B
I've
never
read
this
code
before
so
I'm
kind
of
looking
at
like
what
does
this
do
it
like
makes
a
handler
with
some
options
for
the
trace
provider.
E
So
we
basically
need
to
have
the
kms
plug-ins
also
implement
this
right
visualize.
It
all
the
way.
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
Yeah,
that's
yeah.
We
got
like
10
minutes
or
so
so,
let's
maybe
let's
maybe
take
a
few
seconds
so
like
if
we're
we're
gonna
talk
about
so
yes,
so
rita
already
right
now,
so
why
does?
Why
is
submission
request
entering
its
own
uid?
I
think
maybe
what
you
wanna
also
do.
Instead.
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
I
mean
there
might
be
ways
to
make
it
better
right,
like
I'm
trying
to
think
of,
like
you
know
aws
instance
metadata
and
that
style
of
stuff
like
if
you
could
inject
something
at
the
right
place
in
the
host,
and
maybe
you
can
improve
it
a
little
bit,
but
I
think
you
get
like
relatively
mild
benefits
over
what
you
get
with
just
a
regular
unix
domain,
socket
with
good
permissions
on
the
socket.
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
That
is
completely
hard
coded
into
the
api
server.
As
it's
a
one-time
use,
key
using
aes
cbc
for
the
the
value
of
the
you
know,
the
td
data
and
then
it's
just
stored.
D
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
Yeah,
it's
a
definitely
an
interesting
topic,
so
the
question
would
be
if
it's,
what
was
pursuing
it
or
everybody's,
how
many
resources
we
have
right.
So
we
are
all
together.
Five
with
damien.
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
I
guess
like
I'm,
like
you
know,
like
I'm
less
sure,
of
using
ciphers
like
this,
which
don't
support,
authentication
right,
because
I
don't
know
it
doesn't
really
make
sense
to
me
in
like
2022
to
use
non-authenticated
encryption
modes.
B
D
A
D
Check
that,
because
it'd
be
really
annoying,
I
think
there
was
only
some
some
requirements
for
the
heart
for
something
like
like
this,
but
I'm
not
sure.
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.