►
From YouTube: RBAC In Spinnaker - Groups, Application vs. Account Permissions and How to Use Them - Jason McIntosh
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
RBAC In Spinnaker - Groups, Application vs. Account Permissions and How to Use Them. - Jason McIntosh, Armory, Inc.
Plan to do a walk through with: * enabling group integration using as an EXAMPLE an Okta dev Account & configuring spinnaker using SAML * setting access controls on accounts including how accounts interface with clouds (k8s as an example) * setting access controls on application * Limitations on these configurations * Setting up application restrictions * Using Manual Judgements to elevate permissions * Discuss X509 on top of the above & show the configuration * Go through Fiat, how it operates, show the permissions cache, sync operation impact, and integrates with the above
A
Let's
go
ahead
and
get
started,
plugging
that
R
back
role-based
access
controls
for
anybody
who
likes
acronyms
I,
don't
particularly
like
acronyms,
but
that's
a
very
common
one
in
this
space.
So
let's
talk
about
our
back
account
versus
application
permissions
because
they
are
two
very
distinct
things
in
Spinnaker
land.
Before
we
start,
let's
talk
about
authentication
authorization,
because
you
can't
have
our
back
without
authentication
authorization
services.
A
Spinnaker
is
an
open
source
platform.
It's
built
off
of
Spring
Security
for
most
of
its
authentication,
libraries,
which
means
we
support
most
of
the
standard
authentication
mechanisms,
your
oauth
2,
saml,
ldap,
even
a
basic
form.
We
also
do
x509
authentication,
which
I
can
get
into
a
little
more
details.
We
do
separate
out
authentication
and
authorization
authentication
is
handled
at
gate.
Gate
is
the
entry
point,
two
Spinnaker
for
authentication
purposes.
A
It
terminates
off
at
that
layer
and
then
uses
internal
headers
to
track
your
authentication
information
to
the
various
services,
so
part
of
your
login
will
land
on
gate
gate
will
then
make
requests
internally
passing
an
X
Spinnaker,
Dash
user,
X
Spinnaker,
you
know
groups
or
not
groups
roles.
There's
various
headers
that'll
actually
include
on
follow-on
requests,
but
authorization
I.E
hey.
What
are
you
allowed
to?
Access
is
handled
industry
or
independently
of
gate.
It's
handled
at
a
service
called
Fiat.
A
A
All
of
that,
though,
gets
passed
over
to
Fiat
Fiat
syncs
the
information
and
generates
essentially
cache
of
authentication
information,
that's
accessible
to
the
various
Services.
Now
a
couple
cautions
as
they
rule
individual
user
information
doesn't
mean
anything
to
Spinnaker.
It
doesn't
care
that
I
am
Jason
McIntosh
at
someplace.com.
What
it
cares
about
is
Jason
McIntosh
at
someplace.com
is
a
member
of
groups
Developers
loud
talkers,
whatever
the
group
may
be,
it's
not
going
to
care
about
my
username.
It
is
going
to
care
about
the
groups
and
all
assignments
are
done
via
groups.
A
A
I
said
sample:
does
it
oi
DC
supports
it?
The
other
possibilities
is,
you
can
actually
integrate
with
G
Suite?
You
can
integrate
with
ldap
to
pull
group
information.
It
absolutely
works
that
way,
but
you're
now
having
some
slightly
different
configuration
for
it,
I'm
not
going
to
get
in
the
Weeds
on
how
to
configure
all
the
different
options,
because
every
stinking
platform
is
unique.
On
this
point,
OCTA
has
a
different
idb
configuration
than
key
cloak
than
Microsoft's
One
login.
A
A
If
you
are,
can
query
it
independently
of
your
authentication
that
can
be
ldap,
Google,
Groups,
GitHub
groups,
I
think
I'm,
probably
missing
one
in
there.
It's
documented
on
the
website.
That's
your
standard,
for
how
do
you
find
group
information?
Ldap
actually
works,
probably
the
best.
If
you
have
large
numbers
of
groups,
I,
don't
recommend
that
if
you
can
avoid
it,
if
you
can
filter
your
groups
to
a
meaningful
set
of
groups,
it's
a
lot
easier
to
configure
and
pass
through
and
there's
a
reason.
A
I
mentioned
that,
if
you're
passing
large
numbers
of
groups,
Spinnaker
includes
those
as
part
of
the
headers
on
internal
service
Communications,
and
it
can
get
large,
really
quick.
If
you're
in
a
large
number
of
groups
in
the
more
you're
doing
the
more
you
have
to
track
the
more
you
have
to
sink.
You
try
to
reduce
the
overhead.
Where
you
can
you
can't
always
most
of
your
identity
providers
limit
you
to
about
150
groups
as
part
of
the
login
process.
A
Each
one
is
unique:
octa's
100
groups
or
150
Microsoft.
If
it's
saml,
it's
I,
think
100.
If
it's
oauth
2
it's
150,
they're,
all
sort
of
unique
ldap
does
not
have
that
same
limitation.
Ldap
will
let
you
think,
however,
many
groups
you're
just
going
to
hit
certain
scaling
issues
when
you're
mixing
it.
A
So
if
you're
using,
for
example,
x509
and
you
actually
find
Define,
define
your
username
in
the
certificate
and
Fiats
using
ldap,
it
can
actually
look
up
all
of
your
groups
for
your
x509
certificate
from
your
ldap
authentication
store.
So
there's
a
number
of
configurations
to
make
that
work,
but
it
does
work
is
designed
for
that.
Just
I
said
I've
already
mentioned
it
watch
large
numbers
because
you'll
have
to
tune
some
things.
Potentially,
if
you
have
lots
of
group
information
now,
let's
dive
into
the
core
of
how
the
rbac
works.
A
Spinnaker
doesn't
well.
There
is
new
apis
to
add
accounts
dynamically
big
thanks
to
Apple
for
some
of
that
contribution.
But
when
you
define
an
account,
you
set
the
permissions
on
the
account
at
that
pipe.
At
that
time
there
are
two
permissions
types
supported,
read
and
write
by
the
way,
write
does
not
extend.
Read
you
can
grant
something
right
permissions
without
granting
it
read
permissions
I
do
not
recommend
that
that
causes
some
very
goofy
behavior
in
some
of
the
systems.
A
The
fact
that
Spinnaker
defines
read
and
write
permissions
does
not
mean
that
what
Spinnaker
is
communicating
to
has
those
same
permissions
watch
this
your
Spinnaker
is
configured
to
talk
to
AWS
account
one
two,
three
four
five
I'm
missing
some
numbers
there.
Obviously,
however,
what
Spinnaker
is
going
to
do
is
assume
a
role
into
that
account
that
role
that
it
assumes
to
has
no
correlation
whatsoever
to
what
the
roles
and
configuration
is
for.
A
Spinnaker,
Spinnaker,
abstracts,
all
of
your
cloud
provider,
authentication
away
your
users,
don't
have
a
clue
what
it
is
now
it
can
impact
their
deployments
if
you're,
restricting
your
access
to
an
account.
Your
users
are
going
to
be
able
to
deploy
those
resources
in
the
account
you'll
get
weird
hey
unable
to
deploy
manifest
to
namespace
Bob,
because
Bob
did
not
Grant.
The
Spinnaker
service
account
token
permissions
to
access
that
namespace.
A
It
does
come
up
on
a
regular
occasion
that
kind
of
stuff
can
actually
break
Spinnaker
as
well.
If
you're,
not
careful
on
your
target,
account
permissions
because
it's
designed
to
Cache
resources
in
those
and
if
it
can't,
you
may
hit
weird
situations
where
the
account
pay
I
can
deploy.
But
I
can't
read
data
from
it
or
the
entire
cache
mechanism
will
just
fail
and
you
won't
even
see
it
show
up
in
Spinnaker.
A
A
A
You
configure
Spinnaker
to
talk
to
only
one
namespace,
but
if
that
remote
authorization
allows
Spinnaker
to
deploy
to
other
namespaces,
there
is
nothing
that
prevents
anything
in
Spinnaker
from
pointing
those
other
different
name
spaces
other
than
the
fact
that
you
will
get
weird
behaviors
like.
Where
did
my
application
go?
I,
don't
see
it.
Oh
yeah
I
deployed
to
the
wrong
namespace
and
Spinnaker
is
allowed
to
do
it.
It's
just
I
didn't
configure
Spinnaker
to
talk
to
that
other
namespace,
similar
sort
of
things
with
AWS
regions
in
AWS.
A
If
you
can
configure
submitter,
could
only
talk
to
One
region
and
you
have
three
different
regions.
You
deploy
to
some
other
region.
Somehow
yeah
you're
not
going
to
see
it
in
the
UI,
because
spinach
is
going
to
go
I'm
only
cashing
Us
East,
one
yeah,
you
deployed
to
us
West
2,
but
I,
don't
know
about
us.
West
too,
your
employees
will
succeed.
You'll
just
never
see
the
status
of
it.
It
does
not
validate
what
you're
doing
from
that
perspective.
A
Be
nice.
If
it
did
it's
just
not
going
to
be
that
nice
to
you
so
I've
already
mentioned
account
permissions.
You
can
see
some
examples
up
here:
hey
I've
got
a
Kate's
namespace
Dev
Kate's,
namespace,
prod
I'm,
using
this
as
a
simple,
simple
example
talking
to
the
same
config
server
or
a
kubernetes
server,
where
I'm
breaking
it
apart
by
namespace
like
namespace,
prod,
uce
space,
Dev
you'll.
A
Just
because
it's
configured
with
namespace
Dev,
it
doesn't
restrict
it
to
the
plane
to
namespace
Def,
but
permissions.
You
have
read
and
write
you'll
note.
Everyone
in
engineering
managed
I'll
use
that
as
a
simple
example,
my
team
does
manage
spinnakers
for
customers
by
the
way
I've
seen
this
time
and
again
and
I've
done
it
to
myself
more
times
than
I
can
count.
A
A
A
All
right
so
mention
the
coupe
config,
hey
on
your
config
for
your
rbac,
where
you're
defining
your
get
list
right,
watch,
Etc
and
the
namespaces.
If
you
only
want
a
kubernetes
or
a
Spinnaker
to
deploy
that
kubernetes
in
limited
namespaces
scope,
your
permissions
on
the
surface
account
token
or
assume
role
or
whatever
account
permissions
you're
granting
so
you're,
not
over
scoping.
Your
permissions
same
goes
for
AWS,
hey.
A
If
you
don't
want
somebody
access
their
region,
send
some
permissions
boundary
set
some
controls
on
it,
because
it's
not
going
to
prevent
you
from
doing
it
and
I
said:
there's
always
some
weird
UI
impacts.
It
will
also
impact
Pipelines
because
some
of
what
happens
particularly
taking
AWS,
deploy
to
a
different
region
afterwards,
part
of
that
deploy,
was
actually
validate
and
refresh
the
cache
of
that
remote
region
to
verify
that
your
deployment
and
all
its
dependencies
have
made
it
out
there.
A
I
need
to
set
my
silence.
You
get
to
see
my
auto
notes
on
different
people,
I'm
meeting
CDF,
all
right
application.
Permissions
can
be
set
and
changing
on
the
Fly.
That
is
absolutely
correct.
You
can
log
in
and
create
an
application
in.
Spinnaker
has
no
bearing
on
what
account
you're
talking
to
whatsoever.
A
All
that
is
is
controlling
an
application,
which
is
an
abstraction
around
containers
of
pipelines
and
how
those
pipelines
operate.
So
you
can
log
in
create
it
set
permissions.
It's
got
a
different
set
of
permissions.
There's
rewrite
execute
and
create
you
can
get
people
the
ability
to
execute
all
day
long,
but
not
actually
create
pipelines.
A
For
example,
will
say
you
can
also
control
these
there's
a
policy
and
we
document
it
I
think
only
on
the
Armory
docs
page
we've
talked
about
transitioning
that
over,
but
there's
actually
a
policy
config
you
can
Define
in
your
spinner,
config
and
I
think
it's
actually
stores
it
as
a
configuration
in
Fiat.
If
I
remember
right,
that
will
merge
and
set
overrides,
so
you
can
do
Expressions
that
say,
Hey
anything
matching.
This
pattern
will
restrict
you
to
create
permissions,
for
example,
but
again
pipelines
and
orchestration
tests
only
and
unfortunately
the
default
is
hey.
A
A
It'll
actually
try
to
do
some
intelligence
on
it,
but
do
watch
I've
already
mentioned
hey
just
because
I
would
Grant
Engineering
manage
permissions
does
mean
that
it
works
for
all
permissions.
Sometimes
you'll
have
to
also
Grant
everyone
and
they'll
be
critical.
Here
in
a
minute
you
can
come
back.
You
can
change
these
on
the
fly
when
you
do
change
an
application
permissions,
it
creates
a
background
task
that
executes
and
does
a
sync
operation
now,
depending
on
your
scale,
that
can
be
a
fairly
expensive
operation.
A
What
that
does
is
it
goes
over
to
Fiat
and
says:
hey,
sync,
your
permission
so
that
all
the
service
accounts
and
all
the
other
users
have
updated
permissions
for
your
application.
I've
seen
that
take
in
small
orgs
a
few
seconds
to
large
orgs
50
seconds,
so
it's
kind
of
an
expensive
operation.
You
may
actually
see
your
test
fail
at
large
scale,
but
that
has
to
happen
before
the
permissions
actually
start.
A
Working
read,
write,
execute
I,
don't
remember
if
create
was
ever
added
to
the
UI
I
think
create,
maybe
a
configuration
only
and
actually
thinking
about
it.
No
create
is
not
create
pipeline
create
is
creating
new
applications
have
to
correct
my
statement
just
a
minute
ago,
so
you
can
set
in
the
config
file
a
restriction
on
who
can
create
new
applications
that
lets
you
lock
down.
A
The
ability
to,
for
example,
create
an
application
with
no
permissions
in
production
environments,
so
you
have
to
have
either
an
admin
or
a
user
with
create
permissions
to
be
able
to
do
it
that,
in
combination
with
some
regex
lets,
you
do
some
really
Advanced
patterns
like
hey.
Only
team
X
can
create
prod
applications
again
since
applications.
Don't
necessarily
restrict
you
from
the
plan
to
account.
You
do
need
both
so
you've
added
your
permissions
here.
Hey
engineering
managed
everyone,
everyone
can
read
and
execute,
but
only
manage
can
write
to
my
app
I.E
update.
A
The
Pipelines
pipelines
will
run
with
the
permissions
of
who
runs
it,
though,
so
just
because
I
create
the
application.
Permissions
has
no
impact
on
what
the
pipeline
is
running,
as
the
caller
of
a
pipeline
is
the
one
that
is
going
to
run
with
the
permissions
and
it's
the
callers
groups
that
are
associated
with
it.
So
if
I'm
logging
and
I
trick
a
pipeline
manually,
it
will
run
with
my
permissions
for
that
pipeline.
A
A
You
also
have
a
neurosystem
what
they
call
pipeline
permissions,
which
is
easier
to
use,
but
it
has
some
gotchas
with
it
and
I'll
get
into
that
in
a
minute.
Both,
though,
create
an
actual
internal
service
account
that's
masked
internally
and
stored
in
front
50..
Part
of
that
sync
operation
is
reading.
Those
service
accounts
persisting
and
configuring
the
permissions
on
it.
All
it
will
do
is
contain
roles.
It
has
no
authentication,
it's
an
abstraction
around
authorization
for
the
purposes
of
calling
the
internal
systems
I.E
Pipelines.
A
Let's
see
read
my
notes:
Here
one
thing
you
won't
be
able
to
set
any
permissions
unless
you're
also
a
member
of
all
the
groups
that
your
permissions
are
so,
for
example,
if
I'm
only
in
the
everyone
group
I
cannot
modify
or
change
the
permissions
or
even
assign,
for
example,
a
service
account
that
is
in
everyone
and
a
managed
permissions
group.
That
would
be
a
privilege
escalation.
Spinnaker
will
not
let
that
happen.
A
So
got
to
configure
both
they
do
both
work
together.
Just
because
you
can
execute
a
pipeline
all
day.
Long
doesn't
let
you
actually
deploy
to
an
account,
but
you
can
run
a
pipeline
that
says
hey
evaluate
variables,
there's
nothing
that
will
prevent
that
from
running
over
and
over
and
over
as
long
as
you
have
application.
Permissions
I
will
also
issue
a
caution:
hey
resources,
artifacts,
for
example,
your
git
repo,
your
GitHub
API
fetches,
do
not
have
permission
set
on
them.
A
So
if
you're
using
a
GitHub
repo
with
admin
permissions,
you
can
clone
anything
that
that
GitHub
repo
configuration
has
access
to
I,
think
there's
an
RFC
or
there's
some
conversation
around
adding
permissions
to
artifacts,
so
you
can
restrict
who
can
access,
which
artifact
types
I
don't
believe
any
work
is
actually
done
on
that.
That
does
mean
if
you
have
a
sensitive
group.
Theoretically,
somebody
could
access
the
code
base
in
that
sensitive
groups
repos
using
one
of
those
permissions.
It's
an
ugly
little
aspect.
I
would
welcome
contributions
to
fix
that.
A
Please
it's
come
up
a
couple
of
different
times,
but
it's
not
been
implemented
at
this
point,
so
admin
user.
Here's
actually
the
auth
user,
endpoint
I
just
mentioned
a
little
bit
earlier
once
you're
authenticated.
You
can
actually
query
this,
and
this
is
the
first
troubleshooting
endpoint.
It's
on
gate,
I'm
running
gate
on
a
prefix,
API
V1.
That's
how
we'd
like
to
run
our
stuff.
So
we're
not
dealing
with
cores.
It's
all
the
same
load
balancer
you
can
see
here.
A
A
A
I
will
point
out
one
more
thing:
the
accounts.
You
can
also
see
the
accounts,
that's
directly
tied
to
the
configuration
file
where
you
have
access.
So
when
you
configure
it-
and
you
say:
oh
yeah,
everyone
has
access
to
Dev
a
lot
of
accounts
that
comes
from
that
authentication,
where
it
merges
all
the
different
accounts
into
the
cache.
A
Literally.
This
is
just
a
direct
read
on
that.
So
I
said:
hey
everyone
I
created
an
everyone
group.
Well,
yeah
you
try
to
create
a
new
pipeline
could
not
save
pipeline.
If
your
application
does
not
Grant
it,
but
the
everyone
group
can
execute
keynote
execute
that
doesn't
mean
the
execution
will
work
successfully
if
the
account
or
the
pipeline
is
trying
to
deploy
to
a
resource
that
that
user
is
not
accessible
to
or
does
not
have
accessible
to
them.
So
do
keep
that
in
mind
users
with
parite.
A
A
So
when
it
starts,
there's
a
configuration-
and
particularly
this
is
great
for
automated,
where
you
can
say:
hey
propagate
the
authentication
of
whoever
approves
the
pipeline,
which
means
that
the
permissions
of
the
pipeline
will
suddenly
change
to
whoever
clicks
that
manual
judgment
approval
stage,
so
you
can
say:
hey
group
X
you're
allowed
to
deploy,
so
you
can
have
everybody
trigger
it,
but
only
your
change
control
group
can
deploy
it
to
prod
automated
triggers.
I
mentioned
these
a
little
bit
earlier.
Their
service
accounts
they're
fake
users
that
are
abstracted.
A
I've
already
said
it
once
read,
is
not
defaulted,
don't
forget
to
add,
read
permissions
or
you
get
in
weird
cases
where
the
deploy
works
and
it
can
no
longer
cache
the
results
and
tell
what
the
heck
happened
shot
myself
in
the
foot
more
than
a
few
times
that
way
pipeline
permissions.
It's
the
newer
easier!
You
have
to
configure
it.
It
makes
it
a
lot
easier
to
assign
permissions.
You
no
longer
need
to
pre-define
service
accounts.
A
You
can
just
go
in
and
start
typing
here's
the
roles
I
want
the
pipeline
to
run
as,
and
it
will
dynamically
generate.
A
service
account
has
the
same
restrictions.
It
does
change
the
pipeline
Json.
There's
a
roles
block
that
lets.
You
set
the
rules.
The
pipeline
will
run
as
again
same
restrictions.
You
can
only
assign
those
if
you're
a
member
of
them.
A
It
also
has
an
interesting
after
effect,
if
you
ever
try
to
edit
the
pipeline
one,
the
Sync
has
to
complete,
so
the
service
account
exists
and
you
have
to
be
in
all
those
roles
for
that
to
work.
I
do
recommend
that
as
the
default
anymore,
because
it
makes
using
our
back
and
doing
our
back
so
much
easier.
A
A
A
Also
one
of
the
other
key
things
that
people
fail
on.
Your
automated
triggers
have
to
have
execute
permissions
on
the
application
itself.
So
if
you
assign
a
role
just
to
the
application
or
to
the
pipeline,
and
that
role
is
not
in
the
execute
permissions,
it's
not
going
to
be
able
to
actually
trigger
and
it
will
fail
silently
with
no
error
any
place.
It's
incredibly
annoying
policy.
I
mentioned
that
we've
got
docs
up
here.
I
would
recommend
going
out
to
docs
Armory.
A
There
is
a
number
of
improvements.
There's
been
recent
sync
permissions
to
Fiat
to
improve
performance
time.
I
mentioned
off
artifacts
I
would
absolutely
welcome.
Artifact
permissions
there's
also
some
discussion
around
orchestration
tasks
and
some
of
the
permissions
there
and
we're
talking
about
reducing
sync
time
is
ready.
A
Docs
I
mentioned
that
there's
several
different
docs
on
Spinnaker
IO.
We
have
a
pretty
good
x-59
walkthrough
on
how
to
do
x509
off
with
the
open,
SSL
commands,
keep
in
mind,
that's
a
whole
different
discussion.
I
could
spend
half
a
day
talking
about
TLS
and
certs
and
management,
and
then
there's
a
very
good
permissions
Matrix
on
our
website
that
talks
about
all
the
permissions,
so
there's
an
email,
personal
work
and
I'm
on
Twitter.
If
you
have
questions,
feel
free
to
ask
them,
I
think
I'm
about
time.
A
A
B
A
You
can
only
see
the
permissions
combo
box
if
you
enable
authorization,
if
you
don't
enable
authorization,
you
will
not
see
the
ability
to
assign
permissions
any
place,
but
all
of
these
features
have
been
around
since
at
least
one
22.
Something
like
that.
So,
if
you're
not
seeing
the
permissions,
you've
got
a
probably
a
configuration
issue
on
your
off
and
off
Z
blocks.