►
From YouTube: Pinniped Community Meeting - May 20, 2021
Description
Pinniped Community Meeting - May 20, 2021
We meet every 1st and 3rd Thursday at 9am PT / 12pm ET. We'd love for you to join us live!
This week's discussion included updates on LDAP Support, Refresh flow issues in v0.4.x, and Impersonation proxy deployments on private EKS/AKS/GKE clusters. Additionally, discussion around device code flow vs alternatives. Full details here: https://hackmd.io/rd_kVJhjQfOvfAWzK8A3tQ?view#May-20-2021
A
A
A
If
you're
watching
from
home,
we
encourage
you
to
attend
these
meetings.
Live
we
meet
every
first
and
third
thursday
of
the
month
at
9
a.m.
Pacific
time,
if
you
want
to
engage
with
the
maintainers
in
other
ways,
we
are
on
twitter
and
we
are
also
on
the
kubernetes
slack
workspace
with
within
the
pinniped
channel.
A
A
A
B
Sure
yeah,
so
oedo
is
a
relatively
small
release,
but
has
some
good
performance
improvements
as
well
as
a
couple
of
important
bug,
fixes
no
security
bugs,
but
some
bugs
that
can
make
the
user
experience
a
lot
better
now
that
they're
fixed.
So
we
now
have
some
caching
that
we
didn't
have
before,
and
the
client
side
helps
a
lot.
B
The
impersonation
proxy
supports
more
authentication
features
of
kubernetes,
including
nested
impersonation,
so
you
can
use
impersonation
on
the
client
as
a
client,
even
when
you're
talking
through
the
proxy,
which
is
a
cool
trick,
and
one
of
the
one
of
the
bugs
I
mentioned
is
the
third
one.
There
made
a
bug
that
caused
the
refresh
flow
and
the
supervisor
to
be
broken.
So
the
the
symptom
of
this
is
that
you'd
have
to
log
in
every
20
minutes
fix
that
now
it's
nine
hours
like
it
was
supposed
to
be
so
thanks,
everybody
that
contributed.
B
C
Support
we're
making
a
lot
of
progress.
The
first
pr
is
merged.
Second,
pr
is
ready
to
be
merged.
I
imagine
I'll
probably
get
merged
today.
The
third
pr
is
in
the
works,
so
we're
getting
closer
and
closer
we're
not
quite
there
yet
not
quite
ready
to
release
the
first
release
to
include
that
yet,
but
I'm
getting.
A
D
B
B
Get
all
of
the
bug
fixes
everything
everything
all
the
new
features
coming
in
there
soon
we
did
have
users
that
were
on
the
o4
branch
and
so
and
there's
a
there's,
an
api
change
between
the
o4
branch
and
the
latest
code.
That
requires
a
a
careful
upgrade,
so
we'll
probably
backboard
that
just
so
those
users
can
get
some
of
these
quality
of
life
improvements,
even
though
they
won't
get
like
the
new
features
that
we're
building
now
and
then
the
impersonation
proxy
deployments.
B
We
did
some
research
there
discovered
that
some
of
the
defaults
that
we'd
shipped
in
0.70
and
080
weren't
ideal
for
some
users
and
so
we're
working
on
adding
configuration
options.
Now
we've
been
working
with
someone
from
the
community
who
was
having
an
issue
and
and
helping
us
design
this
new
api.
So
margaret
and
I
have
been
working
on
this
new
api,
I
expect
it
to
merge
relatively
soon
that'll
be
the
next
release
along
with
ldap,
which
I
think
is
almost
wrapping
up
as
well.
We're
making
really
good
progress
on
both
of
those.
A
B
So
we
have
an
open
issue
for
device
code
flow
support.
We
had
originally
had
this
pretty
high
in
our
road
map.
We
were
planning
to
work
on
it
immediately
following
ldap
and
then
we
backed
off
a
little
bit
because
we
didn't
have
anybody
any
real
use
cases
concrete
use
cases
to
validate
the
design,
and
we
were
you
know.
B
We
think
this
is
a
good
feature,
but
we
were
worried
that
if
we
went
out
and
just
built
it,
we
would
get
some
of
the
details
wrong
and
it
wouldn't
actually
be
useful
and
then
we'd
have
a
backwards
compatibility.
You
know
api
to
work
around
so
at
the
time
we
kind
of
set
it
aside,
and
we
put
it
back
on
the.
B
That's
changed
actually,
so
we've
gotten
feedback
from
some
users
that
they
need
to
use,
use
the
pinniped,
concierge
and
supervisor
through
an
ssh
jump
box,
a
sort
of
a
bastion
jump
box
setup
and
the
current
flow
is
awkward
in
that
scenario,
because
the
place
where
you
run
the
cli
has
to
be
sort
of
the
same
machine
where
you're
running
your
browser
and
to
get
the
localhost
part
of
the
flow
to
work.
So
device
code
flow
will
support
that
use
case,
and
now
that
we
have
some
concrete
validation
of
that.
B
This
feature
is
needed
and
we
have
somebody
that
can
help
us
validate
the
particular
design,
at
least
for
for
that
one
environment
and
we'll
try
to
generalize.
I
think
this
will
go
back
on
the
roadmap,
so
we
haven't
decided
this
officially,
but
that's
what
I'm
thinking
we'll
come
up
with?
I'm
gonna
do
some
roadmap
planning
next
week
as
well.
B
B
So
there's
a
bunch
of
complexity
that
comes
along
with
this
rfc.
That's
essentially
to
support
that
use
case
that
we
don't
have,
and
so
that's
one
of
the
reasons
we
might
avoid
it.
Another
reason
is
that,
like
the
libraries
that
we're
using
to
implement,
oauth
and
oadc
fossite
doesn't
have
any
support
for
this,
yet
so
we'd
be
building
all
of
that
from
scratch.
B
If
we
go
down
this
route
and
because
it's
a
standard-
and
it
covers
all
these
edge
cases,
all
these
sort
of
use
cases,
it
probably
wouldn't
be
a
great
idea
to
just
implement
a
tiny
part
of
the
spec.
If
we're
going
to
say
that
we
support
the
spec,
we
should
probably
like
dive
into
it
and
actually
implement
sort
of
a
good
good
amount
of
the
spec,
and
I'm
not
sure
that
we
want
to
do
that.
So
if
anybody
else
is
familiar
with,
alternatives
here
feel
free
to
jump
in
and
present.
B
C
B
Yeah
yeah
yeah
sure
sure
so
so
in
this
use.
In
this
scenario,
I'm
a
user-
I
have
piniped
installed
the
supervisor,
but
when
I
use
coop
ctl
to
access
my
clusters,
I'm
actually
running
coop
ctl
on
some
like
a
like
a
linux
vm,
maybe
somewhere,
that's
sort
of
inside
my
network.
My
corporate
network,
my
production
network
right.
B
And
then
so,
one
of
the
assumptions
that
we're
making,
which
we
weren't
sure
about
and
now
I
feel
a
little
more
comfortable
about
is
to
say,
even
though
that
connection
between
the
bastion
and
the
workload
cluster
is
maybe
inside
this
private
network
and
it's
hard
to
access
you're
still
serving
the
supervisor.
Endpoint
the
the
browser
supervisor
endpoint
on
a
place
where
your
your
laptop
browser
can
get
together.
B
So
the
fly
fly
ctl
flow
is
my
understanding.
It's
basically
very
similar
to
our
flow
by
default,
which
is
the
cli
starts.
A
local
host
port
kicks
off
an
authorization
flow
that,
at
the
end,
will
redirect
back
to
localhost
without
with
an
auth
code,
except
instead
of
redirecting
directly
back
to
that
callback.
B
The
server
recognizes
that
special
pattern,
and
instead
of
redirecting
your
browser
straight
to
the
callback,
it
redirects
you
to
a
sort
of
a
static
page
and
javascript
on
that
page,
does
a
post
to
the
local
host
endpoint.
So
the
behavior
is
basically
the
same
in
that
case,
except
the
javascript
code
also
detects
when
that
connection
fails,
and
in
that
case
it
prints
out
the
code
to
the
screen.
Just
displays
the
code
to
the
user
to
copy
paste
instead.
C
C
That
actually
depends
which
browser
some
browsers
will
just
automatically
fire
the
callback
back
to
cli,
and
it
won't
even
show
this
page.
Safari
must
have
some
kind
of
security
protection
that
prevents
it
from
doing
that.
So
instead
they
show
this
page
where
you
can
click
a
button
to
try
to
fire
the
information
back
to
the
localhost
listener
on
the
cli
or
you
can
copy
the
token
directly
and
then
use
it
directly.
B
So
the
advantage
of
this
is,
I
think
it
it
might
be
simpler
to
implement,
because
all
we're
doing
is
swapping
out
the
the
final
redirect
of
the
off-code
flow
with
a
piece
of
javascript
and
some
html.
Basically,
probably
there
are
probably
fewer
changes
to
integrate
it
into
fossil.
The
library
that
we're
using
the
downside,
I
think
is,
is
actually
a
ux
thing,
which
is
you
still
have
to
copy
and
paste
that
code
from
one
screen
to
the
other
so
like,
and
then.
B
B
I
was
also
originally
worried
about
the
security
implications
of
copying
a
secret
token,
because
then
it's
like
in
your
clipboard
and
you
might
paste
it
in
the
wrong
place,
and
you
know
that
could
be
disastrous,
but
actually
I
think
we
figured
out
that
the
the
thing
that
you're
actually
pasting
there
is
an
auth
code,
so
it's
only
good
for
one
use
and
it's
actually
bound
with
something
called
pixie
pkce,
it's
bound
to
the
client
already.
So,
basically
that
code
is
useless
to
anything
other
than
the
place
that
you're
supposed
to
paste
it
so
security
wise.
B
I
think
it's
fine
usability
wise,
I
think
maybe
device
code
flow
is
slightly
better
like
because
there's
sort
of
one
fewer
step
to
log
in
for
the
user,
but
I'm
not
sure
I'm
not
sure
we
need
to
make
a
decision
today.
I
just
wanted
to
sort
of
bring
it
up
for
discussion,
because
I
think
it's
going
to
be
pretty
soon
we're
going
to
be
ready
to
sort
of
move
these
stories
back
into
the
backlog
and
prioritize
them
and
start
working
on
them.
E
B
There's
a
another
use
case
I
didn't
mention.
This
is
one
that
we
haven't
validated
directly
yet
the
other
use
case
is
I'm
a
user
in
a
corporate
setting
where
I
can't
run,
I
can
run
that
I
can
run
like
piniped
cli
on
my
my
host
machine
because
it's
been
allow
listed,
but
when
it
tries
to
open
a
listening
port
that
gets
blocked
by
some
piece
of
like
a
corporate
host
firewall.