►
From YouTube: Pinniped Community Meeting - September 2, 2021
Description
Pinniped Community Meeting - September 2, 2021
We meet every 1st and 3rd Thursday of the month at 9am PT. We'd love for you to join us live!
This week we say farewell to one of our maintainers, Matt Moyer, v0.11.0 release, and discuss some project roadmap items. Full details here: https://hackmd.io/rd_kVJhjQfOvfAWzK8A3tQ?both#September-2-2021-Agenda
A
Hi
everyone
welcome
to
this
week's
edition
of
the
pinniped
community
meeting.
Today's
date
is
september,
2nd
2021,
by
just
a
reminder
that
these
meetings
are
being
recorded
and
will
be
uploaded
to
our
youtube
playlist,
and
we
ask
that
you
read
and
abide
by
our
code
of
contact
when
you
are
attending
these
meetings,
which
is
listed
right
here
in
the
agenda.
A
If
you're
watching
this
from
home,
we
encourage
you
to
join
us.
Live
we
meet
every
first
and
third
thursday
of
the
month
at
9am,
pacific
time.
You
can
join
our
google
group
to
get
updates
on
the
project
and
invites
to
community
meetings
and
if
you
want
to
join,
live
and
have
something
you
wish
to
discuss
with
the
team
or
are
curious
about
the
project
have
feedback
anything
like
that.
A
Additionally,
when
you're
attending
these
meetings,
we
ask
that
you
put
your
name
in
any
organization
that
you're
representing
this
is
just
a
way
to
keep
track
of
who,
from
outside,
of
the
maintainers,
are
joining
us
for
these
community
meetings.
And
if
you
are
using
pinniped,
we
want
to
know
those
details
and
the
use
cases
in
which
you're
using
this
tool.
So
please
follow
along
this
github
discussion
and
put
that
information
in
with
a
comment
here.
A
A
B
A
C
C
Got
nicer
defaults
for
active
directory
and
then
the
other
thing
is:
we've
got
a
oidc
password
grant.
So
this
is
useful.
If
you
are
someone,
who's
got
like
a
service
account
or
something
that
you
want
to
use
with.
Oidc,
it's
not
supported
by
faoidc
provider,
but
I
think,
like
it's
a
git
lab
that
does
it
and
and
a
few
others.
So
if
you,
if
you
happen
to
be
using
one
of
the
oidc
providers,
that
does
support
it,
you
can
use
this
feature
without
popping
a
browser.
D
Okay,
also
just
quick
addition
to
that.
We
also
have
we
moved
base
image.
We
used
to
use
debian,
so
now
we
have
support
for
digital
s,
which
is
more
secure
and
better
for
performance
because
it
has
smaller
image
size.
Also,
I
want
to
give
a
shout
out
to
scott
rosenberg.
He
gave
very
good
inputs
for
both
ad
and
for
the
ydc
stuff,
so.
E
D
D
We
we're
trying
to
get
validations
on
the
use
cases
so
that
we
are
sure
we
are
delivering
in
terms
of
design,
and
you
know
the
use
cases
that
the
customer
which
are
widely
used
right,
so
we
we
definitely
would
appreciate
inputs
on
the
use
cases
that
folks
are
looking
to
solve
with
multiple
idp
support,
and
that's
why
I
say
it's
in
flux
still
deciding
on
that.
This.
D
A
E
Making
it
so
that
upstream,
refresh
tokens
or
whatever
your
upstream
is
whatever
the
concept
of
the
session
is
for
that
upstream,
the
those
things
should
be
somehow
tied
with
your
downstream
session,
and
so
you
know
you
can
imagine
today,
pinniped,
as
the
concept
of
your
benefit
session
lasts
for
nine
hours,
it's
unconfigurable
in
any
way.
That's
just
what
you
get
you
can
imagine
that
that
configuration
just
or
that
that
nine
hour
number
just
kind
of
disappears
and
your
session
is
not
really
controlled
by
the
pet
at
all.
E
E
C
E
Certainly,
you
will
get
an
access,
token
has
a
lifetime,
it
doesn't
last
forever
right
and
today,
if
an
it,
admin
goes
inside
of
their
idp
configuration.
Let's
say
it's
key
cloud:
if
you're
unfamiliar
with
their
ui
every
time
you
log
into
keycode,
it
creates
a
session
object
and
the
admin
can
see
that
so
that
mo
is
logged
in
to
these
he's
logged
in
five
times
versus
sessions.
E
E
So
you
know
in
the
in
the
past,
I've
seen
this
stuff
implemented
in
really
poor
ways,
primarily
like
token
and
activity
timeouts.
So
those
obnoxious
messages
you
see
on
your
bank
website
where,
like
if
you
for
some
reason
just
go,
I
go
for
a
few
minutes.
It's
like
I'm
going
to
lock
you
out.
I
was
like
why
I'm
right
here.
Just
because
I
didn't
move
my
mouse
didn't
doesn't
mean
you
need
to
block
me
out
right,
but
the
reason
they're
doing
that
is
because
it
lets
them
cheat
this
requirement.
E
E
C
E
Sometime
the
initial
sort
of
gut
idea
that
I
had
on
this
was
we
when
we,
when
we
get
your
upstream
session
so
for
ydc.
That's
your
refresh
token
and
access
token,
and
I
guess
maybe
an
id
token.
Certainly
at
least
max's
token
for
ldap
and
then
active
directory
is
the
password.
When
we
get
this
concept
of
a
session,
we
would
create
a
one-time
use
encryption
key
right.
E
We
would
store
that
on
our
side
on
the
supervisor
as
part
of
your
login
session,
but
we
would
use
that
encryption
key
to
encrypt
the
session
and
then
hand
it
back
to
the
client,
so
we
would
shove
it
inside
the
supervisor's
refresh
token.
That's
okay
and
perfect
block
data
right.
So
what
such
a
design
lets
you
do
is
for
things
like
active
directory.
It
prevents
us
from
holding
the
user's
password
right.
The
user's
machine
always
has
access
to
their
password
because
they're
going
to
type
it
into
a
buffer
somewhere.
E
So
I
think
that
machine
having
an
encrypted
payload
that
contains
their
password
is
roughly
equivalent
to
that
machine
having
a
kerberos
ticket
for
these
situations,
which
I
think
is
perfectly
benign
and
fine,
especially
since
it'll,
be
a
one-time
use,
encryption
key
right,
like
twenty
eight,
two
six
good
whatever
like
I
think,
would
be
fine.
We
or
we
already
have
logic
to
do
this
type
of
stuff
for
the
cookie
stars
that
we
use
on
the
princess
supervisor.
So
I
think
it's
pretty
easy.
E
I
think
the
biggest
unknown
to
me
is
last
time
I
looked
at
this
google
as
an
ordc
provider,
does
not
allow
multiple
refresh
tokens
to
be
issued
for
a
of
client
and
user
combination,
but
I
don't
know
if
that's
actually
true
or
still
true,
but
there
was
two
at
one
time.
It
was
no
longer
true
I'll
stop
there.
E
E
E
So
so
that
that
is,
I
think,
an
investigation
that
needs
to
be
done.
The
where
I
learned
of
this
from
dex
and
some
various
issues
that
had
opened,
but
from
what
I
understood.
This
is
one
of
the
core
reasons.
They
never
implemented
this
functionalities
they
just
it
was
it
was
hard
to
implement
them.
They
didn't
want
to
like
break
stuff
all
over
the
place.
E
Now
you
know
nothing
says
that
we
can't
be
smart
and
like
treat
a
google-based
idp
special
right,
like
we
can
make
a
google
identity
provider,
and
we
also
we
effectively
have
to
get
groups
out
of
you
anyway,
and
inside
of
that
google
ibp.
We
could
have
special
logic
for
reusing,
refresh
tokens
or
something
right
like
like.
E
B
The
other
one
that
I
want
to
mention-
that's
weird
is,
if
we
ever
decide
to
do,
saml
idp
saml
doesn't
have
any
equivalent
thing
to
the
refresh
flow.
You
get
always
get
just
a
short
lived
claim.
Oftentimes
in
saml,
they
use
longer
longer
claims
like
they'll
be
be
one
day
long
or
something,
but
the
only
workaround
I
think
we've
talked
about
that-
would
be
kind
of
a
different
design
that
could
work
with
that.
B
So
in
a
web
application,
that's
not
a
problem
because
you're
just
interacting
with
web
application
and
whenever
you
need
to
re-authenticate
it
just
redirects
you
over
to
the
symbol,
and
then
you
get
redirected
back
and
you've
refreshed
your
session.
You
can
do
that
even
in
I
think,
even
in
samwell,
you
could
do
that
in
like
a
hidden
iframe,
you
can
even
like
make
it
invisible
for
us.
We
could
basically
act
like
a
persistent
web
application
like
that.
B
If
we
introduce
a
mode
where,
when
you
log
into
piniped,
you
don't
close
the
browser
tab,
you
leave
the
browser,
tab
open
and
it
acts
as
a
a
place
that
your
session
is
going
to
be
alive.
It's
going
to
go
re-log
you
into
saml
whenever
it
needs
to,
and
that's
going
to
provide
that
sort
of
refreshed
session
to
your
cli,
probably
by
just
re-upping
your
refresh
token,
or
something
like
that.
E
Where
so
I
haven't,
I
don't
think
I've
ever
truly
configured
like
a
real
satellite
ep
toys
with
them,
but
not
like
the
real
one.
Do
you
have
any
sense
of
how
unrealistic
it
would
be
for
us
to
ask
let's
say:
first,
we
implemented
this
refresh
token
functionality
and
later
we
had
samuel
right.
Could
we
tell
in
the
sample
docs
say:
hey
the
assertion
you
send
us?
B
I'm
not
that
familiar
with
real
sample
idps
either.
I
know
I
know
the
names
of
some.
We
can
go.
Try.
I've
used
them
a
little
bit,
but
I
don't
really
know
how
configurable
they
are
one
one
of
them.
I
know
that
support
samuel
is
adfs
and
and
azure
ad.
I
know
they
support
all
kinds
of
options.
You
can
sort
of
fully
customize
the
the
claims.
B
E
Yeah,
so
sometimes
I
I
think,
even
if
let's
say
the
assembled
idp
had
the
knobs,
I'm
not
sure
if
the
knob
is
the
same
one
to
press,
because
you
you
effectively
lose
replication
right,
because
the
assertion
is
just
a
signature,
that's
valid
until
a
certain
amount
of
time.
There's!
No.
As
far
as
I
know,
there's
no
crl.
E
You
can't
like
ask
someone
hey.
Is
this
assertion
still
valid
so
that
that
might
be
a
concern?
The
other
sort
of
open-ended
concern
is,
I
don't
think
there
exists
a
secure,
saml
library
in
there
like
there
has
been
some
work
departing
existing
ones,
but
the
sample
protocol
was
kind
of
broken
from
the
security
way
like
it's
just
not
designed
correctly.
B
We
don't
have
to
fully
like
we're
not
committed
to
building
samo.
We
don't
have
to
like
design
sample
yet
just
just
to
know
that
if
we're
designing
token
refresh
saml
doesn't
have
a
token
refresh,
and
so
we
might
have
to
have
like
a
work
around
for
that.
There
are
other
hard
things
about
xaml
like
that.
There's
no
go
library
that
does
it
and
stuff
like
that.
C
Not
on
the
same
topic,
but
maybe
on
like
ad
slash
ldap,
it
seems
like
for
ldap.
We
don't
know
what
the
claims
are.
So
like
just
logging
you
in
again
with
your
password,
makes
sense
when
we're
doing
a
refresh.
What
we
want
to
know
is
like
is
your
account
still
active.
Is
your?
Has
your
password
been
changed
all
that
stuff,
and
we
can,
I
think,
get
that
out
of
active
directory
without
binding
to
the
user.
B
But
you
also
could
like
combine
something
like
saml
or
oadc
and
combine
it
with
either
ldap
or
maybe
something
like
skim,
which
is
like
a
rest
based
directory
service
protocol
open
standard
anyway,
and
so
that
you
could
do
both
of
those
things.
And
then
we
had
other
ideas
where
you
might
want
to
have
like
a
directory
api
through
peniped.
B
C
E
I
I
think
we
would
do
that
in
addition
to
all
the
checks
that
you
just
mentioned
tomorrow,
we
would
we
would
do
our
own
internal
business
logic
to
be
like,
but
are
you
the
same
like
one
of
the
things
I'm
unsure
of
is?
Would
we
let
you
continue
to
refresh
your
token
if
your
group
membership
changes,
I
think
if
you
get
new
groups,
we
don't
care,
but
if
you
lose
groups
we
might
care
like.
That
seems
a
little
strange,
because
if
those
groups
are
attached
to
our
back,
something
has
changed
about
you
and
does.
E
E
I'd
rather
go
for
the
least
surprising
thing
possible
here,
and
a
lot
of
this
is
going
to
be
a
real
pain
with
generic
ldap.
There's
no
rules
like,
for
example,
all
dex
does
on
refresh.
Is
it
does
a
lookup
for
the
dn
and
make
sure
the
dn
hasn't
been
deleted,
which
never
happens?
You
don't
delete
the
ends
out
of
your
ldap
directory,
because
why
would
you?
Why
would
you
delete
data
out
of
your
directory
so
that
I
think,
isn't
a
meaningful
check.
E
E
E
Does
anyone
have
other
topics
there's
other
very
like?
If
folks
are
interested
in
talking
about
security
hardening?
We
don't.
We
don't
rotate
enough
keys
that
we
issue
and
we
probably
should
probably
rotate
all
the
things
like
federation
domain
secrets
and
stuff
should
be
probably
located
at
a
much
higher
cadence
than
they
are
sort
of
the
oh.
I
see
andrew
made
it.
I
checked.
No,
I
think
that
that
didn't
come
with
this
one
way
earlier,
so
we
don't
notice.
E
Sorry,
we
don't
rotate
secrets
for
your
federation
domains
that
we
should
another
very
consistent
cadence,
and
I
think
we
could,
because
we
issue
such
short-lived
credentials
like
nine
hours
right.
So
that
would
mean
that
if
you
created
a
new
key
every
day
and
kept
old
keys
around
for
slightly
longer
than
a
day,
there
would
probably
be
no
overlap.
E
E
But
if
you
had
that,
I
think
that
also
would
be
really
nice.
I
kind
of
think
there's
a
thing,
cookie
secrets
and
stuff.
I
forget
this:
there's
a
bunch
of
places
that
we
generate
either
certificates
like
private
keys
or
just
symmetric
keys,
and
basically
all
of
them
are
effectively
rotatable.
The
only
thing
that
I
can
think
of
that
we
can't
easily
rotate
is
the
root
ca
of
like
the
impersonation
proxy,
because
that
one
is
handed
out
to
clients.
B
B
You
have
some
amount
of
time
to
fetch
that
new
coop
config,
that
has
a
new
trust
route.
And
then
you
start
stop
you
stop
using
the
old
one
or
you
cross,
sign
them,
or
there
there's
complicated
things
we
could
do
there.
They
all
still
have
the
negative
property
that
if
I
have
a
config
today
at
some
point
at
some
point
it
will
stop
working.
Even
though
I
should
still
have
access
to
the
cluster,
but.
E
E
A
Well
thanks
everyone
for
joining
today's
pinniped
community
meeting
again,
if
you're
watching
this
from
home,
we
encourage
you
to
come
and
join
us
live
we
meet
every
first
and
third
thursday
of
the
month
at
9
a.m.
Pacific
time
it's
a
great
opportunity
for
you
to
just
come
and
listen.
I
don't
know
what
the
team's
working
on
anything
that
they're
they're
blocked
on.
Maybe
you
can
come
and
join
us
and
become
an
active
contributor
or
even
work
your
way
up
into
becoming
a
maintainer.
A
It's
just
a
great
way
for
you
to
get
involved
more
with
with
this
particular
project
and
provide
feedback.
If
you
have
it,
we
would
love
to
hear
from
you
if
you
aren't
able
to
join
us,
live
just
find
us
on
the
kubernetes
workspace
in
the
pinniped
channel,
and
we
can
discuss
more
with
you
there
as
well,
and
with
that,
thank
you
and
have
a
wonderful
rest
of
your
week.
Everyone
bye!
Thank
you.