►
From YouTube: Pinniped Community Meeting - July 1, 2021
Description
Pinniped Community Meeting - July 1, 2021
We meet every 1st and 3rd Thursday at 9am PT. We'd love for you to join us live!
The team went over a few items updated on our roadmap, non-interactive logins to OIDC providers via password grant, support for web app clients, and Matt Moyer did a demo of jump host login flow. Full agenda and notes here:
https://hackmd.io/rd_kVJhjQfOvfAWzK8A3tQ?view#July-1-2021
A
Hi
everyone
welcome
to
this
week's
edition
of
the
pinniped
community
meeting.
Today's
date
is
july,
1st
2021,
if
you're
tuning
in
from
home,
we
would
invite
you
to
come
and
join
this
live.
We
meet
every
first
and
third
thursday
of
the
month
at
9
a.m.
Pacific
time,
if
you
aren't
able
to
join
us-
and
you
would
like
to
interact
with
the
maintainers,
you
can
find
us
on
the
kubernetes
slack
workspace
and
the
piniped
channel
when
you
do
attend
these
meetings.
A
For
those
of
you
who
are
that
are
joining
us
today
live
if
you
have
anything
you
wish
to
bring
up
with
the
team.
Please
add
that
down
here
in
the
discussion
topics
area
also,
we
ask
that
you
add
your
name
and
any
company
or
organization
that
you're
you're,
representing
when
you're
attending
these
meetings,
so
that
we
can
keep
track
of
who's
attending
and
keep
those
lines
of
communication
open
so
that
we
can
reach
out
after
the
meeting
and
and
continue
to
support
the
community.
A
B
Yeah,
I
do
want
to
click
through
to
the
roadmap
and
maybe
refresh
because
we
did
just
update
this
yeah.
So
we
are
working
right
now
on
what
we
call
remote
oadc
login
support.
So
this
is
being
able
to
log
in
to
the
supervisor
on
machines
that
don't
have
a
web
browser
so
like
if
I'm
ssh,
to
a
jump
host,
and
I
want
to
run
coupe
ctl
there.
B
I
still
have
a
browser,
but
it's
not
on
the
same
place
anyway.
That
work
is
in
progress.
I've
been
working
on
that
this
last
couple
weeks
should
be
ready
soon,
and
the
other
feature
which
mark
has
been
working
on
is
specific
support
for
active
directory
as
an
identity
provider
in
the
in
the
supervisor.
B
So
this
is
basically
an
extension
of
our
ldap
support
with
actually
fewer
options,
because
you
sort
of
don't
need
as
many
options
to
connect
to
ldap,
because
we
can
make
a
lot
of
assumptions
about
defaults
and
then
there's
a
few
things
where
we're
going
to
actually
tweak
the
behavior
of
the
login
flow
to
be
more
sort
of
active
directory
native
small
things
like
parsing
fields.
That
we
know
are
in
a
particular
format.
B
The
other
feature
here
that
we
have
scheduled
for
sort
of
july
is
support
for
more
types
of
clusters
in
the
concierge.
So
there's
a
couple
of
gaps
right
now
that
we
know
of
like
openshift,
doesn't
work
with
the
concierge
right
now
we're
going
to
make
that
work.
There
might
be
other
things
in
this
category.
B
B
This
is
basically
support
for
having
a
supervisor
with
several
idps
configured
concurrently,
so
I
can
allow
users
to
log
into
ldap
or
active
direct
or
active
directory
or
odc
or
another
odc
provider,
and
have
all
of
those
available
and
there's
a
little
bit
of
design
left
to
do
on
this
one
about
how
the
how
this
is
exposed
to
the
user.
Like
is
it?
Is
it
only
exposed
when
you
generate
a
coup
config
or
is
it
also
exposed
to
the
end
user?
B
Some
questions
there,
but
this
is
this-
is
one
of
those
features
that
I
think
people
would
probably
expect
works
already,
and
it
doesn't
so
we're
gonna
make
it
work
with
as
few
surprises
as
possible,
the
next
one
up
there.
We
we
didn't,
have
this
filed
as
an
issue
until
this
morning,
but
it's
something
we've
talked
about
as
a
team,
a
bunch,
and
this
is
the
idea
that
when
you
take
identities
from
the
upstream
identity
provider
and
you
map
them
into
your
kubernetes
clusters,
currently
everything
is
just
one
to
one.
B
So
a
user
named
matt
in
the
upstream
becomes
a
user
named
matt
and
kubernetes,
and
your
group
named
you
know,
petapet
team
becomes
a
group
named
piniped
team
downstream.
So
this
feature
is
about
supporting
more
complex
transformations.
So
maybe
I
want
to
add
a
prefix
to
all
my
usernames
that
came
from
a
particular
idp,
and
so
I
can
say,
like
you
know,
ldap
colon
map
is
my
username
when
it
when
x,
shows
up
in
kubernetes
or
if
I
want
to
apply
other
kinds
of
filtering.
B
So
I
might
want
to
say,
like
oh,
my
my
upstream
idp
has
ten
thousand
groups,
but
I'm
not
going
to
use
all
those
groups
and
kubernetes
are
back,
so
I
only
want
to
ever
support
like
these
five
groups
that
I
know
are
relevant
to
my
policies
and
so
at
the
supervisor
level.
We'll
just
do
that
filtering
and
the
tokens
that
you
get
out
and
kubernetes
will
only
ever
have
like
a
subset
of
groups
and
then
the
same
feature.
B
We
think
if
we,
if
we
design
the
api
correctly,
it
could
also
be
useful
for
coarse-grained
authentic,
it's
coarse-grained
authorization,
so
I
could
say,
like
hey:
I've
got
this
big
corporate
directory.
I've
got.
You
know
tens
of
thousands
of
employees,
and
I
have
this
kubernetes
cluster.
That
I
know
is
for
my
team.
I
don't
ever
want
anyone
else
in
the
directory
to
be
able
to
log
into
this,
and
the
other
scenario
that's
like
that
is
even
worse.
Is
I've
got
github.com
with
you
know?
B
B
You
need
to
be
able
to
audit
your
back
policy
and
make
sure
no
nobody
else
has
user
names
up
anywhere,
so
we
could,
at
the
supervisor
level
support
a
course
grained
check
and
say,
if
you
can't,
if
you
aren't
in
a
particular
group,
you
can't
even
authenticate
you
can't
can't
even
log
into
the
cluster
anyway.
That's
that's
that
feature.
B
B
B
Google
does
work
today,
you
can
make
it
work,
but
you
won't
get
group
support,
because
google
never
puts
the
groups
in
the
id
token,
there's
no
way
to
configure
it.
You
have
to.
If
you
want
groups,
you
have
to
make
a
special
api
call.
That's
google
specific,
so
we'll
add,
like
a
google
identity
provider
that
makes
that
api
call
anyway,
if
folks
have
other
ideas
for
specific
idps
that
don't
that
aren't
supported
by
oadc
or
ldap
that
are
in
wide
use
like
file
issues.
B
I
think
that
the
the
big
one
that
we're
not
committing
to
is
saml,
where
we
probably
are
not
committing
to.
There
are
a
bunch
of
saml
identity
providers,
but
most
of
them
also
support.
Oidc
and
saml
has
a
lot
of
complexity
that
we
could
would
love
to
steer
around
anyway.
That's
it
and
then
the
rest
of
the
road
map
is
unchanged,
so
that
was
kind
of
a
long
update.
A
Thank
you
for
that
matt.
It's
very
thorough
and
I'm
sure
very
helpful
for
those
that
are
that
are
watching
from
home
to
know
what
what
the
team
is
up
to
a
couple
of
things
I
put
on
here
from
the
previous
meeting
just
to
see
if
there
was
any
updates
on
it.
We
had
talked
about
design
for
not
for
non
interactive,
ldap,
logins.
B
A
B
B
B
It
switches
our
that
makes
it
actually
pretty
minor
adjustment
to
our
login
flow,
but
supports
this
case
where
the
browser
doesn't
open
on
the
same
host
where
your
cli
is
running
and
so,
and
it
also
adds
kind
of
like
some
new
ui
elements
during
the
login
flow
that
I
think
are
slightly
nicer.
So
if
I
run
the
login
command
here,.
B
If
I,
if
I
passed
in,
skip
browser
now,
it
prints
out
the
url
and
asks
me
if
I
want
to
paste
my
authorization
code
directly
in
the
window,
and
so
if
I,
if
I
don't
do
that,
if
I
just
click
on
the
url
I
get
logged
in
and
everything
finishes
automatically,
so
that
that
part
of
the
flow
is
kind
of
the
same
as
it
was
before
this
ui
that
you
see
here
is
slightly
different.
There's
like
some
styling
and
it's
not
just
plain
text
anymore.
B
It's
also
served
on
the
supervisor.
So
you
don't
you
don't
get
redirected
to
localhost
anymore,
there's
still
like
a
network
request
that
happens
to
localhost,
but
it's
invisible
behind
the
scenes.
In
the
background
now
you
sort
of
see
like
your
supervisor
in
point
and
then.
Similarly,
if
I
do
the
same
thing
again,
but
I'm
going
to
simulate
being
on
a
jump
post
here
by
just
terminating
that,
so
it's
not
late,
it's
not
listening.
B
If
I
do
the
login
again,
it
automatically
falls
back
to
this
manual
flow,
where
I
click
the
button
to
copy.
My
auth
code
and
then
I
can
paste
that
in
and
finish
the
login
and
that
can
that
can
happen
even
if
those
two
pieces
aren't
on
the
same
machine,
so
one
of
them
could
be
like
on
an
ssh
jump
post.
The
other
one
could
be
on
my
desktop
anyway.
This
is
all
going
to
be
done
this
week.
I
really
hope
it's
got
tests
and
stuff
and
yeah.
I
just
wanted
to
show
that
off.
B
C
A
C
That
was
awesome,
that'll
be
huge
to
have
for
sure,
and
also
just
one
question
regarding
the
pinniped
username
pad
password
for
the
non-interactive
login.
We
had
talked
on
slack
this
week
about
the
I
or
last
week
or
this
week
about
the
you
know,
user
grant
or
password
grant.
Would
it
be
the
same
user
experience
when
that
gets
implemented?
If
it
does.
B
B
B
About
that
that
log
and
flow,
I
think,
we're
still
trying
to
figure
out.
So
this
is
the
this
is
the
issue
we
have.
We
have
these
two
working
theories
of
how
service
or
service
auth
can
work
with
oidc
one
is
that
you
have
user,
you
have
service
accounts
registered
as
users
and
you
use
password
grant
and
that
we
know
that's
a
valid
deployment.
B
People
have
this
there's
another
another
scenario
where
you
have
services,
service
accounts
represented
by
clients
and
they
do
client
credentials
grant,
and
usually
you
wouldn't
get
an
id
token
from
that,
but
I
think
in
some
idps
you
can
or
you
get
an
access
token
that
has
some
structure.
I
don't
know
we're
trying
to
figure
out
whether
it
makes
sense
to
support
just
one
or
support
both
of
them.
When,
like
what
it's
pretty
early
like,
I
think
we
need.
We
need
to
make
sure
that
we
understand
how
this
stuff
is
deployed
in
practice.
C
C
Yeah,
no
definitely
it's
also.
I
mean,
as
we
talked
about
on
slack,
it's
not
the
most
secure
method
as
well,
but
yeah.
No,
I
I've
seen
it
by
a
lot
of
people
with
azure
80
that
they
use
it
that
way
through
dex,
because
dex
does
support
using
the
password
grant
for
oh
idc
provider.
Well,
it
supports
it
on
anything
and
then
it
just
doesn't
work
on
ones
that
don't
support
the
possibility
and
it
falls
terribly
terribly
it
just
errors
out
and
throws
out
a
huge
huge
error
on
your
screen.
B
Another
another
feature
that
is
in
the
same
category
that
we,
I
don't
think
we
have
this
one
written
down
yet
is
the
idea
that
we
could
have
service
accounts
at
the
supervisor,
so
sort
of,
like
pinniped
native
service,
account
objects
that
represent
like
a
some
kind
of
client.
Like
a
you,
know,
ci
cd
jenkins
job
or
something
that
can
log
into
the
supervisor
with
that
identity,
and
that
could
be
like
a
token
or
something
and
get
access
to
some
subset
of
clusters.
B
That
way,
I
don't
know
it
would
be
very,
very
vague
hand
wavy,
but
so
there
are
other
systems
not
decks,
but
there
are
other
systems
that
have
this
similar
kind
of
capability
of
having,
because
kubernetes
has
service
accounts
that
exist
locally
to
each
cluster.
This
would
be
like
a
service
account
that
exists
across
the
federation
domain.
Essentially.
B
B
Yeah,
although
there's
there's,
maybe
there's
maybe
a
distinction,
we
might,
we
might
branch
off
and
have
like
one
set
of
apis
that
are
meant
for
service
to
service
off
like
this
and
then
another
set
of
apis
that
are
meant
for
local
human
user
auth,
because
they
we.
This
has
been
another
discussion
topic
that
maybe
is
good
for
the
future
is
like
how
do
does
it
make
sense
to
have
like
a
local
user
store
in
pinniped,
either
at
the
supervisor
level
or
at
the
concierge
level
locally?
B
C
Exactly
no
makes
complete
sense,
also
one
other
question
just
that.
I
know
that
there
was
an
issue
I
think,
michael
nelson,
from
the
cube
apps
team
and
filed
a
while
ago.
I
just
I've
been
using
pinniped
with
cube
apps
a
lot
and
was
wondering
if
there
was
the
idea
of.
Is
it
planned
to
be
able
to
add
clients
to
the
supervisor
to
allow
it
to
authenticate
to
applications
running
within
kubernetes
like
to
add
redirect
urls,
to
cube
apps,
for
example,
to
be
able
to
utilize
that.
B
That's
a
good
question.
We
are
also
interested
in
that
use
case.
There's
lots
of
there's
lots
of
things
adjacent
to
kubernetes
that
are
web
applications
that
you
might
want
to
authenticate
with
the
same
set
of
users
that
need
to
access
group
tcl.
So,
like
the
other
things
in
that
category,
that
we've
thought
of
are
things
like
monitoring
dashboards
like
prometheus
for
grafana,
cicd,
dashboards,
kubernetes,
kubernetes,
dashboards
things
like
that.
B
The
tricky
thing
is
just
how
to
how
to
secure
the
client
registration
appropriately
and
then
also
whether
clients
get
registered
at
the
assuming
you
have
sort
of
a
multiple
cluster
set
up.
Where
you
have
the
supervisor
installed
on
a
like
a
management
cluster,
and
then
you
have
maybe
several
workload
clusters
that
are
running
just
the
concierge.
B
B
There's
there's
just
a
bunch
of
design
questions
about
exactly
how
it
would
work,
I
think
it'll
be.
I
think
it
will
be
a
very
complex
thing
to
tackle,
but
it's
worth
it
because
it's
it's
gonna,
be
a
big
win.
So
the
answer
to
your
question,
I
think,
is
yes.
I
think
we
think
this
is
in
scope
for
benaped,
but
we're
really
not
sure
how
it's
going
to
work
yet.
C
Okay
makes
sense,
yeah,
no,
I'm
looking
at
it,
also
from
also
from
that
idea
of
the
management
cluster
with
workload
clusters
for
log
into
multiple
clusters
for
multi-cluster
solutions,
whether
that
would
be
something
like
grafana
or
things
like
cube,
apps
or
whatnot,
which
can
target
multi-clusters,
which
then
becomes
nice,
but
definitely
not
an
easy
one
to
tackle.
So.
B
B
C
C
B
One
goal
for
this
is
that
it
should
be
really
easy
to
set
up
applications
that
share
the
same
authentication
as
your
cluster
that
they're
running
on
so
like
as
much
as
we
can
automate
it.
We.
Another
thing
I
think
we
considered
is
integrating
with
something
like
contour,
so
to
have
a
authentication
gateway,
basically
integrated.
So
all
I
have
to
do
if
I
want
like
penpad
auth
in
front
of
my
web.
Dashboard
is
add
an
annotation
to
my
ingress
and
say
I
want.
C
B
About
all
of
this
is
that
you've
got
like
you've
got
to
generate
your
client
secret,
but
to
generate
your
clients
secret
oftentimes,
you
need
to
know
the
redirect
uri,
which
means
you
need
to
have
the
app
deployed,
and
then
you
have
to
take
this
client
secret
and
wire
it
back
into
the
app
config.
It's
just
it's
just.
A
C
A
Waves
going
once
right:
okay,
well
thanks
everyone
for
this
lovely
short
and
sweet
pinniped
community
meeting.
Thank
you,
scott
for
the
discussion
topics
helpful
as
always
really
appreciate
your
input
there.
If
you're,
you
know
tuning
in
from
home
again
we
invite
you
to
join
us.
Live
we
meet
every
first
and
third
thursday
of
the
month
at
9,
00
a.m,
pacific
time-
and
we
also
can
be
found
on
the
kubernetes
slack
workspace
in
the
pinniped
channel.