►
From YouTube: Istio Security Working Group meeting 2020-07-08
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
B
So
currently
the
telemetry
behavior
is
basically
your
log
everything.
There
is
no
control.
What
what
content
you
can
log
in
or
when
a
log
is
generating.
This
creates
a
lot
of
problem,
because
why
is
the
start?
Storage
cost
you
generates
too
many
logs
and
the
other
one?
Is
it's
very
hard
to
identify
the
useful
information
from
large
amount
of
logs.
B
So
the
proposal
is
to
extend
the
authorization
policy
to
provide
this
functionality.
We
propose
to
add
our
log
action,
so
current
reauthorization
policy
has
a
allow
action
in
high
action
and
we
propose
to
add
another
log.
Actually,
so
the
change
to
the
proto
is
actually
very
small
is
simply
adding
another
enum
to
the
action
field
and
it
can.
It
can
be
used
to
specify
when,
under
what
condition
a
log
should
be
created.
B
You
specify
Lego
selector,
my
API
and
the
that
the
operation
is
is
the
right
method
and
the
path
is
slash
user,
slash,
powerful
profile
and
another
example
is,
you
may
want
to
audit
or
access
for
your
API
accepts
the
cost
from
service
count
from
a
certain
service
count,
for
example,
that
service
count
may
be
a
robot
account
and
it's
generating
a
lot
of
noise.
So
you
don't
want
to
have
it
in
the
audience.
Logs
and
yeah
other
example.
You
can,
for
example,
you
can
audit
or
other
internal
user
access
to
a
mesh.
B
So
you
can
say
other
requests
from
this
is
ahmed
count.
Domain
should
be
audited
and
similar
to
authorization
policy.
You
can
also
say
blog
or
request
in
a
certain
namespace,
so
you
just
you
simply
put
a
rule
with
no
restriction,
or
you
can
say
blog
nothing.
So,
for
example,
in
my
dev
environment,
I
probably
don't
need
to
log
any
C.
So
I
just
put
an
empty
room,
empty
row,
section
us
yeah,
so
log
log
policy
is
basically
obvious.
B
Policy
is
basically
our
solution
policy
with
blog
actually,
so
it
has
all
the
same
property
as
authorization
policy.
It
can
be
defined
at
namespace,
scope
or
mesh
scope.
You
simply
put
the
namespace
to
the
loose
namespace.
Then
the
policy
applies
for
the
entire
mesh
and
all
the
policies
are
all
the
together.
So
I
requested
that
log.
If
any
policy
says
that,
and
if
there
is
a
no
policy
applied
for
a
certain
work
loader,
then
there
is
no
impact
on
the
workload.
B
B
Like
in
a
log
entry,
what
what
do
you
want
to
log?
For
example,
the
information
about
the
sauce
like
a
sauce
principal
sauce,
namespace,
sauce
service
source,
IP
or
destination
information
like
the
IP
port
service,
namespace
and
information,
about
a
request,
and
you
can
also
add
other
contacts.
For
example,
what
authorization
policy
allows
this
access.
B
Yes,
so
audit
policy
is
considered
a
security
policy
because
it's
mainly
used
for
like
a
compliance
check.
You
know
it's
a.
It
should
be
differentially
to
the
frontal
normal
debug
log.
So
that's
why
all
this
policy
actually
are
controlled
by
the
security
atomy.
So
it
belongs
to
the
security
API
and
yeah,
and-
and
it
has
so
post
namespaces
level,
security,
admin
and
measure
level
security,
enemy,
I
about
to
create
this
policy
and
because
they
are
additive,
so
there's
no
conflict.
So,
for
example,
mesh
secret
aming
can't
define
some
audit
policy.
B
B
B
B
B
D
Small
at
all,
the
that
was
not
at
all
the
conclusion.
I
got
I
think
everyone's
on
board
with
having
some
sort
of
auditing.
That's
perfectly
fine,
but
I,
don't
think
there
was
much
consensus
on
reinventing
aldi
geometry
at
the
eyes,
I
mean,
but
there's
already
an
access.
Log
format
that's
defined
in
how
much
there's
already
a
define
how
logging
happens.
There's.
D
B
Yeah
yeah,
so
if
this
requests
you
mean
so
if
this
is
a
request,
additional
feedback
from
geometry
team,
of
course,
we
are
going
to
follow
up
with
that,
can
I'm
actually
working
group,
but
the
feedback
I
got
from
the
geometry
working
group
is
there
was
thinking
this
should
be,
because
this
is
part
of
one
oscillation
policy.
So
this
is
belongs
to
a
security
domain
and
the
security
Adam
II
should
be
able
to
a
control
post
like
a
poster,
ordered
content
and
the
order
condition.
But.
B
C
D
Compared
to
I
mean
you
mentioned
before
that
in
other
products
they
have
audit
logging,
as
with
the
authorization
policy,
but
the
difference
is
that
east
EO
is
not
just
a
security
product.
It's
not
like
calico,
where
it's
just
providing
network
policies,
it
provides
network
policies
and
telemetry,
and
so
we
can't.
B
C
B
C
Cannot
implement
it
basically
because
in
envoi
we
have
because
with
mixer
it
was
possible,
you
could
have
it
with
mixer,
but
we
no
longer
have
mixer.
So
if
you
don't
have
mixer
all
the
all
the
stuff
happens
in
Android
user
space,
we
don't
have
control
over
user
space,
I
mean
they
can
completely
bypass
employees,
it
can
run
stuff
as
employee.
C
C
B
Yeah
so
so,
if
the
concern
is
to
open
up
with
telemetry
policy,
then
we
can
go
back
to
the
telemetry
team
to
to
see
what's
the
feedback,
but
I
have
talked
with
the
mentor
with
dark,
with
no
car
crowd
many
times,
and
they
were
actually
supporting
this
effort,
so
they
don't
have
a
IPC
saying
this
is
a
this
is
an
it
either,
but
I
don't
think.
There's
like
a
policy
associated
with
that.
Okay
and
the
neeraja
was
also
in
Turkey
I'm.
Sorry
working
group
meeting
right
he
was
actually
proposing.
This
should
be
the
audience.
B
D
I
heard
frontage,
amateur
working
group
I
think
it's
I
think
it's
one
thing
to
have
the
authorization
policy
have
a
single
line
that
says
log
and
use
this
format
and
point
to
some
telemetry
API
that
defines
the
logging,
maybe
I'm,
not
necessarily
convinced
that's
the
best
idea,
but
I'm,
not
the
only
opinion
that
matters
yeah,
but
completely
reinvent.
All
this
lemon
tree
stuff
is
I,
don't
think
a
good
idea
and
I
don't
think
that
had
consensus
in
the
talent,
your
group,
it's
not.
D
D
D
E
C
B
C
B
B
C
B
D
B
C
D
B
C
Purity
appear
to
configure
logging,
I
mean
if
you,
if
it's
a
feature
that
is
needed
to
have
more
flexibility
in
the
log,
it
should
be
addressed.
For
everything
I
mean
it's,
it's
not
it's.
It
will
be
strange
to
tell
user
hey
if
you
just
want
to
look
with
more
precision
user
authorization
policy,
one
yeah.
D
I
would
agree,
and
the
biggest
thing
that
makes
me
very
confident
that
this
is
the
wrong
abstraction.
Is
your
example
where
you
have
an
authorization
policy
that
applies
absolutely
no
security
rules
in
strictly
logs,
we're
that
doesn't
make
it's
like
the
last
one.
I
think
this
one
right
here.
It
says
just
log
everything
basically
and
there's
no
rules.
That
is
basically
like.
E
C
Sorry
I
think
Johnny's,
environment,
working
group
lead
and
I
think
they're
two
objections.
If
necessary,
we
can
bring
it
to
TOC.
There
is
no
point
to
debate
it
here,
I
mean
and
there
will
be
in
the
rumen
and
we
can
discuss
it,
but
I
think
from
you
know.
With
my
you
know,
working
the
networking
hat,
I
I
think
we
should,
you
know,
escalate
cookie
or
see
if
we,
if
we,
if
we
want
to
and
I
think
John
is
kind
of
saying
the
same
thing
if
I
can
put
14.
C
B
B
A
B
A
D
D
So
in
terms
of
benefits,
one
is
that
there's
lower
attack.
Surface
ingress
is
exposed
to
the
Internet.
So
if
we
have
read
access
and
someone
gains
access,
then
that's
no
good.
They
will
get
access
to
all
the
secrets,
especially
if
they
run
an
SEO
system.
Then
it's
pretty
much
game
over,
because
they'll
get
the
CIA
secret.
D
Yeah
yeah
I
would
agree,
that's
basically
the
primary
one.
The
other
ones
are
that
really
it
allows
us
more
flexibility.
There's
some
work
on
for
the
destination
real
stuff
to
add
a
free,
egress
gateway.
It's
not
really
feasible
right
now
to
do
it
for
sidecars,
because
you
can't
really
give
sidecars
access
to
secrets.
Feasibly
I
mean
when
you
sort
of
can
but
there's
a
lot
of
issues
with
that.
So
this
would
allow
us
to
potentially
add
that
on
sidecars
as
well
correct,
so.
A
C
C
And
and
I
think
the
proposal
is
to
do
it
in
stages,
starting
with
the
Gateway,
because
that's
really
is
the
most
vulnerable
and
then
we
can
discuss
after
if
it
works
and
after
we
test
it,
we
can
work
on
on
the
destination
and
the
site.
That's
because
there
are
other
security
implications
and
concern.
Sir
yeah.
D
I
think
one
other
thing
is
that
we've
talked
about
the
idea
of
reading
certificates
from
cross
namespace
I'm,
not
saying
I.
Don't
want
to
bundle
that
with
this,
because
that's
a
conch
Rishel
topic,
but
doing
this
would
make
that
much
more
feasible
because
then
we
don't
have
to
get
it
by
giving
gateway
secret
access
close
to
right
is
a
horrible
idea.
Giving
each
DoD
a
secret
close
to
right
access
may
be
a
horrible
idea,
but
it's
it's
better
than
in
aggress.
So.
D
E
D
C
C
C
As
John
said,
nice
doesn't
have
to
do
that.
I
mean
it's
it's
a
separate
discussion.
If
we
want
to
allow
gateways
to
access
secrets
stored
in
different
places
and
easier
system
and
happy
to
keep
on
each
your
system
or
same
namespaces
gateway
which
we
can
enforce,
because
we
know
is
identity
of
so
Gateway
and
then
it
will
implement
for
you
not.
C
No,
no
I'm
not
saying
that
I'm
saying
that,
if
you,
if
you
use
sqad,
is
Jodi,
will
do
will
check
that
service
account
of
the
Gateway
is
in
the
same
space
with
a
secret
which
is
trivial.
Okay,
you
want
to
store.
If
you
want
more
flexibility,
is
an
integrated
vault
or
external
storage
storages
for
secrets,
and
then
those
storages
have
their
own
permission.
Policies,
for
example,
both
has
its
own
permission
policy.
We
don't
have
to
reinvent
it.
Oh
yeah.
D
I
kind
of
probably
just
repeating
what
Constance
said,
but
I
kind
of
think,
there's
two
parts.
One
is
whether
this
is
a
something
we
want
to
do,
moving
it
into
Easter
B
and
then
the
second
is
how
or
if
we
will,
what
sort
of
API
we'll
have
to
you
know
do
the
are
back
on
what
can
access
what
secrets
for.
D
C
C
You
comment:
if
you,
if
I
may,
this
proposal
is
basically
using
the
east,
your
D
serving
infrastructure,
meaning
the
way
we
we
handle
our
snacks
and
and
and
all
the
other
stuff,
not
using
the
secret
cache
and
what
what
we
couldn't
have
in
a
yes.
That's
that's
very
important
because
we
want
to
use
the
same
code
for
ex-colleagues
they're
serving
so
we
don't
have
to
duplicate
it.
Yeah.
D
Just
building
off
that,
if
you're
concerned
about
complexity
on
Easter
D
of
serving
this
I
sure
we
could
do
a
prototype
that
wouldn't
do
it
in
like
2025
lines
of
code
or
so
because
we
already
have
code
that
serves
like
15
different
types
of
XDS
sund'ys
duty,
we're
very
good
at
that
in
pilot.
So
it
should
be
easy
at
it.
One
more
does.
D
A
Yeah
I
think
I
think
he's
using
East
you
D
to
fetch
the
certificates,
even
for
the
few
like
cross
namespace.
It
might
be
a
better
solution
to
support
because
eto
deeds
are
already
it's.
It's
a
pretty
privileged
component
in
the
system
compared
with
ingress
gateway.
We
don't
like
open
the
the
door
for
the
inquest
gateway
to
access
secrets
from
different
namespaces.
A
C
C
Or
or
or
we
can
we
can,
we
can
actually
specify
a
config
option,
so
you
can
use
different
HDS
server.
So
maybe,
if
you
were
to
implement
HDS
protocol-
or
maybe
you
know
some
other
storage-
key
storage
would
implement
CSS
protocol
and
then
you
could
just
point
these
Diaz
to
a
different
storage
and
not
go
twist
yadi,
because
that's
the
same
singly
I.
G
C
C
G
C
Have
ingress
gay
to
expose?
It
is
a
beginning
boy
and
someone
can
do
a
remote
exocrine
in
and
when
in
space
that
inner
voice.
That
means
that
that
attacker
will
be
able
to
use
ingress
gateway.
Harbored
permissions
to
read
all
the
secret
initio
system,
including
the
private
key
of
the
Citadel
CA,
actually
class.
D
C
C
G
C
G
A
I
I
C
C
C
D
D
C
D
C
F
Well,
I
guess,
first
one
to
leave
the
endpoint
like.
We
should
really
reverse
reverse.
The
order
of
these
proposal
like
bring
up
the
problem
trying
to
solve
first
and
least
the
taking
point
and
then
come
through
the
solutions
and
the
alternatives.
As
John
just
mentioned
mention
you
can
use
different
granularity
of
the
our
back.
It
can
be,
a
solution
is
already
any
of
life's
code
or
maybe
something
else
or
we
can
look
at
to
get
together
whether
the
problem
is
worth
to
solve
at
all.
Iii,
don't
know
it's
just
it's
the
other
kind.
D
Of
reverse
I'm
not
trying
to
solve
one
problem
of
six
different
problems,
love
increasing
you
know
a
different
priority
and
this
helps
in
all
directions.
So
if
we
were
only
trying
to
solve
the
lower
tax
surface,
there
may
be
better
solutions
if
we
were
only
trying
to
solve
lower
permissions,
maybe
there's
other
ones
if
we're
only
trying
to
fix
the
destination
offer
sidecars,
maybe
there's
other
ones.
But
this
solution
does
help
with
all
those
directions,
and
it
makes
the
code
much
simpler
to
and.
C
F
I
C
So
what
I
meant
is
that
the
agent
right
now
is
your
agent
is
linking
in
the
serving
code
in
in
in
pilot
initially.
So
so,
basically,
you
can
have
exactly
the
same
implementation
with
different
generators.
So
is
good.
Okay,
fair
enough
implementation
is
using
a
generator
as
a
generator
for
agent.
When
the
issue
D
is
running,
an
agent
was
running,
an
agent
will
use
the
same
code
that
is
doing
today
with
a
stable
client
and
the
existing
stuff,
but
we
no
longer
have
to
XDS
servers
initiative,
but.
D
D
C
We
have
a
singly
exist,
implementation
busy.
That's
that's
really
a
certificate
key.
So
when
you
generate
workload
certificates,
we
want
this
to
be
generated
locally,
so
it's
basically
using
an
SDS
server.
That
is
the
local
machine
with
UDS
Soviet,
but
the
implementation
of
that
can
either
be
a
completely
different
XD
s7
implementation
like
we
have
today
or
you
can
reuse
the
same
code
that
we
are
going
to
use
for.
Forgiveness.
Decrees.
C
D
A
I'm
still
thinking
about,
maybe
that's
a
little
bit
of
topic
or
too
advanced-
is
it
possible
for
us
to
separate
out
there
features
that
are
reading
their
steel
system
secrets
to
a
separate,
smaller
component
other
than
Easter
D
like
that
component
is
highly
privileged
to
be
able
to
read
their
secret
from
the
from
the
east
you'll
each
do
system
namespace,
and
we
we
have
later
like
even
maybe
introduce
better
protection
like
maybe
that
interface
can
be
used
for
vault
or
others.
That's
basically
like
key
storage
interface,
so.
C
C
I
said
earlier
that
that,
if
void
or
some
other
managed
secret
store,
or
whatever
implements
a
SDS
interface,
we
just
point
to
it,
it
doesn't
have
to
be
issued
is
just
like
with
Sierra.
If
we,
if
we
want,
which
we
have
an
external
CAS
that
is
managing
signings,
are
what
certificates
we
point
to
it
and
issued
es
bypassed
same
with
ASDs
I
mean
we
can
have
agent
point
to
either
an
external
CI
or
an
external
secret
storage.
But
if
those
are
not
available
with
all
that
least
UID,
which
is
what
we
have
today.
A
B
G
D
H
F
C
F
Not
arguing
I
think
there
is
another
problem
in
today's
model
that
if
you
deploy
gate
away
in
full
namespace
you
co,
D
doesn't
have
to
have
the
privilege
to
access
secret
info
namespace.
So
the
secrets
you
can
put
the
key
certificate
in
full
namespace
and
these
this
model.
We
are
growing
more
and
more
privileged
to
the
issue.
D,
which
becomes
like
a
friend
stand,
a
giant
security
monster
to
a
very
large,
privileged,
well
and
use
s
becomes
the
attacked
and
you
have
a
larger
impact
of
cause.
I
think
customers
own
public.
C
D
C
C
C
A
Think
I
think
the
concern
of
like
extending
the
east
of
the
privilege
rates
it's
less
of
a
concern
from
the
community,
because
ECD
can
do
a
lot
of
things
already,
but
the
real
concern
for
me
or
from
some
community.
It's
like
grunting,
too
much
privilege
for
ingress
gateway
that
are
running
not
in
Easton
Easton
names,
sto
system
namespace.
So
we
want
to
solve
that
problem.
The
the
best
approach
would
be.
You
cease
to
D
to
have
the
privilege
and
use
that
as
their
safeguard
to
get
all
the
access
to
to
date,
those
credentials
I.
B
B
C
C
Is
reducing
the
attack
interface
because
one
hope
will
involve
the
long
leaf
tokens
that
is
not
yet
resolved
by
kubernetes.
You
have
non-expiring
token
can
be
stolen
and
used
from
anywhere.
In
this
case,
the
authentication
period
is
done
with
without
certificates,
a
notification
between
security
and
the
Copernicus
niculae
server
is
using
the
East
ID
token.
So
it's
it's.
It's
actually
not
visible
to
attacker.
Sony,
ingress
gateway,
yeah.
B
A
C
D
B
D
C
Let's
because
because
implementation
question
said
they
are
relatively
small
and
we
can
even
get
it
in
one
second
I
think:
let's
try,
they
discuss
it
and
he
receives
various
objects
and
I
mean
because
it
is
Alfredo's.
There
is
one
one
side.
There
is
a
two
hopes
that
was
raised
and
the
other
one
is
that
if
ingress
is
attacked
its
it
can
escalate
to
entire.
C
D
C
I
would
say
the
most
critical
is
to
have
agent
have
an
option
to
load
SDS
from
a
different
source,
because
that
we
may
do
it
in
each
to
edgerton
a
different
component.
We
may
have
what
implement
SDS
or
other
provider,
because
SDS
is
an
API
I'm
interested
in
having
agent
have
an
option
to
run
without
dependency,
could
API
server
and
without
with
with
a
remote
STS,
and
maybe
one
8,
volt
or
other
people
implement
a
SDS,
implement
or
alternative
implementation
will
emerge
and
that
will
satisfy
all
use
cases.
Like
sir
manager
phrase
numbers
equip
limited.
C
A
That's
the
next
topic,
yeah
I,
just
refactored
can
see
my
screen
I!
Think
it's
alright.
Can
you
so
I
took
a
lot
of
feedback
from
the
community
and
you
factor
this
stock
I
think
we
have
several
ways.
We
want
to
keep
to
manage
their
integration
models.
Briefly
speaking,
they
are
this.
So
why
are
the
API
adapters?
A
A
A
A
So
why
are
the
certain
manager
is
the
third
one?
Certain
manager
can
have
two
ways
to
integrate.
I
think
one
way
is
to
integrate
with
their
East
EO
through
the
coconut
hit
CSR
a
kinetic
certificate
signing
API
the
other
way
might
be
a
new
approach
that
they
proposed,
which
is
called
a
CSI
right,
and
the
CSI
is
experimental
feature
currently.
So
what
we
currently
do
is
probably
just
integrated
with
the
cert
manager
in
through
the
community
start
sunny
API,
and
that
one
does
have
some
extra.
A
Maybe
rum,
clips
overhead
because
of
the
API
server
is.
C
A
A
Totally,
okay,
certain
manager
opens
the
door
for
integrating
with
about
last
secret
or
any
other.
It
also
has
a
self-signed
CA
support
and
also
maybe
other
cas
magnify.
So
this
is
a
also
approach
where
the
kinetic
secret
volume
amount.
It's.
What
we
already
supported
today
in
this
approach,
your
CA
will
need
to
manage
to
put
those
key
answers
into
communitites
secret,
and
then
you
need
to
mount
them
on
to
every
workload
and
think
this.
A
It's
still,
you
need
to
have
some
tooling
to
to
be
able
to
mount
them,
specify
the
volume
mount,
but
it's
already
supported.
So
basically,
the
issue
agent
can
read
from
their
local
or
mounted
file
I'll
if
it's
under
some
specific
file
path,
and
then
the
easter
agent
will
serve
the
SDS
for
that
file.
A
Of
course,
this
one
will
also
I
think
it
it
integrates
with,
is
2d
to
be
better,
because
each
Duty
can
do
their
re
job
yeah
and
you
don't
want
every
part
to
be
able
to
write
to
the
community
CSR
API.
So
those
are
their
several
ways
that
we
we
plan
to
support.
Really
a
lot
of
them
are
not
not
introducing
a
lot
of
overhead
to
e
still,
so
many
of
them
are
trivial.
Work
on
e
still
side
but
may
have
some
require
their
user.
A
The
users
to
implement
some
code,
for
example
their
adapters
or
the
integration
with
a
certain
manager
yeah
such
as
those
well
there
I
think
I
I
have
several
things
to
discuss.
Why
I
think?
Maybe
it's
their
API
server?
Overhead,
the
command
is
the
DNS
server
overhead
for
the
community,
CSR
API
I
think
someone
from
maybe
certain
manager,
cane
or
from
key
factor.
Do
you
have
any
like
expertise
like
how,
from
your
previous
experience,
how
this
kubernetes
starts
and
the
API
works?
E
Think
yeah
I
would
happen
so
yeah.
A
couple
of
people
couldn't
make
it
tonight,
but
I'm
I'm
here
I
haven't
done,
have
any
direct
experience
so
that
everything
we've
done
any
scale.
Testing
I
think
is
a
pretty
bad
a
question
to
ask,
though
we
have
like
experimentally,
integrated
with
the
CSR
API
and
we've
got
several
signers,
but
so
much
but
I
don't
think.
We've
really
pushed
it
to
the
limit.
I
think
I
think
we
already
need
to
get
to
a
stage
where
we
can
answer
that
question.
Okay.
I
was
thinking
that
these
es.
D
Are
API
they
could
be
nice.
One
insert
managers
should
have
similar
scalability
traits
right
like
for
each
one.
Worse,
we're
creating
a
CSR,
whether
it's
the
kubernetes
one
or
the
cert
manager.
One
and
then
you
know
I
guess
updated.
We've
read
it,
so
it
should
be
somewhere
reads
and
writes
for
for
both
ApS.
Is
that
accurate,
I
think
so?
Okay.
C
H
C
D
Yeah
I
agree
it's
something
to
be
aware
of,
and
we
need
to
test,
but
I,
don't
think
it
will
be
a
blocker
and
I
say
that
without
having
tested
it.
But
the
reason
is
that,
yes,
we
had
a
couple
rights
on
every
pod
coming
up
to
the
API
server,
but
there's
already
quite
a
few
rights.
There's
already
like
you
know
the
pod,
the
endpoints
everything's
changing
so
I.
C
Forget
we
can
do
it
in
each
doing
it
because
he's
doing
it
is
not
running
the
same
code,
so
we
can
start
the
process
of
provisioning
the
certificate
much
larger
than
before,
once
again,
automation,
certain
manager
and
kubernetes
es
r.
If
sub
manager
has
ability
to
sign
certificates
with
tremendous
api,
I
think
we
should
just
go
with
that.
Api
and
you
know,
support
us,
I
mean
it's
already
supported
and
make
sure
we
test
it,
and
we
we
verify
that
it
works.
Well.
It's
that
manager.
D
C
C
D
C
A
Think
we
we
can
open,
keep
all
options
open
right
like
we
have
used,
we
can
have
the
our
users
to
use
a
certain
manager,
of
course,
and
if
the
serve,
if
their
users,
they
can
just
use
their
custom
CAS
to
watch
their
communities,
CSR
API,
they
can
just
do
it.
They
can
just
do
it
without
the
cert
manager.
Right.
C
A
A
E
So
I
mean,
would
you
dictate
we'll
have
a
community
of
support
on
the
various
different
CAS
yeah?
And
today
we
haven't
yet
ported
all
of
them
from
the
existing
project.
It
was
the
V
bottom
basically
team.
Then
you
were
see
it's
our
API,
but
we
have
semi
welcome
to
the
community,
but
on
the
others,
you're
right
I
mean
people
can't
go.
Write
code
can't
go
integrate
against
the
CSR
API
themselves,
but
it
yeah.
D
C
E
C
No,
no
so,
okay,
it
seems
that
at
least
there
is
work
on
that
on
on
on
their
side,
and
if
there
is
work,
I
think
we
should
just
you
know
test
it
to
figure
out
what
branch
it
is
and
maybe
we'll
be
done
with
it
very
fast,
because
we
already
have
half
of
the
code.