►
From YouTube: WG-KMS Bi-Weekly Meeting for 20220823
Description
WG-KMS Bi-Weekly Meeting for 20220823
A
B
B
I
think
the
best
way
to
organize
that
at
least
starting
off
is,
unless
you
happen,
to
have
the
link
to
our
board
andy.
Otherwise,
I'm
just
going
to
go.
C
B
C
B
C
But
I
don't
know
how
I
have
access
to
it.
Maybe
you
just
need
to
part,
be
part
of
a
specific
group
to
have
access
to
it.
Yeah.
D
C
C
C
C
B
C
B
We
were
kind
of
following
the
same
pattern
that
we
have
for
the
cigar
triage
board.
You
know
just
the
same
kind
of
swim
lanes.
So,
let's
see,
I
guess
I
can
just
start
with
the
backlog
so
rita.
You
have
the
bug
for
making
it
so
that
custom
resources
get
encrypted
at
rest
because
they
don't,
which
is
sort
of
it
can't
be
no
matter
how
you
try,
it
won't
work.
B
So
this
is
just
a
wiring
mistake
on
our
part.
Well,
somebody's
part,
maybe
not
ours,.
B
It
does
not,
if
you
look
at
the
pr
that
was
closed.
That
was
an
initial
attempt
at
this.
I
got
sign-offs
on
david
and
daniel
smith
that
this
is.
This
is
perfectly
fine.
It's
just
a
bug
fix
and
does
not
require
anything.
B
So
this
has
been
open
for
a
while.
We
just
didn't
fix
it,
because
storing
secrets
and
custom
resources
should
be
fine.
You
should
be
able
to
define
a
fancy
secret
custom
resource
resource.
D
B
D
Just
for
my
knowledge
is
that
is
it
like
encrypted
by
default,
or
does
it
require
to
be
in
the
resource
list
yeah
so.
B
B
So
that's
that's
problematic
for
like,
for
example,
rancher
has
some
token
resource
thing.
That's
a
custom
resource
openshift
gets
around
just
by
having
aggregated
apis
that
still
support
encryption
address
correctly,
but
you
know
openshift
before
moved
to
a
ton
of
custom
resources
and
it's
totally
normal
for
people
to
want
to
put
secrets
in
there
because
that's
what
it's
for
the
resource
you
know
crds
are
generic,
but
this
is
not
necessarily
kms
v2.
It's
just
that.
B
We
want
this
to
just
work
correctly,
so
it's
not
surprising
to
people.
The
one
aspect
of
this,
that's
theoretically
related
to
kmsv2,
which
we
haven't
discussed
yet
in
one
of
these
meetings
is,
but
I
brought
it
up.
I
think
once
before
was
the
some
ability
to
support
like
today.
The
encryption
config
requires
you
to
specify
which
resources
are
encrypted.
B
Please
that
does
require
the
kms
integration
to
be
effectively
bulletproof
or
incredibly,
and
just
incredibly
much
more
resilient
than
the
beta
api
was.
B
The
one
time
I
talked
to
jordan
about
this,
he
was
like
really
crazy,
but
I'll
make
it
better
I'll
make
me
to
not
fall
over.
If
you
have
more
than
five
secrets
or
something.
So
what
do
you
folks
think?
Should
we
add,
do
we
add
well,
should
we
add
that
to
the
cap
as
something
to
get
reviewed
and
have
discussion
on,
I
guess.
A
It's
too
early
for
that
conversation,
I
feel
like
there's
a
lot
of
prerequisites
that
need
to
happen
like,
for
example,
this
bug
needs
to
be
fixed
first,
obviously,
and
the
alpha
thing
I
think
I
mean
in
order
to
do
it
for
all
like.
I
think
it
would
need
to
be
at
least
a
bit
more
mature.
B
No,
I'm
thinking
it
would
just
be
part
of
this
kept
right,
so
the
idea
would
be
is
that
basically,
all
I'm
asking
for
is
some
way
to
tell
the
api
server.
When
I'm
wiring
up
this
kms
provider,
it's
meant
to
encrypt
everything,
not
just
some
particular
resource
right,
so
that
that
you
know
the
trivial
way
to
express
that
is
to
instead
of
having
resource
always
just
me
strings,
you
could
let
it
support
star
star,
for
example,
as
a
way
of
saying
well
stars,
and
just
as
in
stars
and
rbac
arbitrarily
match
any
string.
B
You
could
do
that
as
a
way
of
not
changing
any
apis,
just
enhancing
what
they
can
express
in
place.
The
the
discussion
I
would
want
to
have
with
folks
is
well.
Do
we
want
to
do
that
not
not
of
like?
How
do
we
do
it
in
is
like
do
we
want
to
do
it
at
all?
It's
like,
for
example,
you
could
do
it
today
for
the
beta
api.
I
do
not
recommend
it.
It's
not
going
to
work
out
well
for
you
and.
A
D
C
It
would
be
like,
like
a
really
nice
use
case,
for
that,
and
I
don't
know
if
there's
a
huge
difference,
if
you,
if
you
clear
all
the
secrets
or
everything,
if
something
is
it
doesn't
work,
it
doesn't
work
and
I'll
just
go
for
it.
B
A
B
Yes,
christoph
you
didn't
have
access,
who
else
doesn't
have
access
to
this
board.
B
Can
you
can
y'all
just
ping
me
and
slack
for
github
handles
and
I'll
like
manually?
Add
you
to
the
board.
So
that's
sure
sorry,
it
was
not
intended
to
be
private
because
that's
just
yeah.
B
B
Right
now,
because
I
think
I
created
and
made
me
well
I
mean
an
organ
could
do
whatever,
but
I
think
when
I
because
I
created
the
board,
I'm
implicitly
the
admin
of
the
board,
so
I'm
gonna
go
fix.
That
too.
I
didn't
really
realize
there
was
that
much
r
back
associated
with
the
board.
I
just
made
the
board
and
expected
it
to
work
like
the
old
ones,
but
I
guess
yeah.
I
mean
this
is
a
new
board,
so
I
can
understand
why
it
has
all
this
new
features.
C
Yeah,
this
was
one
of
the
review
comments.
I
think
we
had
during
125,
so
today
we're
using
the
lro
cache.
So
we
use
that
for
v1,
and
then
we
continued
using
that
for
v2
as
well,
and
then
mike
had
a
comment
that,
like
maybe,
we
should
actually
try
using
an
expiring
cash
and
then
mo
also
is
thinking.
If
we
do
that,
we
might
be
able
to
get
rid
of
the
cash
size
in
the
future.
C
B
So
I
yeah
I'm
I'm
a
big
plus
on
not
having
that
knob
just
because
I
don't
like
it,
I
mostly
think
like
you
should
either
set
it
in
like
negative
one
over
a
million
like
there's,
I
really
think
there's
a
cache
everything
retracted,
nothing
not
which
to
me
is
basically
just
a
weird
api
with
the
expiring
cache.
I
think
we
kind
of
get
the
correct
property,
which
is
as
long
as
there's
not
ridiculous
memory
pressure
on
the
api
server.
It's
just
going
to
cache
whatever
it
can.
B
C
B
Yeah,
so
we
would
just
add
validation,
saying
if
you're
using
v2,
you
cannot
set
this
field,
because
this
doesn't
mean
anything
which
is
fine
right.
This
is
the
point
of
having
a
new
api
in
alpha.
It
gives
us
time
to
grow
it
instead
of
stressing
out
about
every
permutation
of
upgrades.
So
I
think
this
is
fine.
I
don't,
I
don't
think
it's
going
to
cause
any
issue.
A
But
but
that
change
needs
to
be,
I
mean
we
need
to
update
the
cap
to
reflect
that
right.
B
A
No,
I
think
you
said
v1,
sorry
didn't
you
say
you.
A
A
A
B
I
had
the
the
mail
thread
open
on
this
one:
did
we
get
approved
to
have
a
repo.
C
Not
yet
I'm
I'm
going
to
ping
dims
because
he
had
approved
the
last
one.
So
I'm
just
going
to
see
if
there's
any
process,
if
they
need
us
to
attend,
lexica
architecture
call
to
just
explain
it,
but
I'll
bring
him
today
and
just
follow
up.
B
Okay
for
folks
context,
so
I've
we
want
to
make
a
new
staging
repo
for
the
kms
code
and
we
will
move
the
proto
and
stuff
in
there.
So
that
way,
if
you
want
to
import
it,
you
don't
have
to
import
the
entire
world
from
kubernetes
land,
because
that's
silly,
but
also
so.
B
This
is
where
I'm
expecting
like
the
reference
implementation
to
live
the
key
hierarchy
code
to
live
any
metrics
code,
just
it
would
all
be
there.
Ideally,
as
you
know,
separate
packages
within
this
repo,
so
people
can
pick
what
they
want
and
use
it
in
their
own
projects.
Also
an
examples
directory
with
like
a
a
full
implementation
of
a
plugin,
basically
using
all
the
pieces.
B
B
C
B
So
that
one's
going
on
so
yeah,
so
I
have
I
have
this
one
assigned
to
me.
B
B
I
had
commented
on
this
on
initial
implementation,
but
we
just
kind
of
ran
out
of
time
in
the
125
time
frame.
So
I
was,
I
didn't,
think
it
was
a
big
deal
not
to
have
it
yet.
As
long
as
you
know
we're
continuing
on
alpha
for
another
release,.
B
Oh-
and
this
was
the
this-
was
basically
the
original
cap
we
had
written
that
we
pulled
out
and
then
made
as
a
sub
item
in
the
second
chapter,
then
forgot
or
didn't,
ran
out
of
time
for
also
which
is
basically
just
logging
logging
within
the
within
the
api
server
logs
to
be
able
to
say
when
you
see
this
uid
on
your
kms
plugin
or
you
know,
whatever
you
see
in
your
key
vault
or
whatever,
wherever
it's
going,
you
can
trace
back
to
what
what
was
the
event
within
the
api
server
that
caused
it
to
do
that,
if
you
so
choose
so
this
person
said
I
want
to
do
this
and
I
was
like
okay,
we
can
respond,
saying,
that's
fine,
I
don't
think
it's
hard
yeah.
C
Yeah,
I
think
the
only
thing
we
had
discussed
in
that
comment
was
you
actually
have
access
to
the
data
context
right.
So
this
is
what
you
have
access
to
when
the
kms
call
comes
in,
which
is
the
path
the
net
cd.
B
Yeah,
so
you
should
have
access
to
the
full
request
info
if
the
request
is
coming
in
from
a
rest
api
handler,
so
you
should
be
able
to
parse
out
that
structured
stuff
and
have
it
available,
and
then
you
should
also
just
include
this:
the
raw
pad
as
a
basically,
you
should
include
whatever
you
have.
B
So
we
can't
always
guarantee
that
oh
mo
tried
to
get
pods
and
that's
why
the
kms
plug-in
was
called.
But
we
could
say,
like
the
at
the
bare
minimum,
we
can
always
say
the
api
server
was
trying
to
do
something.
This
is
why
it
did
that
so
either
way.
I
think
it'll
be
useful.
B
B
Don't
okay,
the
difference
is
that
we,
this
log
is
like
meant
to
be
like
effectively
an
api,
whereas
normally
logs
are
just
like
yeah
human
beings,
read
them
and
kind
of
do
something,
so
this
one's
a
little
bit
harder,
basically
because
it
has
more
a
little
bit-
has
more
strictness
to
what
we're
asking.
B
So,
back
back
in
the
day
in
open
shift,
oauth
tokens,
the
name
of
the
object,
was
literally
the
token
that
was
a
bad
design.
You
should
not
do
that.
B
That
that's
the
obvious
thing
that
comes
to
mind.
If
you
have
names
that
you
somehow
consider
sensitive
right
like
my
secret
project,
because
I
am
like
nsa
and
I
use
fun
names
for
my
objects
based
on
internal
secret
stuff,
that
can
be
bad,
I
guess
group
and
resource.
I
don't
think
so,
because
if
you
can
do
discovery
against
the
api
server,
which
basically
every
user,
can
you
can
see
all
you
can
see
all
the
apis
that
exist.
I
don't
think
grouping
resources
is
particularly
interesting.
All
right.
B
A
B
Yeah,
that
was
maybe
poor
wording
on
my
part
it
like
of
the
stuff
available
to
us.
We
should
carefully
pick
out
what
we
think
is
good,
though
I
I
can't,
I
don't
think,
there's
really
anything
sensitive
other
than
maybe
name
and
name
space
and
they're
not
sensitive
as
much
as
they
might
be
considered
private,
so
that
one
I
mean
it
would
be
kind
of
really
annoying
from
a
log
level
not
to
have
the
namespace
the
name
of
the
associated
object.
B
All
right
so
like,
if
you
want
the
logs
to
be
useful,
they
need
to
contain
the
metadata.
But
if
you
don't
want
blocks
that
contain
anything
that
could
theoretically
be
sensitive
and
they
can't
control
it
and
they
can't
contain
them.
So
I'm
not
really
sure
that's
why
I
had
recommended
something
along
log
level.
Six,
so
it's
not
gonna
just
happen
by
default.
B
Yeah-
and
I
know
we
had
explicitly
said
it
was
out
of
scope
for
now,
but
may
maybe
it's
maybe
maybe
we
just
have
this
at
a
high
log
level,
saying
that
you
know
it's
not
normally
going
to
be
there
and
at
some
point
in
the
future.
We
could
try
to
include
it
in
audit
logs
for
the
things
that
have
white
logs
associated
with
them.
C
So
go
ahead!
Sorry,
no
very
good!
I
was
just
gonna
give
update
like
so
I
finished
the
implementation
part
of
it
and
I
was
able
to
test
it
as
well
like
how
the
changes
can
take
effect,
and
you
know
how
we
can
do
it.
I
think
the
next
part
for
me
is
I'm
just
gonna
start
writing
tests
for
this,
and
hopefully
I'll
make
a
pr
this
week.
C
B
Okay,
I
think
the
only
like
open
question
I
had
in
my
mind
on
the
hot
reloading
was:
do
you
have
to
opt
in
or
is
it
just
a
new
behavior.
C
Right
now,
it's
probably
just
just
a
new
behavior
right.
We
have
not.
We
don't
have
any
flag
or
something
like
that.
B
The
only
concern
I
have
is
like,
for
example,
in
this,
was
telling
me
how,
for
example,
the
azure
like
the
aks
stuff
does
like
how
it
the
actual
core
of
it
uses
this
stuff.
Technically,
it
creates
an
invalid
intermediate
state
when
it
does
it,
which
is
it.
B
It
updates
the
encryption
config
with
a
new
write
key
without
first
having
it
as
a
read
key
right
and
that's
okay
today,
because
until
you
restart
the
api
server,
it
doesn't
matter
yet
right,
but,
for
example,
in
openshift,
when
I
wrote
this
code,
I
always
made
sure
it
didn't
matter.
If
your
api
server
just
crashed
and
burned
in
the
middle
of
it,
there
was
no.
There
was
no
way
for
it
to
come
up
in
order.
That
was
going
to
make
it
right
data
that
other
api
servers
couldn't
read
yet
right.
B
This
might
still
be
fine
like
it
might
be.
One
of
those
like
goes
like
high
priority
release.
Note
like
hey
you
use.
The
encryption
feature,
make
sure
that
your
intermediate
states
are
not
invalid,
because
that's
never
been
allowed.
You
were
just
relying
on
the
fact
that
the
api
server
didn't
immediately
read
them
right,
because,
even
though
the
api
server
is
not
immediately
reading
them,
it
could
crash
at
any
moment
it
just
the
whole
vm
could
oom
and
die
at
any
moment
right.
B
So,
like
right,
the
state
exists
in
a
bad
way,
no
matter
what
it's
just
that
we
would
be
making
this
more
common.
I
I
still
lean
towards
just
doing
it,
because
that
was
sort
of
the
approach
we
took
for
certificates
and
stuff.
It's
just.
C
C
C
C
C
D
C
D
I
think
it's
it's
it's
one
of
the
the
most
interesting
feature,
and
I
I
don't
see
why
someone
don't
want
to
have
that
because
it
this
is
reducing
so
much
work
from
a
day
to
operation
standpoint
and
access
to
specific
resources
too,
so
to
be
able.
C
Yeah,
my
only
concern
is
if
we
are
not
thinking
about
some
corner
case
and
if
they
upgrade,
then
we're
basically
breaking
them
without
a
way
to
get
back
to
our
working
state.
So
if
we
introduce
like
a
flag
that
just
allows
them
to
like
disable
it
in
one
or
two
releases
and
then
like,
if
we
don't
get
any
complaints
like
it
can
be
one
of
those
flags
which
is
enabled
by
default,
but
with
an
option
to
disable.
B
B
Gonna
change
your
api
for
you,
I
know
mike
wasn't
super
excited
about
like
how
are
you
loading
this
and
I
was
like
dude.
I
just
don't
want
to
really
build
a
kms
cache
every
time
like
it's
just
it's
just
slow
like
it
doesn't
matter
how
performant
you
make
the
api
at
the
end
of
the
day,
making
a
bunch
of
network
calls,
but
it's
going
to
be
slow,
sometimes
so,
okay,
then
we
have
the
the
next.
Two
are
the
same
thing
I
think
once
the
issue
and
once
the
proposed
pr,
which
is.
B
So
we
want
to
undo
that-
and
I
was
not
a
fan
of
the
proposed
approach
of
just
expanding
the
transformer
interface
to
just
basically
have
a
no
op
method
in
99
of
cases,
and
in
one
place
it's
not
a
no
up,
so
I
was
gonna.
I
was
gonna
ask
for
a
better
approach
that
only
made
transformers
that
need
to
be
stopped.
Have
such
a
thing.
B
But
either
way
this
this
is
just
a
regression
to
our
test
suite
that
we
caused,
because
we
ran
out
of
time
and
I
was
going
to
merge
a
bandage
fix
for
it.
But
then
it
was
pass
code
freeze
and
I
was
not.
I
was
not
about
to
violate
job
freeze
over
a
nice
to
have
so
that's
just
another
thing
that
we
have
to
do.
C
Yeah
yeah,
then
this
is
all
just
our
context.
This
is
not
specific
to
we
do
so
like
we
had.
This
is
also
changing
v1
like
the
way
it's
done.
B
In
a
very
minor
way,
it's
just
allowing
open
connections
to
be
closed.
When
the
system
is
exiting
effectively,
which
happens
a
bunch
of
times
in
tests,
it
doesn't
realistically
happen
on
production
clusters
because
they
start
up
and
then
they
go
down,
but
they
don't
they
don't.
The
same
process
does
not
like
start
up
and
go
down
over
and
over
internally
right.
B
The
tests
do
get
that
a
bunch
of
the
go
routine.
Leakage
can
kind
of
explode
that
way.
So
that
covers
what
we
have
on
the
board
right
now.
So,
what's
not
reflected
on
the
board,
is
reference
stuff,
like
reference
implementation,
stuff,
that's
still
in
an
issue
tracker,
so
I
mostly
because
initially
I
ran
out
of
time.
So
we
haven't
gone
through
and
curated
that
stuff
into
issues
yet,
and
then
this
stuff.
B
Yeah
we
should,
in
general
I
I've
been
thinking
about
how
to
enhance
the
v2
api
to
make
the
rotation
story
much
better.
So
we
we
talked
a
bit
in
that
original
cap
about
the
storage
version,
hash
and
stuff,
and
then,
when
I
talked
to
api
machinery
they're
like
yeah,
that
api
has
been
alpha
for
two
years
and
I
was
like
yeah:
can
it
not
be
alpha
like
no,
because
no
one's
working
on
it,
so
it's
still
in
alpha
state,
hasn't,
hasn't
moved,
not
because
it's
good
and
done
it's
still
not
done
so.
B
I've
been
reading
the
caps
and
stuff
and,
of
course,
the
caps
don't
line
up
with
the
code
inside
of
the
api
server.
So
that's
always
fine,
so
I'm
still
trying
to
figure
out
what
to
do
here.
I
talked
with
initial
bunch
about
this.
B
One
high-level
approach
that
I
had
was
to
basically
funnel
like
some
kind
of
identifier
and
the
state
of
the
api
server
to
the
plug-in,
and
then
let
the
plug-in
do
something
with
it.
With
like
a
theoretical
implementation
that
we,
we
could
write
like
as
an
open
source
thing
that
people
could
use
if
they
wanted
to,
could
use
some
custom
resource
to
coordinate
the
api
servers
and
what
key
id
they're
on
and
then
wire
that
up
to.
B
B
I
the
thing
I've
been
struggling
with
this
on
is
how
much
of
this
should
just
be
part
of
the
kms
feature
set
like
I.
I
struggle
to
think
about
this
stuff,
like
if
you're
going
to
go
through
the
effort
of
having
like
this
kms
integration.
Are
you
really
not
going
to
have
any
rotation
story
like?
Are?
You
is
rotation
really
optional
for
you
and
it
might
be
like
in
your
alpha
implementation,
but
it
will
quickly
show
up
as
a
request
for
anyone
that
actually
cares.
B
So
I
was
trying
to
think
of
like
if
it
made
sense
to
have
dedicated
dedicated
feature
sets
within
the
api
server.
To
do
this.
B
B
That's
half
done
so
that's
kind
of
where
I'm
at
on
this,
but
for
me
like
for
126,
like
the
the
priorities,
are
coming
up
with
some
strategy
for
rotation
for
kms
v2
and
getting
kristoff's
reference
stuff
in
so
that
way,
that
way,
we
have
that
baseline
and
we
can
start
working
on
it
together.
C
Yeah,
I
think,
like
we
should
probably
like
share
that
create
a
dock
with
what
we
had
discussed
and
then
like.
We
can
go
that
I
think
most.
You
are
also
suggesting
we
can
just
open
a
pir
on
the
cap
and
keep
adding
details
there
or
like.
Maybe
we
can
start
with
the
dog
with
what
we
discussed
and
then
like
see
what
other
folks
think
as
well.
B
Yeah,
since
since
we
chatted,
I,
I
found
some
like
issues
in
not
like
intractable
issues,
but
I
found
some
like
edge
cases
that
we
would
have
to
handle
the
the
harder
part
I'm
trying
to
have
that.
B
If
I,
if
I
look
at
the
existing
caps
from
the
api
machinery
folks,
they
have
a
lot
of
complexity,
around
api
server
identity
and
like
how
it's
like
they
have
like
three
or
four
different
caps
on
basically
that
that
are
intertwined
around
the
same
thing,
and
I
was
trying
to
come
up
with
like
what
is
like
the
minimum
thing
in
this.
That
actually
has
the
right
properties
without
all
of
this
like
and
I'm
just.
I.
B
I
just
need
to
read
a
lot
more
of
the
api
server
code
in
this
area
like
just
get
because
they
have
pieces
and
controller
manager.
Then
they
have
pieces
in
the
api
server
and
they're
all
using
a
bunch
of
them
have
like.
If
statements
on
like
one
or
two
feature
flags
being
enabled.
So
I
was
like
okay,
that's
cool!
B
No
one's
going
to
be
able
to
reason
about
how
which
of
these
pieces
is
actually
running
on
this
cluster
and
like
it
was
weird
because
they
were
like
yeah
we're
gonna
put
one
of
these
controllers
in
the
controller
manager
and
the
other
one.
A
B
The
api
servers,
because
we
want
to
leverage
some
picture
from
one
place
another
I
was
like.
I
don't
find
this
to
be
a
benefit.
I
find
this
to
be
a
way
of
confusing
people,
because
now
different
components
like
logically
run
the
stuff
and
they
have
different
versions
right,
like
the
api
server
and
the
controller
manager,
are
different
binaries.
So
now
you
have
to
like
remember,
which
one
is
running
at
what
version.
B
So
it's
just
it's
just
kind
of
messy,
and
I
was
like
it
that
the
concern
I
have
with
any
like
optional
external
approach
is
the
complexity
of
running
that
stuff
has
been
offloaded
to
the
poor
soul.
That
has
to
run
it,
and
so
they
have
to
understand
the
ordering
and
everything
of
all
those
components
in
their
config
and
how
it
all
relates,
and
there's
a
lot
of
moving
pieces.
B
B
I,
even
if
you
ignore
the
the
storage
migration
step
like
if
we
could
get
to
the
point
where
rotation
was,
you
change
your
key
id
and
your
kms
key
vault
and
you
somehow
are
then
at
the
end
of
it
all
notified
that
hey
you're,
ready
to
do
storage
migration,
and
so
you
just
run
storage
navigation
like
that
sounds
so
much
better
than
run
these
seven
components
with
exactly
wired
up
config,
and
then
they
do
basically
that,
but
like
none
of
it's
internal
like
it's
and
you
know
it's
all
technically
optional,
so
that
yeah,
I'm
just
I'm
just
struggling
with
convincing
myself
that
having
this
stuff
be
optional,
is
or
not
not
in
the
core
is
a
good
idea.
B
Just
putting
it
in
core
limits,
the
flexibility
we
have
overall,
because
it
has
to
do
just
one
thing.
Basically,
I
just
think
doing
that
one
thing
is
better
than
letting
people
kind
of
go
like
you
know:
that'd
be
okay
with
some
flag,
just
turn
off
the
internal
control
groups
and
you
get
to
do
whatever
you
want
like.
I
don't
really
care
about
that
part.
I'm
more
about
the!
B
B
You
don't
spend
a
bunch
of
your
team's
times
getting
everything
set
up
right
and
you
know
your
customers
might
ask
for
like.
I
want
to
have
my
own
key,
and
I
want
to
locate
myself
fine,
whatever
that
that
should
be
possible,
but
the
I
just
want
the
security
by
default
should
be
the
easy
step,
not
the
hard
step
and
right
now,
I
feel
like
it's
going
to
end
up
being
a
hard
step
still,
unless
we
build
more.
B
If
you
don't
have
any
thoughts
on
the
last
thing,
I
was
gonna
ask
rom.
I
know
you
have
those
two
issues.
If
you,
if
an
issue,
if
you
could
pull
them
up,
maybe
we
could
talk
through
them.
Some.
I
wanted
to
just
kind
of
get
some
explanation
and
stuff
from
you.
So
that
way,
when
we
talk
about
it
with
other
folks,
I
have
a
little
bit
like
I
read
it,
but
like
I
wasn't,
it
wasn't
always
exactly
clear
to
me.
Yeah.
D
So
the
first
one
that
you
pulled
up
here,
it's
the
remove
yeah.
So
this
one
can
be
closed
against
the
issue
that
was
discussed
on
the
eleven
one,
one,
one,
nine
one,
nine
for
the
odd
reload,
because
basically
this
one
was
to
remove
the
concept
of
the
holder
and
the
ordering
within
the
file
so
that
we
don't
have
to.
D
We
start
all
the
time
the
api
server
when
we
do
a
such
a
change
and
it's
it's
just
not
about
the
order,
but
it's
adding
adding
new
providers
and
and
and
and
so
on,
so
because
it's
it's
really
painful
and
most
of
the
time.
Well,
not
most
of
the
time.
But
quite
often
when
we
do
this,
it
means
that
we
have
to
go
back
to
the
the
control
plane
and
start
with.
We
start
the
the
api
server.
D
So
it's
it's
kind
of
painful
and
it
would
also
help
and
that
I'm
grateful
for
the
the
hot
reload
effort
for
the
manage
kubernetes
offerings
because
obviously
there's
no
access
at
all
to
the
ability
to
restart
an
api
server
there.
So
so
this
one
can
be
definitely
closed
against
that
reloads
issue.
B
So
that
part
makes
sense.
The
bit
about
order
is
unclear
to
me
what
what
what
about
ordering
is,
assisted
or
not,
with.
D
So
yeah,
so
the
ordering
is
part
of
the
the
other
issue
that
I
opened,
because
when
we
see
that
most
of
the
time
when
we
implement
stuff
we've
got
when
we
implement
true
surface
as
an
example,
as
a
provider
plug-in
with
customers,
they
often
not
change
anything
about
the
the
file,
so
they
they
might
have
the
identity
first
and
then
the
kms
provider
in,
and
they
don't
understand
why
it's
not
encrypted.
D
So
we
have
to
explain
them
and
they
need
to
change
the
order
in
because
that's
the
way
it
is,
it's
gonna
look
at
the
the
file
and
if,
if
the
kms
is
second,
it's
not
gonna,
it's
not
gonna
work
so
that
that's
that's
more
like
a
day.
D
Two
misunderstanding
issue:
I
think
I'm
coming
back
on
my
statement
earlier
about
the
it
would
help
on
manage
services
like
aks
and
sound
when
we
don't
have
access
to
the
control
plane,
because
we
actually
will
not
have
access
to
the
file.
So
it
will
not
help.
D
So
that's
something
that
just
occurred
to
me
right
now,
the
so
that
that's
that's
the
part
and
the
ordering.
The
the
reason
why
I
I
would
love
to
remove
the
ordering
also
is
to
be
able
to
think
about
having
multiple
kms
encryption.
We
have
that
use
case
with
a
customer
government
customers
where
they
do
multi-tenancy
and
they
wish
to
have
multiple
different
kms,
because
each
tenant
might
come
up
with
their
own
kms
provider
and
or
a
set
of
keys
whatever
and
and
then
that's
the
moment
they
would.
D
D
So
I
just
put
an
example
there,
I'm
I'm
the
noob,
so
I
just
came
up
with
an
an
annotation
approach
where
you
would
define
a
kms
provider
by
using
the
name
of
the
the
id
from
the
encryption
comparison.
The
encryption
configuration
file
that
would
allow
them
to
to
target
a
specific
kms
in
that
that
file.
B
B
Yes,
I
realize
that
having
this
as
files
on
disk
makes
it
problematic
to
talk
about
from
a
kubernetes
api
perspective
problematic
to
interact
with,
but
that's
actually
like
part
of
the
design
of
it
right
like
the
it
is
a
unix
domain
socket
on
the
host.
Yes,
because
it's
it
like
the
persona,
that's
responsible
for
this
is
the
infrastructure
operator.
So
you
as
the
kubernetes
cluster
admin,
don't
get
a
say
you
you,
as
a
customer
to
that
operator,
need
to
tell
them.
B
I
will
pay
you
money
if
you
give
me
up
the
choices
here,
but
not
because
that's
what
like
it
like
you,
you
can't
realistically
start
talking
about
uds's
through
the
kubernetes
api
right,
because
they're,
like
you,
can't
orchestrate
that
it
has
to
exist
a
front
from
in
the
infrastructure
right,
it's
very
deeply
tied
to
like,
or
are
you
running
the
control
plane
as
pods?
Are
you
running
on
just
bare
metal
as
processes
like
people
kind
of
go
crazy
on
how
they
deploy
kubernetes?
B
And
I
mean
that's
great,
I
guess
I'm
a
little
dubious
about
the
flexibility
on
on
these
components,
but
whatever
that's,
I
guess
people
love
their
toys
and
want
to
play
around
with
them.
So
I
I'd
be
very,
very
nervous
about,
like
so
already
within
kubernetes.
Oh,
if
not
within,
like
within
sight,
we've
already
taken,
the
stance
of
policy
cannot
be
subdivided
within
namespaces
right.
That's
why
pod
security
admission
is
just
based
on
labels
on
namespaces,
with
the
explicit
asset
like
within
the
namespace.
There
is
no
segregation.
B
B
B
I
don't
know
like,
I
don't
think
it
makes
that
much
sense,
or
I
mean
what
am
I
trying
to
I'm
I'm.
I
would
be
concerned
about
even
at
the
name
space
level
having
some
way
of
talking
about
kms
plugins,
like
as
a
for
example
like
if
you
typo
the
name.
What
is
supposed
to
happen,
yeah,
like
it's
like
everything's
supposed
to
fail
in
the
space
is.
Is
it
silently
supposed
to
keep
working
like?
B
D
This
is
representing,
like
20
of
the
actual
reality
in
the
world,
because
80
of
the
platform
and
I'm
using
platform
here
instead
of
infrastructure
platform
owner,
are
also
the
communities
admins
and
and
that
that's
where
there
there's
a
there's
a.
I
think
it
works
well
in
that
construct
for
cloud
providers
where
indeed
you're
paying
a
provider
to
to
do
whatever
you
want
or
not,
actually
as
a
secret
as
a
security
standpoint.
D
But
the
reality
is
that
there's
a
lot
of
as
you
were
mentioning
people
who
their
their
environment
as
they
wish,
and
that
that
those
people
are
the
same
people.
Sadly
that
are
owning
both
both
hats.
D
B
B
Agree
with
you
that
both
parties
exist.
Yes,
where
or
both
scenarios
exist,
where
the
infrastructure
provider
and
the
kubernetes
cluster
admin
are
the
same
persona
or
the
same
human
versus.
Not
so
I
agree
with
you
totally
there
so
to
trying
to
come
up
with
some
way
to
support
that
the
closest
thing
I've
been
able
to
think
of
which
is
still
half
done.
Thought
is
either
support
within
the
encryption
configuration
itself
to
say
you
know
some
set
of
name
spaces
like
today.
It's
a
group
resource
right,
it
could
be
groups
resource
namespace.
B
Instead
of
having
an
encryption
in
the
encryption
configuration,
you
could
have
it
as
part
of
the
metadata
of
requests
made
back
to
the
plugin
so
like
the
multiplexing
could
happen
at
the
kms
plugin
level
itself,
saying
like
hey,
I'm
asking
you
to
encrypt
something
and
the
namespace
that's
associated
with
that
something
is
fubar,
so
the
the
problem
there
is
it
it.
B
It
breaks
the
pid
concept
we
have
today
because
it's
global
to
the
plug-in.
So
I
don't
think
that
works
out
or
not
in
the
current
iteration.
Nice
thing
is
all
alpha,
so
we
can.
We
can
change
it
and
do
what
we
need
to
do
so,
I'm
still,
I
haven't
come
up
with
something
that
makes
me
go.
Yay
like
this
will
work.
A
Well
also
like,
because
this
is
very,
it
introduces
a
lot
of
nuance
and
and
perhaps
not
backward
compatible
right.
I
I
definitely
want
to
see
if
there
are
more
users
who
want
this.
This
is
why
I
asked
you
to
open
this
issue,
and
you
know
again
per
your
comment
earlier
right.
If
they're
more
there
there's
a
lot
more
users
that
want
this,
we
would
like
to
see
more
plus
ones,
and
so
far
we
haven't
seen
it
yet
yeah.
B
I
guess
there's
no
there's
no
limit
on
key
id,
it's
just
a
string.
You
can
put
anything
you
want
in
there.
So
if
you
were,
if
you
wanted
to
you,
could
you
could
represent
multiple
key
ids
in
there
as
like
an
encoded
json
object?
If
you
wanted
or
whatever
like
you
know,
however,
you
wanted
to
limit
them,
so
you
could
still
probably
make
it
work.
D
Oh
yeah,
so
with
with
the
with
truso,
we
made
some
kind
of
a
concept
where
we
we
targeting
multiple
different
kms
providers
like
aws
and
and
vault,
and
so
that
that's
working
somehow,
but
it's
it's.
D
It's
lacking
the
ability
to
to
do
it
in
an
easy
way
by
defining
label
or
an
annotation
from
a
user
perspective.
So
it's
it's
requires
a
lot
of
moving
pieces
to
do
it.
As
you
were
mentioning
earlier,
with
the
storage
for
migration,
with
having
the
ability
to
have
crds
and
all
those
components
we
we
can
do
it.
It's
not
it's
not
a
problem.
It's
just
like
the
complexity
of
such
a
solution,
so
yeah.
D
Yeah
that
that's
maybe
it's
coming
back
to
what
mo
was
mentioning
about,
having
a
different
approach
from
the
encryption
configuration
file
where
we
could
add
something
there
to
mention.
You
know
like,
instead
of
getting
the
name
or
defining
a
group
of
a
namespace
or
I
don't
know,
but
instead
of
naming
the
actual
providers,
I
guess
it's
more
the
creation
that
we
will
fail.
So
if
it's,
unless,
unless
it's
it's
changed
on
the
go,
it
should
just
failed
and
give
an
error
right.
D
C
B
Mean
if
I
think
you
know
assuming
we
can,
if
we
ignore
the
complexity
for
a
second
feedback
on
needing
such
a
feature
for
a
second
like.
If,
if
we
were
to
implement
this,
I
think
it
needs
to
stay
in
the
veil
of
the
infrastructure
operator.
Persona
like
it
needs
to
stay
within
the
things
that
they
can
fully
control,
because
you
need
to
guarantee
that
it
works
that
persona
right
and
that
that
means.
B
Like
if
we,
if
we
were
trying
to
do
this
truly
as
a
kubernetes
api,
it
would
probably
require
changing
object,
meta
and
I
can
guarantee
you
cigars
will
deny
me
changing
object
meta,
because
the
bar
for
changing
object.
Meta
is
just
impossibly
high
now,
because
it
has
to
be
perfectly
consistent
across
the
kubernetes
api
and
what
it
means
and
yeah
we've
had.
B
I
think
the
last
time
we
changed
it
was
for
paging,
but
yeah,
it's
just
a
really
high
bar
and
it's
it's
it's
hard
to
make
everything
work
perfectly
with
it
because
of
how
expressive
the
kubernetes
api
is.
So
I
don't,
I
don't
think
we're
going
to
get
success
there.
B
I'm
also
concerned
about
the
name
space
type
approach,
because
not
all
resources
are
name-spaced
sure,
and
maybe
you
could
argue
that
you
cannot
apply
multi-tenancy
to
like
nodes
on
your
on
your
kubernetes
api,
because
there's
no
way
to
express
like
who
can
mess
with
the
note
object,
like
other
than
directly
saying
you
can
you
know
you
can
edit
this
node
and
this
other
node
and
that
other
node
and
somehow
you
know
the
names
that
you
can
edit.
So
you
can
go
mess
with
those,
but
not
other
ones.
D
Yeah,
I
think
we
can.
We
can
still
prototype
this
from
our
plug-in
perspective,
so.
B
D
We'll
we'll
we'll
do
it
in
a
different
way,
so
here
the
the
when
we
discuss
with
so
we
have
two
major
government
agency
that
we're
working
with
one
is
the
equivalent
of
the
open
security,
but
for
europe
and
the
other
one
is
in
hong
kong
and
we
were
discussing
about
that
approach
of
multi-kms
because
they
need
it.
So,
basically,
if
you
think
about
those,
they
have
a
massive
communities
clusters
2000
nodes.
D
D
Multiple
providers
trying
to
do
something
that
we
would
require
the
very
same
running
component
deployed
to
make
it
happen
so
that
that's
the
that's
the
reason
why
so
removing
as
much
of
the?
D
But
I
think
it's
it's
as
you
were
mentioning
it's
a
question
of
moving
the
complexity
from
one
side
to
another,
and
I
think
the
impact
on
the
do
we
want
to
have
the
impact
on
the
platform,
or
maybe
just
on
the
the
plugin
for
that
specific
tenants,
because
otherwise
we
would
have
if
there's
something
that
goes
south
the
entire
platform
and
the
entire
tenants
might
be
at
risk.
B
Oh,
I
I
just
as
an
fyi
the
way
kubernetes
was
built
today,
no
matter
what
we
do
here.
If
a
single
kms
plug-in
that's
encrypting,
a
single
secret,
if
it's
unavailable,
oh
yeah,
yeah,
yeah,
we
and
that's
by
design.
Sadly,
because
kubernetes
requires
fully
logical,
consistent
lists,
so
a
single
rear
in
that
list
means
the
platform
stops
working.
So,
within
the
scenario
that
you
just
described,
you
need
100
availability
from
every
single
one
of
those
plugins.
C
B
D
That
we
don't
have
any
interesting
outcome,
which
was
the
case
on
the
first
implementation,
yeah.
B
D
B
B
It's
it's
always
nice
to
have
customers.
That
say
I
want
a
thing
because
you're
building
the
right
things,
instead
of
a
thing
that
someone
wants
instead
of
just
guessing
but
yeah,
this
one
is
hard.
I
I
I
don't
have
good
answers
on
this
one.
Well,
I'm
not
gonna
say
I
have
good
answers
on
any
of
the
stuff
we
talked
about,
but
when
I
definitely
don't
have
a
good
answer
for
it.
D
Okay,
I
will
I
will
ask
the
different
customers
to
come
and
put
attempts
at.
B
Yeah
and
if
I
don't
know
how
late
the
sega
meeting
is
for
you,
but
if
you
can
attended
that
that'd
be
great,
it's
much
much
easier
for
you
to
represent
your
view
instead
of
us
trying
to
do
it
for
you,
okay,.
D
I'm
currently
so
so
I'm
based
so
the
funny
thing
is
that
I'm
I'm
based
in
between
two
continents,
because
I'm
I'm
in
san
jose
for
the
moment.
D
And
but
otherwise,
I'm
based
in
the
netherlands
for
the
job,
but
we
I
do
back
and
forth
for
personal
reasons.
So.
D
Yeah,
that
would
be
fantastic,
yeah,
definitely,
but
it
should
be
in
amsterdam
next
year,
so
yeah.