►
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).
A
A
I
would
like
us
to
just
think
about
perhaps
there's
two
definitions
of
private
there's
or
visibility
in
that
there's
something
that's
private,
like
a
cass
agent
running
on
a
project,
that's
private
that
private
in
the
sense
the
internet
or
other
people
outside
my
group
cannot
see,
but
I
can
see
and
then
there's
the
completely
separate
use
case
of
it
is
a
private
project
that
I
can't
even
see.
I
don't
I
don't
have
any
visibility
into
that
and
I
think
they're
distinct
for
two
different
reasons.
One.
A
A
We
should
try
and
enable
that
to
be
as
seamless
as
possible,
but
if
there's
a
project
or
a
cass
agent,
that's
in
a
project
I
cannot
see
at
all
is
hey.
How
do
we
handle
that?
You
know
we
can
certainly
request
access
into
that,
but
also
the
be
the
discoverability
part.
How
is
I,
as
a
user,
who
can't
even
see
into
a
repo
know
that
cas
agent
exists
and
if
we
have
to
be
careful,
because,
if
we're
like
allowing
people
to
request
access
into
cash
agents,
they
in
private
repos?
A
Is
that
leaking
some
kind
of
information
because
they
can
go
like
I'm
going
to
try
and
request
access?
And
you
know
that's
kind
of
a
way
of
people
to
try
and
figure
out
who's
got
cash
agents.
Does
that
kind
of
that's
another
consideration?
If
a
repo
is
private
and
you,
as
a
user,
can't
see
it
in
theory?
You
cannot
know
anything
about
that
project
for
real
kind
of
security,
even
though
it
might
be
just
a
private
in
your
company
or
whatever.
A
A
If
you
want
to
request
access
to
it,
that
that
might
be
okay
to
start
with,
there
might
be
other
people
who
who
want
more
permissions,
that
maybe
we
can
say
you
can
access
into
a
private
project
even
a
request,
but
only
if
you're
in
the
same
group
or
something.
So.
I
can't
just
request
access
into
random
repos
across
gitlab,
trying
to
see
if
anyone's
going
to
click
the
button
kind
of
thing.
C
A
I
don't
think
there
will
be
any
passwords
or
secrets
in
what
we
the
configuration
repo
for
cass
right
now,
but
what
if
we
want
to
have
cass
to
start
to
do
bigger,
integrations
or
you
know,
starting
to
talk
to
other
issue
tracking-
I
I
don't
know,
but
we
must
always
be
careful
of.
I
think
at
the
moment
a
cast
configuration
repo,
there's
nothing
in
there.
A
B
D
D
So,
for
example,
if
our
conflict
class
conflict
project
exists
in
a
group,
that's
top
secret
top
secret
group,
and
then
this
cast
group
requests
permissions
from
normal
group,
slash
project
so
completely
different
group.
So
now
because
we
have
to
show
like
some
level
of
where
this
agent
is
coming
from,
so
we
have
to
kind
of
show
the
full
path
right
of
say:
top
secret
project,
slash
cats,
project,
slash
agent.
So
now
the
developers
or
the
maintainers
of
normal
group
can
now
see
like
this.
Top
secret
group
exists
now.
D
So
it's
an
information
link
right
in
a
sense,
it's
very
it's
a
very
kind
of
like
guild
problem
to
have.
I
don't
know
whether
we've
given
out
about
it.
I
think
we
haven't
that
it's
very
very
hard
for
me,
because
every
we
have
all
these
vulnerabilities
coming
and
we
always
try
to
fix
it
as
well,
because
when
someone
goes
to
gitlab.com
popsicle
group,
if
you
don't
have
access
to
it,
it
should
just
make
them
fall
for
existing
has
never
existed.
D
D
A
So
there's
one
way
to
look
at
it
would
be
if
it's
a
private
group,
maybe
it's
like
if
everything
is
public.
So
if
everything
is
public,
you
know
there's
a
it
would
be
easy,
for.
You
know,
requests
to
come
either
way
and
people
as
long
as
there's
a
request
and
people.
The
other
side
accepts
that
the
public
is
very
easy.
A
Maybe
I
think
what
we're
going
to
have
to
look
at
is
probably
just
we
have
to
kind
of
pick
some
hard
rules,
even
if
they're
not
the
best
and
just
kind
of
say
these
are
the
rules,
so
it
could
be
like
if
your
cast
manifest
project
is
private.
No
one's
allowed
to
request
into
it.
You
have
to
give
permissions
out
you,
as
the
private
owner
have
to
say.
I
guess
this
group
can
do
this.
Yes,
this
can
do
that
and
as
a
developer,
that's
that's
not
correct.
A
That's
not
the
best,
because
you're
gonna
you've
got
to
go
and
hassle
someone
in
the
private
group
to
give
you
permission,
but
at
least
it's
secure.
So
I
think
we're
going
to
be
that
constant
trade-off
of.
Are
we
going
to
make
things
a
little
bit
worse
for
private
groups,
but
probably
more
secure,
because
I
can't
see
a
model
where,
as
a
developer,
I
would
like
to
request
into
a
private
group
that
is
going
to
be
100
safe,
so
maybe
for
private
groups
for
at
least
a
private
cast
agent.
A
We
may
just
have
to
say:
if
you're
going
to
make
the
cass
agent
private,
which
is
fine,
then
you
are
going
to
have
to
explicitly
tell
the
people
who
to
give
access
to
which
is
probably
not
bad,
because
maybe
that's
how
private
groups
in
get
lab
work
anyway.
If
you
want
someone
to,
you
know
see
into
your
private
group,
you
kind
of
got
to
give
them
the
permission
to
so.
Maybe
that's
okay
for
us
to
tell
people
to
do
that
yeah.
C
A
Next,
on
the
other
side,
so
let's
say
I'm
running
a
cass
agent,
but
I
have
a
development
group
that
I
don't
see,
that
is
private,
and
that
does
happen
because
some
companies
have
special
teams
that,
like
this
is
top
secret,
maybe
they're
doing
a
hr
system,
some
data
that
you
know
they
don't
want
everyone
to
see.
So
you
know,
I
think,
that's
okay,
like
if
they're
like
I
I've,
got
this
private
project.
I
don't
see,
but
I
wanted
to
use
my
cass
agent.
I
think
that's
probably.
Okay.
A
Obviously,
there's
proviso
that,
if
they're
requesting
that
cass
agent
and
I'm
running
that
cass
agent
in
theory
in
a
very
kind
of
black
hat
kind
of
way,
I
could
manipulate
the
cass
agent,
which
pulls
down
the
code
to
actually
get
access
to
that
code.
So
we
can't
guarantee
it
as
a
truly
secure
model,
but
typically
in
that
way,
the
operators
running
cass
are
most
likely
have
root
commissions
on
the
on
on
the
infrastructure
anyway,
so
they're
already
some
trusted
at
some
level.
A
So
I
think,
with
a
private
project
coming
out
into
like
a
less
privileged
cast,
that's
probably
easier,
because
we
can
just
say
well.
The
person
running
that
cast
has
some
level
of
trust
anyway,
but
it's
really
when
you've
got
that
private
cast
and
then
there's
potentially
all
these
other
projects
outside
that
level
of
trust
that
are
trying
to
get
into
it.
C
Okay,
so
we
are
discussing
well
a
flow
outside
of
gitlab,
so
somebody
actively
going
to
the
task
maintainer
and
asking
for
access
or
asking
them
to
add
their
project
to
the
managed
projects.
If
that
makes
sense,
so
maybe
I
can
come
to
graham
graham
is
a
maintainer
of
the
cars
and
I
can
say:
hey.
I
have
this
hello
world
project.
Please
add
it
to
the
agent
and
then,
if
my
project
is
private,
then
a
push
notification
will
come
so
that
I
give
the
agent
access
to
my
project.
C
A
A
C
B
A
That
they
can't
see
the
offline
part
while
bad
at
least
it's
you
know
for
you
to
come
to
me
and
say
hey.
I
want
access
to
your
private
cass.
I
must
have
told
you
what
I
must
have
told
you
hey.
You
know
come
to
me.
You
know
there's
some
level.
I've
trust
I've
already
established
outside
of
gitlab
to
communicate.
To
that
view,
and
if
I
haven't
said
anything
to
you,
you'd
never
know
it
exists.
A
You'd
never
ask
me,
so
I
guess
that's
that
kind
of
that
yeah
offline,
well
offline,
probably
all
online
anyway
or
email,
or
what
or
documentation
or
some
other
outside
specifically
gitlab
method
of
communication,
and
obviously
I
would
love
to
bring
that
into
gitlab
as
well.
I
just
we
just
have
to
be
careful.
How
we
do
that.
C
B
D
A
C
C
A
A
Yeah,
no,
I
see
so,
do
you
add
projects
to
the
agent
or
do
you
add
agents
to
the
project?
That
is
a
very
interesting
question.
So
this
it's
a
tricky
one
because
definitely,
as
an
operator
who's
like
so
I'm
going
to
run
a
cast,
that's
connecting
to
my
production
cluster
or
whatever.
It
is
good
for
me
to
see
it
all
at
a
glance.
A
I
think
the
pro
I
think,
there's
a
it's
a
really
interesting
problem,
because
I
always
think
of
cass
agents.
You
know
as
my
domain.
This
is
what
I
think
about,
whereas
a
developer
is
always
just
thinking
about
their
project,
they
don't
care
about
anyone
else's
project.
So
I'm
trying
to
provide
an
answer,
but
I
really
kind
of
don't
have
one,
because
you've
got
two
people
looking
at
things
from
two
different
perspectives.
A
B
C
A
So
if
a
project
request
comes
to
me
that
says
I
as
a
this
project
would
like
access
to
your
cast
agent,
that
I
would
expect
to
go
to
the
cast
agent
screen
and
approve
that
if,
if
it
was
a
if
it
was
a
way,
if,
if
I
had
preemptively
added
a
project,
so
if
I
as
the
operator
and
said
I'm
going
to
go
and
add
this
project
than
this
project,
I
would
probably
expect
the
project
owners
to
get
notified
and
said
hey.
This
person
has
granted
you
access
to
the
cass
agent.
A
C
A
C
A
A
A
B
A
A
B
B
C
C
D
D
We
don't
know
khan,
it
just
thinks
it.
I
mean
cass
cass
knows
about
it,
like
the
the
the
actual
thinker
knows
about
it,
but
on
the
get
lab
side
we
don't
know
about
it.
So
that's
a
very
good
question
because
say,
for
example,
we
play
we
want
to
show
the
status
right.
Let's
say
like
here's,
a
manufacture,
yeah,
did
it
actually
sync
or
is
it
in
the
processor
or
syncing?
Or
did
it
error
all
right
so.
D
A
Weird
well
do
we
have
to
just
be
like
we
just
stick
to
the
gitlab
visibility
model
and,
if
you're
a
private
project,
you
have
to
deploy
your
own
caps.
Like
you
know
they
we
we
design
cast,
so
you
could
run
multiple
copies
of
cast
in
one
cluster.
Do
we
just
say
okay,
if
you're
going
to
do
you
know
if
there's
something
that's
across
the
security
boundary
you're
just
going
to
have
to
deploy
another
cast
and
we're
just
going
to
keep
things
simple
and
keep
every
cast
within
its
own
security
boundary
like.
A
It
may
be
trickier
because,
obviously,
like
you
might
have
the
one
cluster
that's
running
like
three
or
four
casts,
but
maybe
that's
not
a
bad
thing.
Maybe
that
keeps
everyone,
especially
if
those
cass
agents
aren't
running
with
full
admin,
privileges
which
I
assume
they
probably
wouldn't.
In
this
case,
maybe
that's
another
way
is
just
we're
going
to
stick
to
a
very
get
lab
permissions
model
and
if
you
try
and
do
anything
across
that,
unfortunately,
you're
just
going
to
have
to
deploy
an
extra
pass.
A
Is
if
you
have
a
you
know,
you've
got
a
company
and
they've
got
you
know,
one
kubernetes
cluster
won't
have
you,
they
deploy
one
cass
and
it's
got
certain
visibility
levels
and
then
we're
talking
you
know
because
we're
talking
about
like
there
might
be
private
projects
or
maybe
the
cass
agent
is
private.
So
we're
talking
about
that
cross
security,
boundary,
and
so
maybe
I'm
saying
another
solution
to
this
whole
problem
is
to
not
make
it
a
problem
and
say
we
cannot
do
cast
agents
across
security
boundaries.
A
If
you
have
one
group
project,
whatever
that's
a
higher
security
than
the
lower
one,
you
have
to
deploy
an
entirely
other
cass
agent
with
a
higher
security
level.
You
know
into
that
security
level
into
that
manifest
project.
In
that
private
group,
like
we
basically
say
we
will
never
cross
security
boundaries
at
all
and
then
all
of
our
problems
are
solved
because
we
can
the
visibility
of
what
we
want
to
do
in
the
workflow
is
just
simple.
A
I
see
the
downside
to
that.
Is
you
know
people
having
deployed
more
cass
agents,
but
maybe
that's
not
a
bad
thing.
Maybe
it
just
makes
everyone
simpler
sinking
status
is
simpler
because
we
just
draw
the
lines
and
say
there
is
never
any
situation
where
a
cass
agent
is
crossing
any
kind
of
security
boundary.
C
A
You
want
your
toolbox,
you
want
to
deploy
your
code,
you
want
to
get
it
into
the
kubernetes
cluster
or
wherever
it's
going.
You
want
it
to
do
that.
Obviously,
if
someone
set
up
a
cass
edge
and
it's
nice
just
like
click
a
button,
then
it
all
happens
magically
that's
very
nice,
but
the
reality
is.
You
know
that
you
know
security
is
there,
you
know
it's
true.
These
problems
are
tricky.
A
Maybe
if
you're
a
if
you're
a
group
within
a
company
that,
like
we're
doing
extra,
secure,
work,
we're
doing
high
security
work,
maybe
it's
not
unreasonable
to
say
well,
then
you
also
need
to
spend
a
little
bit
of
extra
effort
and
deploy
your
own
high
security
cash.
I
I
would
probably
do
that
anyway.
To
be
honest,
I
to
me
I
would
happily
deploy
two
cass
agents,
one
for
my
team.
That's
high
security
and
one
for
low
security.
A
Just
so
I
can
mentally
keep
things
a
little
bit
separate
anyway,
and
also
you
know
just
just
so
I'm
I'm
ensuring
that
I
know
the
permissions
and
who's
deploying
what
and
there's
less
chance
of
any
kind
of
security
issue.
So
maybe
that
is
just
the
other
way
we
look
at
this.
Is
we
we
don't
shy
away
from
saying,
deploying
multiple
percentages?
If
you
need
it,
you
know
we
don't
have
to
have
the
one.
C
D
I
think
victor
victor
is
already
planning
to
split
the
issue
into
two
and
then
we
will
solve
this
like.
Currently,
we
will
just
solve
this
to
private
projects,
because
right
now,
public
project
has
no
problem
and
then
there
is
another
issue.
That's
coming
up.
That's
this
is
cross
group
stuff
right,
but
I
think
it's
it's
worthwhile
thinking
about
these
heart
rules
in
the
beginning,
so
that
sort
of
whether
I
had
to
change
tag
immediately.
I
think
that's
definitely
a
worthwhile
consideration
like
having
having
this
hard
boundaries
because
there's
still
ways
around
it
like
like.
D
If
I'm
motivated
enough,
I
can
just
say
here's
a
manifest
project.
I
shall
do
a
mirror
to
another,
manifest
project
that
crosses
the
group
boundary
and
it
causes
the
engine
in
the
same
same
group
as
the
cast
project
in
the
southerly
armor
permissions
to
set
up
right
so
that
that
also
simplifies
a
few
things
then,
because,
if
we
assume
I
could
hide
within
a
group
thing,
then
suddenly
we
can
say
the
manifest
project
can
just
choose
from
a
list
of
agents
from
a
group
always.
C
A
I
think
for
a
big
company,
so
a
big
company,
probably
a
lot
of
projects,
probably
more
likely
to
have
more
complicated
security
problems,
probably
got
a
bigger
infrastructure,
bigger
cluster
big.
And
what
have
you?
I
think,
the
idea
of
just
hard
hard
model,
one
agent
for
the
security
one
agent
for
the
other
is
not
a
big
deal.
They
already
have
to
manage
a
lot,
so
you
know
it's
a
very
little.
Adding
one
extra
repo
or
one
extra
step
to
them
is
is
not
as
big
of
a
deal.
Their
clusters
are
probably
so
big.
A
Adding
more
cass
agents
is
not
a
big
deal
and
once
again
in
terms
of
resources
for
the
smaller
groups,
you
know,
maybe
it
is
a
little
bit
of
extra
complication
for
them.
But
it's
a
real
question
of
how
many
smaller
groups
smaller
companies
do.
We
have
where
they've
got
a
very
complicated
security
model.
I
don't
know
if
there's
a
way
for
us
to
determine
that,
but.
A
D
D
D
Maybe
I
either
infrastructure
team,
don't
like
exposing
my
infrastructure
to
the
rest
of
my
company
or
my
group,
who
knows
it's
the
same
principle
right
now,
like
our
kubernetes
clusters
are
not
exposed
to
developers
right
so
like
I
feel,
like
kind
of
hesitant
to
expose
the
list
of
agents.
To
my
whole
group
say
in
the
case
of
gitlab,
for
example,
that
will
mean
that
you
know
I
would
be
exposing
all
my
agents
to.
D
Well,
it's
just
information
right,
so
information
is,
is
it's
another
line
of
defense
and
also,
if
you
had
a
list
of
information
that
information
might
leak
a
lot
of
issues
like
if
we,
if
I
name
my
agent
like
you,
know
something
bad
agent.com,
it
links
the
to
the
whole
group.
Someone
within
the
group
links
it
out
to
the
press.
I
don't
know
like
that
kind.
C
B
C
A
C
D
C
D
D
C
D
A
D
C
D
D
D
D
E
C
D
D
C
D
D
C
D
C
D
C
D
C
But
if
you
want
to
see
the
products
of
all
the
projects
for
you
of
your
agent,
then
you
would
have
to
navigate
to
each
manifest
project
right
to
see
the
status
or
is
a
use
case
in
my
project,
and
I
only
care
about
this
project
at
this
moment
and
not
about
the
rest
of
the
project.
Yes,
okay,
that's
the
assumption
that
we're
looking
at
one.