►
Description
2023-03-22
[BR] Should a k8s admin be able to interact with the Korifi API or not?
Treat the cf namespace bindings as the CF “users” table and reject API requests if you don’t have a CF rolebinding.
Fill out the /v3/users endpoints in future stories..
[GC] v0.7 soon!
Ram: A blog post would be nice.
KubeCon material is done and submitted.
Publishing end of week around 3/31.
{RI} Presenting Korifi at the virtual summit which is a run up to SpringOne on Apr 4th
Feel free to post good talking points in Slack, any input is welcome.
B
B
B
All
righty
we're
five
minutes
in.
Let's
go
ahead
and
get
started
this
first
one
is
from
Bird
Rock
he's
not
here,
but
you
know
the
conversation.
Probably
anyhow
should
a
Kate's
admin
be
able
to
interact
with
the
creepy
API
or
not.
Question
mark
I.
Think
at
this
point
you
can't
right
unless
you
get
the,
unless
you
get
a
particular
role
associated
with
you,
do
we
feel
that
for
the
right
Behavior.
A
D
A
We've
we
had
a
warning
introduced
exactly
for
this.
It's
like
you're
trying
to
use
corifi
with
an
encore.
If
you
use
where
things
might
happen,
and
they
usually
do
yeah.
So
we
might,
he
I
think
he
had
proposed
a
solution
that
was
very
specific
around
this
create
org
use
case.
What
I
proposed
instead
was?
Why
don't
we
like?
If
we
don't
want
these
people
to
use
the
API
just
block
them?
We
know
we
already
know
how
to
detect
them.
A
These
are
the
cfus
and
you
can
delete
stuff
from
that
table,
for
example,
and
users
will
be
added
back
if
you
rebound
them
Etc,
so
our
equivalent
is
the
bindings
we
have
in
the
root
name
space
so
like
when
you,
when
you
create
a
role
in
Korea,
automatically,
creates
a
binding
in
the
root
name
space
which
is
needed
for
listing
ores,
I
think
for
domains
as
well.
I
think
for
a
few
things.
A
So
my
idea
was:
we
could
just
do
a
one-to-one
mapping
from
conceptual
CF
users
to
these
roles
and
implement
the
slash
V3
users
endpoints,
based
on
those
role
bindings,
and
then
people
will
be
able
to
delete
those
because
another
concern
was
they
leak
like
you,
you
keep
create
you
create
bindings
in
corifi
and
we
are
those
all
these
bindings
to
the
root
namespace.
Then
you
delete
the
bindings
you've
created,
but
the
binding
in
the
root
namespace
never
goes
away
because
there's
no
reliable
way
of
deleting
those,
so
we
kind
of
keep
accumulating
them.
A
But
if
we,
this
is
exactly
what
CF
does
with
its
users.
If
you
don't
want
them
anymore,
you
have
to
explicitly
delete
them.
So
it's
it's!
A
nice
I
think
coincidence
that,
like
we
pre
without
really
doing
it
on
purpose,
we
end
up
behaving
pretty
much
exactly
like
CF.
We
just
need
to
introduce
those
endpoints
and
like
we
could
once
we
decide.
Okay,
that
list
of
bindings
in
the
root
name
space
is
basically
our
users
table.
A
B
A
A
D
A
D
Doing
extra
filtering,
yeah
and
I
think
that
makes
sense.
You
know
protecting
the
API
and
saying,
if
you
want
to
use
the
API,
you've
got
to
be
a
you've,
got
to
have
a
Carefree
role,
because
otherwise
the
creepy
rolls
don't
work.
You
know
that
that
makes
sense.
If
they
want
to
hit
the
cluster,
then
and
they're
a
cluster
admin
gone
fine.
D
You
know
we're
going
to
document
simple
cases
like
declaratively,
creating
oils
and
spaces
and
role
bindings,
because
that's
part
of
the
platform
management
side
of
things
I,
don't
know
that
we're
going
to
go
into
more
detail
of
how
to
push
an
app
effectively
by
creating
your
own
see,
you
know,
custom
resources,
but
I,
don't
think
many
people
are
going
to
try
and
do
that
anyway.
So
I
think
that's
fine,
yeah.
A
A
403
is
forbidden
four
to
three
or
whatever
is
more
appropriate
error
and
just
say
sorry,
you
you're
not
allowed
in
and
maybe
add
something
somewhere
to
either
the
truck
some
troubleshooting
dock
or
something
to
say.
If
you,
if
you
get
this
error,
then
make
sure
you
add
a
user
to
Korea
make
sure
that
when
you
use
the
user,
you
specified
when
you
installed,
corifi
and
or
a
user
that
you've
previously
bound
to
some
role
in
corifi.
D
We
are
I,
think
the
code
lists
all
of
the
role
bindings
and
then
filter
Down
based
on
the
propagation,
the
creepy
propagation
label,
so
the
either
has
to
have
propagation
to
a
propagation
file
Summit
for
it
to
be
considered
a
peripheral
binding
and
as
it
matches
the
subject
to
the
to
the
user
and
if
it
finds
an
entry
that
matches
all
of
that
then
they're
a
cfuser.
At
that
point,
yeah.
A
Yeah
unless
something
goes
wrong,
but
then
you
have
issues
down
the
line.
If
that
happens,
then
you
should
everyone
should
have
a
binding
there.
So
we
should
just
check
that
and
you
treat
that
as
our
user
base,
basically
as
a
user's
table,
so
we
could
do
that.
As
part
of
this,
we
could
just
simplify
that
middleware.
Just
look
at
the
root
binding.
Instead
of
trying
to
be
fancy.
A
And
then
we
can
have
stories
about
implementing
the
user's
endpoints.
It's
not
like
that
very
I
think
the
only
thing
that
they
would,
they
would
add,
is
maybe
being
able
to
list
so
I
have
an
idea
of
all
the
users
in
your
that
are
less
like
recognized
by
corifi
and
then
deleting
so
again
like.
If
you
want
someone
to
be
out
of
the
system
you,
even
if
you
unbind
them
from
everything,
they
still
keep
this
binding,
which
has
some
permissions
like
listing
orgs
and
stuff.
A
D
A
Yeah,
so
we're
planning
to
release
zero
seven
soon,
so
either
this
week
or
beginning
next
week
tops
the
GC
works
or
the
the
cleanup
work
about
deleting
leftovers
is
done.
The
labels
annotations
work
has
been
wrapped
up,
there's
something
some
logs
work
that
has
been
done
to
improve
logs
and
I.
Think
the
work
about
supporting
service
accounts,
as
could
you
users,
is
basically
is
already
landed
in
Maine
and
potentially
we
could
get
other
stuff
as
well
about
declarative
management
like
of
spaces
and
orgs
Etc.
A
C
B
C
Something
regular
too,
if
that's
possible,
that
being
said,
I
imagine
this
will
be
like
our
big
release
before
kubecon.
So
there's
going
to
be,
like
a
push,
add
cubecon.
That
basically
says
we
are
at.
You
know
v0.7,
and
you
know.
Historically,
these
are
the
things
that
we've
tried
and
we've
iterated
on
and
changed,
and-
and
this
is
where
we
are
at
right
now-
and
this
is
where
we
intend
to
go
yeah
so
yeah
blog
post
would
definitely
be
nice.
A
C
So
that
hasn't
been
sent
for
publishing
yet
but
I
was
able
to
incorporate
all
of
the
inputs
that
you
had
yeah.
So
you
had
written
like
a
shorter
summary
of
you
know
what
what
it
should
be
and
what
the
goals
are,
and
things
like
that
so
yeah,
that's
the
version
that
we
are
going
to
go
with,
but
we
it's
not
out
for
publishing.
Yet
it'll
probably
go
out
at
the
end
of
next
week,
yeah
week
of
the
31st.
C
Talk
is
scheduled
for
the
4th
of
April,
so
I'm
going
to
be
making
use
of
the
stuff
that
we
have
in
terms
of
just
demonstrate,
like
a
local,
install
and
then
show
that
the
same
thing
works
on
like
a
remote
instance
and
I'll
be
using
that
the
one
that
we
use
for
acceptance,
tests,
I'll
reserve
some
time
closer
to
the
date
and
let
everybody
know
but
yeah.
That's
that's.