►
From YouTube: Spinnaker Workshop Part One - Cloud Compliance and Entitlements - Stephen Atwell, Armory
Description
Spinnaker Workshop Part One - Cloud Compliance and Entitlements - Stephen Atwell, Armory
Join industry experts who will lead talks focusing on several key and core items that will give you an overview of the breadth of the power of the Spinnaker platform. In this interactive workshop, you will learn about:
How you can easily establish and enforce automated uniform compliance
Current use cases for Armory Policy Engine
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
I'm
going
to
give
you
a
quick
walkthrough
of
some
cloud
compliance
and
entitlements
use
cases
that
my
customers
are
implementing
today
using
armory
policy
engine.
I'm
going
to
start
by
giving
you
a
high
level
overview
of
the
policy
engine
ecosystem,
I'm
going
to
start
by
telling
you
what
spinnaker
is
and
how
our
customers
are
leveraging.
A
It
I'm
going
to
tell
you
what
policy
engine
is
and
then
I'm
going
to
tell
you
what
open
policy
agent
and
rego
are
I'm
going
to
explain
how
all
of
these
components
come
together
in
order
to
fulfill
these
use
cases
once
we've
covered
the
high
level
ecosystem,
we're
going
to
dive
into
several
of
these
use
cases
we're
going
to
break
the
use
cases
down
into
two
different
families,
we're
going
to
start
by
talking
about
compliance
use
cases.
These
are
use
cases,
for
example,
to
enforce
sock
audit
controls.
A
They
ensure
that
a
company
stays
in
compliance
to
their
internal
policies,
as
well
as
regulations
that
they
need
to
comply
with.
Our
second
set
of
use
cases
is
going
to
be
around
entitlements.
These
are
very
much
related
to
who
is
allowed
to
do
what.
So
without
further
ado,
let's
hop
over
into
our
high
level
overview.
A
So
spinnaker
is
an
open
source
deployment
platform.
It
allows
you
to
deploy
code
to
any
of
the
major
cloud
environments,
so
it
can
deploy
to
amazon
web
services,
microsoft,
azure,
google
cloud
platform,
it
can
also
deploy
to
kubernetes,
and
it
adds
a
lot
of
of
advanced
capabilities.
On
top
of
that
simple
deploy.
So,
for
example,
you
can
really
easily
do
a
blue
green
deploy.
A
You
can
really
easily
do
a
canary,
deploy
and
armory
policy
engine
is
a
plug-in
to
spinnaker
and
it
adds
some
robust
policy
capabilities
to
spinnaker,
so
armory
policy
engine,
basically
instruments
everything
you
can
do
within
spinnaker
and
it
allows
you
to
write
policies
against
them
in
another
open
source
framework
that
is
called
open
policy
agent,
open
policy
agent
can
execute
policies.
Its
policies
are
written
in
a
language
that
is
called
rego
and
then
it
also
outputs.
What's
called
the
decision.
Log
and
the
decision.
Log
is
an
audit
history
of
every
policy
decision.
A
Open
policy
agent
has
made
so
every
time
you
do
a
deploy
with
spinnaker
armory
policy
engine
reaches
out
to
open
policy
agent
and
open
policy.
Agent
makes
a
note
of
what
the
policy
check
was.
You
know
what
infrastructure
were
you
trying
to
deploy
as
well,
as
was
that
deploy
allowed
to
happen?
What
was
the
decision.
A
While
we
are
going
through
our
use
cases,
I'm
going
to
be
showing
you
some
rego
scripts
that
implement
these
use
cases.
So
rego
is
a
fairly
different
language
from
from
many
of
the
languages,
you've-
probably
probably
used
in
the
past.
So
this
is
going
to
be
a
high
level
primer
of
some
things
that,
if
you
understand
about
rego,
will
help
you
to
follow
along
on
those
policies.
A
So
the
first
thing
I
want
you
to
know
about
reggo
is
that
it
uses
a
different
structure
for
its
if
statements
than
any
other
language
I've
used
in
the
past,
so
you
know
instead
of
having
kind
of,
if
then
the
condition
and
then
the
statement
that
happens.
If
that
condition
is
true,
it
reverses
it.
It
starts
by
putting
the
statement
that
only
is
evaluated
if
the
condition
is
true
and
then
it
puts
the
condition
in
in
your
squiggly
brackets.
A
So
here
you
can
see
this
statue
equals
true.
That
will
only
be
evaluated
if
the
curly
brackets
evaluate
to
true
here,
you'll
notice.
I
have
two
sets
of
curly
brackets,
so
the
reason
for
that
is
inside
of
a
set
of
curly
brackets.
All
of
the
conditions
are
anded
together,
but
you
can
have
multiple
sets
of
curly
brackets
and
those
will
be
org
together.
So
in
this
case
it
will
set
statue
equals
yes.
A
A
A
So,
at
its
simplest
you'll
see
this
value,
equals
array
square
bracket
underscore
score
square
bracket
and
what
that
underscore
means
is
try
every
single
value,
and
this
statement
is
true:
if
any
value
in
that
array
matches
this
condition,
so
it
will
simply
check
every
single
thing
coming
down
here.
This
sum
function.
A
This
is
for
find
some
value
of
I,
where
all
of
these
values
are
true,
so
this
will
return
true.
If
in
this
has
statues
array,
there
is
any
element
where
both
city
and
country
match
my
city
and
country,
so
this
allows
us
to
with
just
these
three
lines
have
this
rule
from
up
above,
but
you
know
it's
not
going
to
match
on
new
york's
that
are
not
in
the
united
states.
A
So,
finally,
for
rule
number
three
with
this,
you
know
any
value.
Syntax
things
get
complicated
when
you
want
to
negate
it
so
rego
forces
you
to
be
very
explicit
anytime,
you
are
doing
you
know
negation
around
this.
You
know
find
any
value
syntax.
So
you
know
these
two
functions
on
the
left
are
not
valid
and
the
way
you
do
negation
in
rego
is
you
make
a
function,
so
you
make
a
function
in
this
case
it's
called
in
array
and
you
have
that
not
have
any
negation,
and
then
you
make
a
second
function.
A
Call
that
just
negates
it
so
you'll
see
me
using
these
functions
and
then
calling
not
and
then
the
function
on
a
fairly
regular
basis
throughout
the
examples,
and
that
is
just
how
you
do
negation
in
rego
last
thing:
that's
a
pattern
that
you'll
see
is
there.
Will
be
a
few
places
where
I
am
using
this
object.get
function
and
the
reason
for
that
is
in
rego.
A
If
you
reference
a
variable
and
it
doesn't
exist,
then
that
condition
will
always
evaluate
to
false.
So
you
can't,
for
example,
say
hey.
If
this
variable
equals
null
be
true
directly
the
object.get
function,
it
allows
you
to
specify
a
default
value
to
give
back
for
the
variable
if
it
does
not
have
any
if
it
does
not
exist,
and
this
value
allows
you
to
very
easily
do
a
null
track.
A
So
those
are
some
basic
things
for
rego
that
I
hope
help
you
follow
along
in
the
example
without
further
ado,
let's
go
into
our
first
family
of
use
cases.
These
use
cases
are
things.
Customers
are
doing
in
order
to
ensure
that
their
production
environment
runs
in
line
with
their
policies
in
line
with
their
regulations.
A
It's
not
about
like
who
is
allowed
to
do
what,
but
more
what
code?
Are
we
okay
with
running
in
production
at
all,
so
our
very
first
example
use
case.
I'm
keeping
this
one
fairly,
simple,
simply:
checks
to
see
if
a
particular
pipeline
stage
exists
in
any
pipeline,
that's
going
to
deploy
to
production.
A
So
if
a
customer
wants
to
deploy
to
production,
they
need
to
do
this.
This
stage
in
this
particular
example,
I'm
using
the
manual
judgment
stage,
we
do
have
customers
who
do
stages
other
than
manual
judgment
with
this
type
as
well.
It
can
be
done
with
any
stage
so
later
on.
We
will
cover
a
more
powerful
version
of
this
example,
because
this
version
is
just
checking
whether
the
stage
exists.
It's
not
caring
about
things
like
stage
order,
for
example,
so
let's
walk
through
how
this
policy
works.
A
So
this
first
line
specifies
what
type
of
policy
it
is.
So
there
are
several
different
types
of
policy
checks
that
policy
engine
will
run
and
they
have
different
pieces
of
data
that
you
can
write
your
rule
against.
So
the
opa.pipelines
package
is
the
package
you
use
to
write
policies
that
occur
when
a
pipeline
is
being
saved.
A
A
Here
we
have
our
actual
rule,
so
this
rule
is
going
to
deny
and
provide
back
this
message
to
the
user.
If
this
condition
is
true,
so
you're
going
to
see
this
pattern
in
a
lot
of
these
examples,
the
condition
we're
checking
in
this
case
is
we're
looking
for
any
value
of
j.
So
if
this
value
exists
such
that
it
is
a
deploy
manifest
stage
where
the
account
is
in
our
list
of
production
accounts-
and
there
is
also
no
manual
judgments.
A
A
So
a
lot
of
companies
when
they're
adopting
the
cloud
or
they're
adopting
kubernetes
have
challenges
with
making
sure
they
know
who
owns
and
is
responsible
for
every
piece
of
infrastructure,
that's
deployed
and
a
lot
of
companies
implement.
You
know
tagging
or
annotations
in
order
to
have
this
visibility,
but
then
they
have
the
challenge
of
enforcing
that
all
of
their
application
developers
are
actually
tagging
everything
they
deploy.
A
A
A
Here
we
have
again
the
list
of
what
annotations
we
require
that
users
have
set
and
then
down
here
we've
got
the
condition
that
if
it's
true,
we
will
not
allow
this.
So
what
we're
going
to
do
for
this
is
we're
going
to
go
through
all
of
the
annotations
that
are
in
the
manifest,
and
we
are
going
to
simply
read
from
that
annotation
every
required
annotation
and
if
it's
set
to
null
we're
going
to
fail,
so
the
instant
that
any
of
these
annotations
is
set
to
null.
A
A
For
our
third
use
case
family,
this
is
quite
similar
to
the
the
last
use
case.
So
you
know
it's.
We
want
to
go
and
analyze
manifest
when
it
is
being
deployed
and
ensure
something
is
true,
but
the
last
one
was
kind
of
a
internal
visibility
best
practice,
this
one's
really
more
around
ensuring
our
production
environment
stays
safe.
So
a
lot
of
companies
have
requirements
for
data
encryption
in
transit
and
for
data,
encryption
and
transit.
A
How
you
ensure
your
data
is
encrypted,
really
amounts
to
which
protocols
are
you
using?
You
know
if
you're
using
http
it's
not
encrypted
if
you're
using
https?
It
is
so.
This
policy
simply
prevents
a
large
number
of
services
from
being
exposed
for
their
unencrypted
versions.
So
this
will
block
http,
which
is
port
80..
It
will
also
block
several
common
alternate
ports
for
running
http,
but
you'll
notice.
It
allows
https,
which
is
port
443.
A
You'll
notice
that
this
rule
is
doing
three
checks
that
are
org
together.
There
are
different
types
of
kubernetes
manifests.
So
if
you're
deploying
a
service
versus
if
you're,
deploying
a
pod
where
the
path
in
the
manifest
is
to
ports
is
different,
so
in
a
service
manifest,
our
ports
are
in
this
spec
dot
ports
section
and
then
inside
of
that
you
can
have
a
port
or
a
target
port.
A
A
A
A
So
imagine
that
you
have
a
security
scanning
tool.
A
lot
of
these
tools
maintain
lists
of
what
they've
scanned.
So
you
know
we
have
a
process
where
we
deploy
docker
images.
We
run
a
security
scanner
on
them
and
when
that
scanner
is
done,
it
makes
a
note
that
hey
this
particular
image
has
been
approved
to
be
used.
It
passed
the
check
or
you
know.
A
So
in
this
case
I'm
not
maintaining
the
list
of
approved
images
in
the
policy,
because
it's
changing
frequently.
I
am
attempting,
in
this
example
to
read
the
list
of
approved
images
from
the
rego
data
document.
The
data
document
is
a
document
that
you
can
upload
into
and
then
can
be
referenced
from
your
policies.
So
it's
got
a
simple
api
and
you
can
hook
it
up
to,
for
example,
your
security
scanners.
A
An
alternative
that
can
also
be
done
is
rego
does
allow
you
to
do
simple.
You
know
http
rest
api,
calls
from
within
your
policy,
so
there's
two
different
ways
to
kind
of
do
this
integration
to
your
security
scanner
either
you
can
call
its
apis
from
within
your
policy
or
you
can
have
it
when
it
finishes
a
scan,
upload
new
data
to
rego
that
specifies
the
list
of
approved
images.
A
So
here
again
I'm
running
on
those
deploy
manifest
stages.
So
anytime
we're
going
to
deploy
a
manifest
and
I've
got
two
helper
functions
down.
Here
is
the
image
in
the
list
of
approved
images.
It's
just
going
and
you
know
checking
that
array,
and
then
I've
got
is
the
image
unapproved,
which
is
just
doing
that
not
function?
All
of
the
checks
here
are
just
asking
whether
or
not
an
image
is
unapproved.
The
difference
between
them
is
the
path.
A
So
you
know
I
mentioned
on
the
last
example
that,
depending
on
the
kind
that's
being
deployed
the
path
and
the
kubernetes
manifest
for
report
change,
the
same
is
true
of
the
image
so
for
pods
versus
pod
templates,
there
is
a
slightly
different
path
for
your
container
image,
so
this
checks
your
normal
container
image
and
then
in
kubernetes.
You
also
have
a
knit
containers
which
are
containers
that
basically
can
start
up
and
do
things
like,
for
example,
copy
files
around
and
then
go
away
after
kind
of
initial
configuring
of
the
pod.
A
So
if
any
of
our
containers
anywhere
in
our
manifest,
are
not
on
the
approved
list,
this
will
give
back
that
rejection
and
this
again
forces
that
your
scanner
has
run
and
approved
every
image
before
it
can
reach
production
for
our
second
use
case
family.
This
is
a
class
called
entitlements.
These
are
very
focused
on
who
can
do
what
and
we
have
different
customers
who
are
different.
Doing
different
rules
around
you
know
which
actions
are
they
trying
to
restrict?
But
these
are
all
rules
around
who
is
allowed
to
do
what
in
the
company.
A
Our
first
example
is
going
to
be
high
level
restricting
an
action
by
a
role,
so
in
the
spinnaker
ui
for
an
application.
You
can
open
the
clusters,
tab
and
the
clusters.
Tab
will
show
you
what
infrastructure
is
running
for
your
application
and
it
allows
you
to
click
on
any
deployed
pod
or
any
deployment,
and
it
allows
you
to
edit
that
deployment.
So
you
can,
you
can
say
edit
and
you
can
literally
just
inline
edit
the
the
kubernetes
manifest.
A
You
can
also
choose
delete
and
it
will
completely
delete
your
your
deployment
for
you
or
you
can
choose
scale
and
tell
it
hey.
I
need
more
pods.
So
a
lot
of
our
customers
want
some
of
this
functionality
for
some
users,
but
they
don't
want
everyone
to
have
access
to
it.
So
this
particular
example
takes
one
of
those
tasks
and
it
makes
it
so
that
that
task
can
only
be
run
by
admin,
users
or
users
of
a
particular
role.
A
This
would
be
the
the
task
type
that
is
created
when
you
hit
that
edit
button
that
I
mentioned
delete
manifest
would
be
the
task
type
created
if
you
try
to
delete
the
entire
infrastructure,
and
it
will
only
allow
it
if
the
user
is
an
admin
or
if
the
user
has
the
desired
role.
If
either
of
those
is
true,
then
it
will
be
allowed
if
they're,
both
false,
then
the
user
will
get
back
this
message
and
will
be
denied
access.
A
So
a
lot
of
our
customers
have
audit
requirements
where
they
need
to
maintain
separation
of
duties,
so
the
user
who
implemented
a
code
change
cannot
also
approve
that
code
change
into
production
and
many
of
these
companies
have
multiple
different
sign-offs
that
need
to
happen.
So
in
this
particular
case,
I
have
a
rule
that
I
don't
want
code
deployed
to
a
production
account
unless
it
has
had
a
sign
off,
occur
from
my
information
security
department
and
from
my
qa
department,
and
in
this
case
those
are
manual
sign-offs.
A
A
So
how
does
it
work
so
this
stage
graph
data
structure
reads
the
input
and
the
input
contains
a
series
of
of
stages,
all
of
the
stage
data
for
the
pipeline
that
is
being
executed,
or
in
this
case
saved,
and
that
stage
data
is
in
a
native
spinnaker
format.
So
this
code
here
creates
a
data
structure
called
stage
graph
and
it
is
in
a
graph
format
that
is
easy
to
use
in
rego.
A
A
This
first
helper
function
takes
the
index
of
a
stage
and
it
takes
a
role
and
it
returns
true
or
false.
Is
there
an
approval
by
that
role
earlier
in
the
pipeline
than
this
index,
and
this
is
running
that
graph
analysis
that
I
mentioned
in
order
to
make
sure
that
it
only
looks
at
earlier
stages
for
roles,
we're
looking
at
the
selected
role
of
the
stage
and
also
making
sure
that
only
one
role
can
approve
that
stage,
so
we
want
to
ensure
that
both
qa
and
infosec
have
approved
it.
A
A
So
for
our
rule,
we
will
go
through
every
stage
and
for
every
deploy,
manifest
stage
that
is
deploying
to
a
production
account.
We
will
fail
if
it
lacks
an
earlier
approval
by
either
the
qa
role
or
the
infosec
rule.
So
if
either
of
those
roles
haven't
approved
it
we
fail.
If
they've
both
approved
it,
then
we
don't
give
back
the
error
message
and
the
user
is
allowed
to
deploy.
A
A
A
A
There
is
at
a
high
level
the
ability
to
trigger
at
the
start
of
the
execution
of
any
pipeline
stage.
There
is
also
the
ability
to
trigger
on
any
save
pipeline
or
any
api
call
from
the
ui
to
the
spinnaker
apis.
There
are
also
some
policy
checks
that
can
be
implemented
to
turn
on
and
off
certain
ui
buttons
based
off
role
so
and
and
andre
sentinel
is
very
specific
to
the
hashicorp
stack.
A
So
you
know
if
you're,
using
terraform
and
you're
doing
everything
through
terraform
it's
a
great
option
if
opa
started
largely
in
kubernetes,
so
you
can
use
opa
via
kubernetes
admission,
controller
and
policy
engine
uses
opa
because
it
basically
was
when
we
looked
at
it.
The
the
starting
point
that
looked
like
it
would
would
work
best
with
the
largest
range
of
technologies
and
policy
engine
is
specifically
opa
on
top
of
spinnaker.
A
And
then
the
announcement
that
I
was
asked
to
make
during
the
q
a
is
that
there
is
a
car
in
the
parking
lot
that
has
its
lights
on
the
license.
Plate
number
is
c-d-r-o-k-s,
the
car
is
a
code
by
the
manufacturer's
secret.
So
if
you
drive
a
secret
code
with
the
license
plate,
number
r
o
k
s
your
lights
are
on.
A
Cool,
so
if
you're
interested
in
learning
anything
more
about
policy
engine
or
if
you
think
of
another
question
you
have
on
this
session,
I
will
be
manning
the
armory
booth
at
about
this
time
tomorrow
morning,
so
feel
free
to
stop
on
by
and
if
that
time
doesn't
work
for
you
and
you've
got.
You
want
to
know
more
about
any
of
this.
You
know
if
you
stop
by
and
ask
someone
else,
I'm
sure
they'll
be
they'll,
be
willing
to
help
you
get
in
touch
with.
A
Me,
oh,
can
opa
policy
work
on
aws
cloud
formation
templates?
So
yes,
but
it
depends
on
how
you
are
deploying
to
aws
when
you
are
deploying
to
aws.
You
can
have
your
your
your
templates
as
part
of
your
spinnaker
config
or
you
can
read
the
configuration
from
s3.
So,
for
example,
we
have
a
customer
who
is
doing
reading
ecs
task
definitions
from
s3
the
situations
where
you're
reading
config
from
s3.
A
A
Yes,
so
I
on
terraformer
with
opa,
I
put
out
a
blog
post,
I
wanna
say
a
couple
months
ago
that
you
used
opa
and
terraformer.
There
are
also
in
the
package
list
that
I
mentioned,
for
which
packages
you
can
do.
One
of
those
is
policies
the
trigger
before
a
terraform
execution
stage,
and
all
of
those
packages
do
have
policy
some
example
policies
in
there.
A
So
so
sudeep
there
are,
there
are
not
currently
any
katakota
labs.
There
is
a
an
aws,
quick
start
that
I
know
just
became
available
for
getting
armory
spinnaker
stood
up
in
aws.
There
are
there's
also
you
know.
If
you
look
at
something
like
policy
engine,
if
you've
got
normal
open
source,
spinnaker
deployed
it's
fairly
easy
to
turn
on
policy
engine
to
try
out,
and
we
can
also
get
you.
You
know
a
hands-on
sales
demo.
A
So
so
jesse
the
data
dot,
approved
images.
The
way
that's
passed
into
policy
execution
is
open.
Policy
agent
has
what
is
called
the
data
document,
and
the
data
document
has
a
api
for
uploading
to
anything
in
it.
So
anytime,
you
see
data
dot,
something
in
rego
that
basically
is
referencing
a
a
piece
of
data
that
is
uploaded
via
opa's
api,
as
opposed
to
being
maintained
in
the
policy.
A
Sudeep
that
that
is
a
a
great
ask
I'll
if
you,
if
you
get
me
your
contact
information,
I
can
probably
get
you
something
there
on
the
comparison
to
azure
policy
at
a
high
level.
When
you
look
at
opa
or
sentinel
or
azer
policy
or
aws
config
rules,
a
lot
of
them
can
be
used
for
similar
things,
but
most
of
the
other
solutions
are
very
technology.
Specific
policy
engine
gives
you
kind
of
a
single
central
place.
A
You
can
define
all
of
your
policies,
regardless
of
which
cloud
you're
running
on.
There
is
also
a
advantage
that
we
have
over
several
others
in
that
most
of
the
other
products
in
the
space,
deploy
your
infrastructure
and
then
flag.
It
is
violating
policy
where
spinnaker
allows
and
policy
engine
allows
you
to
check
the
policy
violation
before
you
deploy
and
prevent
that
deploy
from
ever
running.
If
it
would
cause
a
policy.
A
A
A
Cool
thanks
everyone.
I
hope
you
found
this
useful
and
and
just
to
make
sure
everyone
caught
it
earlier.
There
is
a
car
in
the
parking
garage
with
its
lights
on.
It
is
a
a
secret
code
with
the
license
plate
number
c
d,
r,
o
k
s
and,
if
you're
trying
to
remember
that
license
plate
number
it's
in
the
qa
chat,
so
you
can
copy
it
out
of
there
as
well.