►
From YouTube: Pinniped Community Meeting - September 16, 2021
Description
Pinniped Community Meeting - September 16, 2021
We meet every 1st and 3rd Thursday of the month at 9am PT. Would love for you to join us live!
Full agenda can be found here: https://hackmd.io/rd_kVJhjQfOvfAWzK8A3tQ?both#September-16-2021-Agenda---Margo-Guest-Emcee
A
Hi
and
welcome
to
today's
edition
of
the
pen
community
meeting
today
is
september
16th
2021.
If
you're
watching
this
from
home,
we
encourage
you
to
come.
Join
us
live
we
meet
on
the
first
and
third
thursday
of
the
month
at
9
00
a.m.
Pacific
time
it's
an
opportunity
to
listen
to
what
the
maintainers
are
working
on,
provide
live,
feedback,
ask
questions
or
get
live
help
with
in
a
bed.
A
A
If
you
have
anything
you
wish
to
discuss
with
the
team.
Please
add
that
to
the
discussion
topic
section
at
the
end
of
the
agenda,
we
also
ask
that
you
add
your
name
and
organization
to
the
document
so
that
we
know
who's
attending
and
keep
lines
of
communication
open.
You
can
also
add
a
comment
to
the
github
discussion,
talking
about
how
you
use
pinniped
and
include
your
company's
logo.
So
we
can
promote
your
organization
and
learn
more
about
how
people
use
pitifed
for
the
announcements.
A
A
B
B
A
Hopefully,
today
we
we
found
a
couple
of
bugs
in
the
0.11
release,
one
of
which
was
with
validation
using
cube
ctl
apply.
Unfortunately,
we
mostly
used
cap
on
our
team
and
in
our
tests.
So
we
didn't
catch
that
something
you
can
work
around
by
just
not
validating
everything,
but
still
unfortunate,
and
then
another
bug
related
to
updating
or
deleting
recreating
the
bind
secret
for
active
directory
sort
of
messing
up
some
caching
and
also
has
a
workaround.
A
D
So
this
would
be
evident
to
an
end
user
if
they
tried
to
perform
a
login
through
the
pinniped
coupe
cuddle
plugin,
and
they
got
messages
about
the
service
not
being
available,
and
typically
they
would
see
that
message
about
one
third
of
the
time
if
they
were
affected
at
all
and
so
we've.
We
believe
that
we
have
fixed
that
bug
in
the
upcoming
release
that
we're
about
to
put
out.
B
A
E
B
B
I
I
started
on
it,
but
it's
just
a
little
too
early
like
I
can
talk
about
it,
but
I
have
it
in
my
head.
If
people
want
to
talk
about
it,
but
it's
probably
probably
not
digestible
in
that
form,
if
you
like,
like
some
written
text
with
some
diagrams
and
sometimes
you'll,
actually
understand
what
I'm
talking
about.
A
D
B
B
B
B
Okay,
so
the
high
level
problem
statement
is,
if
you
have
a
running
supervisor
somewhere
and
that's
riser
has
valid
certificates,
which
you
should
always
because
we
expect
people
to
use
it
in
the
browser.
So
if
you
don't
configure
it
that
way,
nothing
good
is
going
to
come
out
of
it
and
your
it
administrator
somehow
tells
you
the
url
of
the
supervisor,
maybe
something
like
kubernetes
auth.company.com,
so
something
that's
sort
of
easy
for
you
to
remember.
B
B
B
So
pretty
immediately
from
a
user-facing
perspective,
any
api
that
we
add
on
the
supervisor
has
to
has
to
be
part
of
the
federation
domain,
because
that's
basically
what
we
just
said
right,
the
design
is
immediately
limited
by
that
the
user
does
not
know
of
kubernetes
cluster
underneath
or
the
fact
that
it
even
is
a
pretty
nice
customer.
They
only
have
access
to
the
federation
of
them
right.
They
don't
have
any
cluster
relaxes,
so
we
would
have
to
build
apis
on
the
federation
domain.
That
did
something
like
this.
B
B
Theoretically,
you,
if
you
wanted
to
be
really
awful,
you
could
try
to
hack
the
existing
endpoints
to
return
extra
data.
I
think
that's
still
compliant
with
the
watts.
Why
do
you
suspect
to
send
expert
dips
back?
I
would
say:
don't
do
that.
It
just
seems
like
a
hack.
Also,
since
you
can
add
extra
end
points
to
the
federation
domain.
If
you
want
I'm
not
really
sure
we
would
want
to
just
hack
on
stuff
to
like
the
code
response
or
something
so
the
the
way
I
thought
about
this,
in
my
mind,
was.
B
By
that,
what
I
mean
is,
if
you,
for
example,
are
using
the
impersonation
proxy
today
and
you
hand
out,
keep
config
from
that.
If
you
want
to
change
the
certificate
conserve
insert
of
the
impersonation
proxy,
for
whatever
reason
that's
disruptive
to
your
users,
so
you're
basically
encouraged
never
to
do
that
right
in
the
same
way.
B
B
Basically,
building
off
of
that,
you
can
imagine
an
api
where
an
iit
admin
registers
on
the
federation
domain,
the
intent
to
have
the
concierge
be
part
of
that
federation
domain
and
then,
on
the
other
side,
the
concierge
registers
that
federation
domain
much
more
specifically
than
a
dial
authenticator,
does
today,
like
it's
explicitly
saying.
I
want
to
use
this
federate.
This
supervisor.
C
B
Yeah,
you
can
start
making
assumptions
in
your
code
about
well
like
this.
This
is
a
supervisor
federation
domain
and
not
just
like
google's
endpoint
or
something
so
once
you
have
that
you
can
effectively
build
a
handshake
between
those
components
right,
so
the
supervisor
can
validate
a
concierge
just
trying
to
talk
to
it
and
which
concierge
it
is,
and
you
can
validate
a
service
account
token
coming
in
from
that
concierge.
As
a
way
of
saying
you
are
indeed
the
concierge.
B
I
think
you
are
right
so
then
the
information
that
the
concierge
sends
it
is
at
least
somewhat
trustworthy.
I
think
there's
still
some
careful
design
work
there.
For
example,
the
audience
always
has
to
come
from
the
supervisor.
It
can't
come
from
the
concierge,
so
this
will
end
up
being
a
bi-directional
api
right.
B
So,
like
the
concierge
would
say
I
would
like
to
be
part
of
your
federation
domain
and
the
federation
domain
would
be
like
cool
here's,
your
audience
once
all
that
stuff
is
done
but
like
there
would
be
an
initial
registration
and
then
or
like
there
would
have
to
be
some
mechanism
for
this
to
be
kept
up
to
date.
So
that
way
as
if
the
concierge
changes
this
configuration
over
time,
yes,
your
cube
config
might
become
invalid,
but
the
act
of
fixing
the
key
config
is
very
trivial.
B
Just
run
like
I
don't
know
in
the
supervisor:
login
url,
that's
it!
Your
your
stable
endpoint
is
the
federation
domain
and
not
any
particularly
config,
which
I
think
would
be
a
pretty
nice
sort
of
middle
ground.
That
way,
if
you
know,
if
an
I.t
admin
migrated
away
from
the
impersonation
proxy
to
like
the
new
flow,
they
could
leave
the
impersonation
proxy
working.
B
But
the
new
flow
would
be
the
preferred
approach
so
that
when
users
did
run
that
command
again,
they
would
get
a
better
to
config
the
next
time
all
right.
So
then
they
can
build
a
buffer
right.
They
could
say
we
have
one
month
or
n
number
of
months
before
the
conflict
will
stop
working,
and
this
is
what
we
have
done
in
our
commercial
products
before
for
our
sas
offerings,
it
was
when
they
migrated
from
the
old
concierge
the
dot
4
branch
where
it
was
the
concierge,
was
a
namespace.
B
The
apis
were
all
named
spacecode
to
the
cluster
scope.
Since
that
was
a
breaking
change.
They
ran
both
the
old
and
new
versions
of
the
concierge
in
those
environments
and
basically
told
customers.
They
had
a
couple
of
months
to
upgrade
like
they
just
needed
to
run
the
command
again
to
get
a
new
config
and
that
allowed
them
to
sort
of
do
that
kind
of
transition.
B
That's
the
kind
of
floor,
I'm
thinking
it's
basically
a
very
limited
configuration
on
the
part
of
the
ip
admin
right
basically
saying
this
is
how
you
find
the
concierge
and
like
on
the
concierge
side.
It's.
This
is
how
you
find
the
supervisor
and
the
rest
is
dynamic
and
fade.
That's
sort
of
handshake
when
you
do
respond
by
those
components,
and
once
you
have
that,
then
you
don't
really
have
to
maintain
it
over
time,
like
the
components
get
to
maintain
those
right.
B
Yeah,
well
I
mean
the
ik
admin
will
always
kind
of
keep
config
if
they
wanted
to,
because
I'm
not
being
private
about
that.
But
you
don't
need
to
the
the
thing
you
need
to
hand
out.
Is
the
federation
domain
issuer
url
from
the
supervisor
and
the
knowledge
of
typing
in
like
some
pinpoint
command
like
printer
supervisor
login,
so.
B
Yeah,
you
know
like
how
you
log
into
like
the
g
cloud
cli
right,
like
you,
have
the
concept
of
logging
in
and
asking
for
two
configs
back
right.
This
is
in
that
same
way,
right,
like
you
log
in,
and
you
know,
there's
no
reason
that
you
have
to
keep
the
name
of
the
piniped
cli
like
pinpad
right.
You
could
rename
it
to
something
that
made
more
sense
in
your
environment,
but
the
idea
is
to
instead
of
saying
you
somehow
get
a
tube
config
and
you
use
it.
B
The
idea
is
you're,
saying
you
log
into
your
kubernetes
environment,
and
then
you
can
pick
which
cluster
you
want
to
use
right
so
like
once
you
have
this
right,
you
can
have
higher
order
apis
on
the
federation
domain
that
are
like.
I
would
like
to
get
all
the
clusters
cool.
I
see
I
have
seven.
I
would
like
that
you
can
fake
further
one
called
dev,
seven.
B
D
B
B
B
Was
it
the
the
actual
apis
for
doing
this
much
more
sort
of
open-ended
the
other
bit
that's
kind
of
in
interesting
and
weird
is
like
the
like.
The
way
we
would
write
the
code
for
this
like
in
the
way
we
want
today
would
be
like
controllers
doing
all
this,
but
that
would
mean
that
the
federation
domain
would
have
to
support
list
and
watch
which
is
not
necessarily
easy.
B
It's
not
necessarily
hard
either,
but
if
we
wanted
to
actually
continue
to
write
controllers
for
all
this
stuff,
we
would
have
to
have
that
semantic
available.
We
could
always
just
do
polling
and
just
say:
yeah,
take
some
time,
take
some
number
of
minutes
or
whatever
for
it
to
figure
out.
If
you
can
pay
changes
that
might
be
okay.
B
B
Yeah
we
haven't
built
that
feature.
Yet.
No
I'm
saying
no
one
has
even
asked
like
we
have
thought
about
it.
It's
like
not
a
bad
thing
to
build,
but
no
one
has
asked
exclusively
either
like
the
closest
I've
heard
for
like
network
topology
is
like
please
like
stop
deploying
this
other
image
for
your
keemstar
agent
or
something
like
like.
Basically,
I
want
all
the
images
to
be
locally
hosted
on
my
cube,
but
stop
trying
to
fetch
stuff,
because
there
is
no
network
on
the
keyboard
to
fetch
anything
so
that
that
makes
sense
right.
B
I,
since,
like
the
whole,
like
docs,
end
point
and
stuff
right
like
they
exist
as
endpoints
to
allow
for
rotation
right
so
like
there.
There
is
some
some
gotcha
right.
If
you
statically
specify
the
jocks
now
you're
responsible
for
manually,
doing
rotation
somehow,
which
generally
means
people
will
never
rotate
the
keys,
which
is
not
exactly
what
I
said.
B
Well,
yeah,
I
don't
know,
I
I'd
be
curious
to
hear
people's
feedback
and
then
watching
this
about.
Would
there
be
concerns
about
the
supervisor
reaching
out?
Actually,
I'm
trying
to
think
you
you
could.
You
could
still
build
this
where
the
directionality
was
only
from
the
concierge.
If
you
wanted
to
open
the
tunnel
from
the
concierge
to
the
supervisor
and
then
reverse
it
and
talk
back
through
the
tunnel,
that's
what
we
do
in
our
sas
products
today
is
that
the.
D
B
B
So
if
you
just
want
to
do
what
you've
been
doing,
you
should
be
evidenced
to
doing
that.
So
all
the
existing
or
live
maps
just
keep
working
cause,
there's
nothing
wrong
with
them.
They're
perfectly
fine
good
commands
they
work.
Well.
This
is
more
meant,
as
a
user
experience
booster
on
top
of
those
but
yeah.
I
totally
do
you
know
we
should
it's
not
it's
opt-in
not
knocked
out
or
yeah.
It's
opt-in
if
you
want
it,
but
the
stuff
that
exists
today
should
work
as
nicely
as
always.
E
I
knew
you
were
gonna
ask
that
question,
and
so
I
tried
to
come
up
with
an
answer,
but
I
really
don't
have
any
thoughts
I
mean
I
don't
have
any
knowledge
of
use
cases
that
would
help
here
and
it
seems
like
it
generally
improves
the
security
posture
and
user
experience.
So
I'm
I'm
in.
I
don't
have
any
specific
feedback,
though.
B
B
E
Yeah,
I
think
I'd
have
to
like
think
through
the
whole
user
experience
from
the
perspective
of
this
this
particular
downstream
project.
It
also
like
by
the
time
this
feature
is
shipped.
There
may
be
other
changes
in
this
particular
downstream
projects,
configuration
and
vision
so
well,
I
know
this
won't
be
the
last
conversation
that
we
have
about
this.