►
From YouTube: CDF - SIG Interoperability Meeting 2021-06-03
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
B
B
D
I've
done
a
two-hour
tutorial
presentation
just
before
this,
so
my
voice
is
a
bit
sore,
but
I
think
I'll
make
it.
Two
hours
is
a
long
time.
It's
a
long
time
for
a
monologue.
Exactly.
A
Yeah
it
was
there
what
there
wasn't
like
there
wasn't
any
opportunity
for
anyone
else
to
gonna
grab
the.
B
E
E
E
I
guess
you
could
say
you
know,
because
we're
we're
an
alien
we
we
did
like
snippets
from
flash
gordon
from
the
1950s
which,
if
you
haven't
watched
them,
you
will
crack
up
it's
thoroughly
entertaining
you
almost
can
see
the
wires
hanging
from
the
spaceships
flying
around.
E
And
it
helped,
but
I
I'm
thinking
that
there's
got
to
be
ways
to
do
those
kinds
of
presentations
that
mix
up
different.
You
know
different
solutions
like.
G
Excuse
me,
good
morning
or
good
afternoon
and
evening,
depending
on
where
you
are,
I
used
this:
it's
not
very
fancy
with
the
company.
It's
not
terribly
the
the
presentation
of
what
they
do
is
not
very
fancy,
but
the
material
that
they
present
and
the
way
they
present.
It
is
pretty
effective,
actually.
B
H
Sure,
okay,
thanks
everyone
for
joining
the
meeting.
Sorry
for
interrupting
your
chat
was
fun
to
listen,
so
I
hope
you
can
see
my
screen
right
now.
I
hope
I
am
sharing
the
hmd
document.
If
not,
then
I
need
to
fix
that.
H
So
we
gave
a
break
for
our
meetings.
We
skipped
the
previous
meeting
so
because
there
wasn't
any
topic
and
there
was
many
progress
with
some
of
the
topics
we
have
been
working
on.
So
this
is
kind
of
a
recap
meeting.
H
H
Something
to
travel
during
cdcon,
so
please
add
that
to
your
schedule
and
join
to
the
discussion
and
then
just
a
quick
reminder
about
spdx
file
information
topic,
which
we
said
we
will
have
a
conversation
about
it
using
github
discussions,
and
then
I
see
anders
joining
us
thanks
for
joining
anders
and
we'll
have
a
presentation
from
you
on
open
policy
agent.
So
we
will
use
the
rest
of
the
meeting
for
your
presentation
and
any
follow-up
conversations,
and
if
anyone
has
any
topic
you
want
to
add.
Please
do
that.
H
During
the
previous
meeting
a
month
ago,
we
said
we
will
start
with
this
file.
Information
for
spdx
specification
and
two
action
items
are
there.
H
The
first
action
item
is
not
done
because
I
was
able
to
create
the
discussion
topic
this
morning,
but
the
second
action
item
is
enabling
github
discussions
for
the
repository,
which
I
did
so
we
can
close
that
action
item
and
other
action
item
was
on
kara
and
we
have
anders
here.
So
we
can
close
ex
night
one
kara
to
reach
out
to
police
asian
community
thanks
kara
for
that.
H
And
those
were
the
action
items
so
now.
The
next
topic
is
the
birth
of
weather
session.
So,
as
you
know,
like
last
cdcon,
silicon
is
having
burst
feather
sessions.
H
Let
me
go
to
full
schedule
and
if
you
click
the
burst
of
feather
sessions
or
filter
using
both
sections,
you
will
see
we
have
nine
birth
of
a
feather
sessions
and
if
I
am
counting
it
right,
three
of
them
are
four
specialties
groups.
The
first
one
is
events
specialized
group
which
will
happen
on
wednesday
june
23rd.
H
So
please
join
that
one.
If
you
want
to
take
part
in
the
conversation-
and
you
know,
contribute
to
the
events
sake
or
just
hear
what
they're
up
to,
because
I
see
lots
of
activity
in
slack
channel
on
github
repository
looks
like
they
are,
having
lots
of
fun
there
so
join
to
that
one,
and
then
the
ml
ops
seed
will
happen
at
the
same
time
as
sig
events,
which
is
kind
of
a
bit
unfortunate.
H
So
people
can,
you
know,
participate
in
both
seats
if
they
are
in
different
pace
times
and
then
the
sig
interoperability
verse
of
federation
will
happen
on
thursday
june
24th
and
rest
of
the
six
are
four
projects,
starting
with
jenkins
x
and
then
all
telus
has
some
versa.
Feather
at
2
pm
eastern
daylight
time
and
tech
tone
has
its
own
verse
of
feather.
So
just
please
check
the
schedule
and
if
you
have
any
concerns
with
the
you
know,
scheduling
reach
out
to
jaclyn
or
others
to
see
if
they
can
do
anything
with
the
schedule.
E
H
Yeah
yeah,
I
think
both
sessions,
like
I'm
not
saying
like
the
talks
or
presentations,
are
not
important,
but
you
know
both
sessions
are
generally
interactive
and,
like
you
may
you
know,
watch
session
recordings
afterwards,
but
missing
verse
of
a
feather
session
means
that
you
miss
the
discussion
live.
So
that
is
why
I
am
kind
of
you
know.
H
Maybe
let
me
action
myself,
I
will
reach
out
to
jackie
and
tracy
and
see
if
they
can
do
anything,
because,
like
project
sessions
are
important
as
well,
because
then
no
events
project
is
talking
about
jenkins
sex
collaboration,
for
example.
So
jenkins
sex
community
will
miss
taking
part
in
events,
personal
feather
and
vice
versa.
B
E
E
J
H
E
Yeah
I'll
mention
it
I'm
on
the
there's.
A
strategy
called
today
for
the
board
I'll
mention
it
on
the
board
too,
but
if
you
could
go
ahead
and
reach
out
to
those
jennifer
and
tracy
and
jackie
and
I'll
see.
H
H
So
this
let
me
find
the
original
document.
So,
as
you
may
remember,
we
java
tried
to
start
conversation
around
to
standardize
metadata
on
hack
md
document,
and
then
I
think
it
was
james
stression
who
suggested
to
create
a
separate
ripple
to
continue
with
that
work
and
that
didn't
get
much
no
attention
and
then,
after
we
met
with
spdxcoin
or
after
kate,
stills
from
spx
community
joined
our
meeting
and
presented
what
they
are
doing
in
spdx
community.
H
The
consensus
within
this
group
was
to
you
know,
instead
of
us
starting
everything
from
scratch,
we
should
perhaps
look
at
what
they
have
done
and
what
are
the
overlaps?
What
are
the
gaps
and
perhaps
contribute
to
spdx
from
ci
cd
perspective
and
kate
was
also
in
agreement
that
they
may
benefit
from
expertise
from
cdf
community
as
part
of
their.
H
You
know
work
on
a
similar
topic
and
then
we
decided
to
use
the
discussions
to
you
know
continue
this
work
and
two
hours
ago
I
created
the
issue
or
the
discussion
topic,
and
I
realized
this
was
very
late
to
do,
but
I
tagged
few
of
you
there
steve
james
kate
and
tracy
miranda,
so
chris,
if
you
have
any
you
know
ideas
about
the
file
information,
anything
you
feel
missing
in
the
spec
when
it
comes
to
ci,
cd
or
anything.
You
see,
you
know
this
is
perfect.
H
F
Now
that
that
sounds
like
a
good
plan
and
I
think
whatever
we
find
that's
not
in
the
spec,
I
think
the
spdx
group
is
interested
in
our
feedback,
so
especially
since
they're
they're,
coming
at
it
from
a
different
angle
than
we
are
so
it'll,
be
a
useful
information
for
us
to
gather
for
for
this
process.
H
I
also
want
to
andrea
emil,
maybe
tracy,
you
know,
I
I've
seen
references
to
espdx
in
events,
discussions
as
well,
and
I
I
noticed
this
vocabulary.
Work
is
happening
and
some
kind
of
you
know
cdf
events
work
start
that
based
on
quadrants,
I
know,
if
you
have
plans
to
you,
know
somehow
look
at
what
spdx
done
and
perhaps
or
provide
feedback
from
iran's
seek.
E
I
I
mean
I've.
Actually,
I've
looked
at
both
of
them
and
it
didn't
even
dawn
on
me
to
try
to
cross-pollinate
between
these
two.
J
H
But
then
what
I
can
suggest
is
like
this
discussion
already
start
here.
Maybe
once
you
see
some
further
discussions
under
this,
you
know
topic.
Maybe
when
you
see
oh,
this
is
pretty
related
to
what
we
are
doing
and
then
you
can
bring
that
into
your
events.
Seek
when
you
have.
You
know
time
to
look
at
that,
because
I
see
you
are
very
focused
on
the
proof
of
concept,
work
and
vocabulary
work
at
the
moment,
and
you
may
not
have
time
to
overlook
spdx
as
well.
E
It
will
it'll
be
something
that
the
ortelius
team
will
keep
focused
on.
I
can
just
I'll
promise
you
that
we've
got
some
stuff
we
have
to
get
done
and
get
through,
but
on.
The
road
map
is
aggregating,
this
information
up
to
a
logical
application.
So
we
are
we're
thinking
about
how
this
this
data
needs
to
be
displayed
and
shared
and
when
it
should
be
gathered,
so
we
will.
We
will
we'll
circle
around
and
get
back
get
back
to
it.
E
It's
something
we
have
started,
but
we
we've
got
to
finish
some
service
catalog
data.
First,
I
don't
want
to
throw
it
to
the
team
just
yet,
but
we
they
they've,
already
started
thinking
through
it.
I
mean
steve.
You
want
to
enhance
on
that
discussion.
F
Well,
right
now,
we're
specifically
focused
on
container
images
and
addressing
that
first
versus
file
data
because
of
the
microservice
viewpoint
that
we're
taking.
F
So
when
we
look
at
gathering
information
right
now,
we're
trying
to
gather
information
about
the
image,
but
also
what's
in
the
image
where
we
are
looking
at
cves
and
licenses
at
this
point
and
where
the
spdf
x
is
coming
into
play,
but
eventually
we'll
get
into
tracking
at
the
file
level
of
what
is
in
the
container
and
then,
if
you're,
talking
about
like
a
regular
we're
going
to
do
a
war
file
deployment.
F
So
it's
on
our
our
our
a
container
perspective.
First.
H
Okay,
then
yeah,
I
look
forward
to
anything
that
could
be
contributed
by
orthodox
team
as
well
when
they
have
time.
Okay,
so
steve,
I
will
probably
you
know
ping
you
on
slack
as
well.
I
need
to
collect
my
notes
and
then,
if
anyone
else
wants
to
take
part
in
this,
obviously
please
start
following
the
discussion
and
even
better
go
in
there
and
just
add
your
thoughts
on
this,
and
we
can
now
get
this
going
wild.
We
have
kate's,
while
kate
still
remembers
us.
H
E
Oh,
are
you
talking
about?
Oh,
that
was
me
sorry.
Okay,
here
is
the
the
cncf
application
delivery.
Sig
has
been
working
on
a
generic
operator
white
paper.
It
is
pretty
thorough.
I
read
through
it
yesterday.
It's
actually,
I
think
it's
they
did
a
great
job
of
building
it
out,
and
it's
really
just
talking
about
operators
in
general,
not
in
the
terms
of
a
git
ops
operator,
but
how
operators
in
general
should
look.
I
just
bring
it
up
because
it
could
be
something
that
we
want
to
reference.
It
is
almost
a
integration.
E
You
know
how
you
can
use
an
operator
to
do
anything
you
choose
to
do,
but
it
has
some
interoperability
overtones
and
it
may
be
something
that
the
events
sig
might
want
to
look
at
as
well
around
a
listener.
E
H
Thank
you,
yeah
I've
seen
this
doc
as
well.
I
forgot
me
about
it
thanks
for
highlighting
that.
Actually,
since
you
mentioned
tracy
up,
tillery
is
doing
most
of
like
interesting
stuff.
I
don't
know
if
anyone
has
seen
this
potato
head
or
something
like
it.
E
Yeah
I
I've
looked
at
that
it's
kind
of
fun.
C
E
How
do
I
describe
it?
It's
really
a
you
know
how
to
put
your
manage
infrastructure
components.
H
And
the
thing
that
got
my
attention
is
like
they
talk
about
like
multiple
different,
like
cd
technologies
like
flux,
argo,
cd,
captain
and
so
on.
It's
like
it
looks
like
fun
to
play
with,
and
it
also
you
know.
Perhaps
we
can.
You
know
talk
to
them
again.
I
think
we
had
some
participation
from
captain
folks
or
others
from
abdillary
in
rc,
but
I
don't
see
them
here
today
during
today's
meeting,
but
this
repo
or
what
they
do.
There
looks
interesting
as
well.
H
H
H
Thanks
tracy,
before
we
move
to
unders,
anyone
wants
to
bring
up
a
quick
short
topic.
D
Okay,
let's
see
here.
A
Okay,
so
there
we
go
okay,
first
of
all,
I'm
glad
to
be
here
happy.
Can
you
see
my
screen
now?
Is
it
full
screen.
A
Okay,
great
okay,
so,
first
of
all,
I'm
anders-
and
I
work
as
a
developer
advocate
for
styra,
which
is
the
the
inventors
of
open
policy
agents,
and
so
that
would
be
the
topic
for
my
talk
here
and
policy-based
access
control
was
the
topic,
but
I've
tried
to
kind
of
modify
this
a
bit
to
fit
into
more
of
the
ci
cd
context,
which
I,
which
I
heard
you
you
are
into
so
the
challenge
here.
A
What's
or
what's
the
problem
we're
trying
to
solve
with
open
policy
agents
is
really
to
manage
policy
in
increasingly
distributed
complex
and
heterogeneous
systems,
so
the
cloud-native
landscape,
just
one
thing
that
we
can
probably
all
agree
on.
It's
it's
complex.
There
are
a
lot
of
technologies
for
applications.
A
There
are
all
these
cloud
vendors
and
there's
all
these
different
data
sources,
and
they
all
have
their
own
way
of
dealing
with
policy,
and
when
I
say
policy,
it's
it
most
often
pertains
to
authorization
like
who
can
do
what
in
the
system,
but
it
could
also
be
other
forms
of
organizational
policies
like
what
type
of
resources
can
we
deploy
to
this
or
that
cluster
and
under
what
conditions.
A
So
the
goal
of
oppa
is
really
to
unify
policy
enforcement
across
the
the
whole
cloud
native
stack,
and
even
if
we
say
the
cloud
native
stack,
oppa
obviously
works
very
well
for
older,
older
type
of
systems
as
well.
A
A
A
A
keyword
here
is
decoupling,
oppa
decouples
policy
from
application
logic,
so
it
what
it
means
is
pretty
much
how
you
would
decouple
storage
from
your
application
logic
and
and
move
that
into
a
database
in
the
same
way,
oppa
decouples
policy
and
moved,
and
so
you
move
that
out
from
your
application
and
into
oppa.
So
ideally,
your
application
won't
even
know
that
there's
an
admin
user
or
that
there
are
certain
roles
or
permissions,
but
that
part
is
delegated
over
to
oppa.
A
A
So
that's
still
up
to
the
application
to
do,
and
that
is
of
course
highly
context
specific,
whether
it's
to
serve,
I
don't
know
a
403
response
code
or
whether
it
is
to
to
send
us
a
message
to
some
slack
chat
or
maybe
inform
the
authorities,
that's
highly
context,
specific
and
and
hence
why
oppa
does
not
do
enforcement.
A
That
would
be
very
hard
to
do
in
in
all
these.
In
all
these
different
tech
stacks,
so
in
order
to
to
be
this
kind
of
unifying
force,
policies
are
written
in
a
declarative
language
called
rigo,
which
is
a
integral
part
of
oppa
and
some
of
the
most
common
use
cases
for
oppa.
It
include
kubernetes
admission
control,
which
I'll
touch
on
a
bit
more
later:
microservice
or
app
authorization,
infrastructure
policies,
data
source,
filtering
and
cicd
pipeline
policies.
A
I
think
these
numbers
are
a
bit
old
by
now,
but
still
oppa
is
a
vibrant,
open
source
community.
We
have
160
contributors
from,
I
think,
50
or
so
different
companies
50
integrations
around
5000,
github
stars,
4000,
slack
users
and
so
on.
The
numbers
are,
aren't
that
important,
but
it's
it's
a
vibrant,
open
source
community
and
the
ecosystem
includes
not
just
oppa
but
also
many
sub-projects
and
and
external
products
such
as
conf
test
for
configuration
testing,
which
I
think
is
we'll
look
into
a
bit
later.
A
It's
as
it's
it's
very
relevant
in
in
the
ci
cd
context,
there's
gatekeeper
for
doing
kubernetes,
admission
control,
there's
various
editor
integrations
for
bs
code
and
intellij.
A
And
if
that
wasn't
enough
to
convince
you,
I
think
this
quote
from
kelsey
hightower
gonna
summarize
this
oppa
perfectly.
So
the
open
policy
agent
project
is
super
dope.
I
finally
have
a
framework
that
helps
me
translate
written
security
policies
into
executable
code
for
every
layer
of
the
stack,
so
that's
kind
of
that's
spot
on
that's
exactly
what
we're
trying
to
achieve.
A
So
how
do
we
achieve
that,
and
how
can
we
work
with
all
these
with
all
these
technologies?
That,
of
course,
were
those
those
technologies
were
written
entirely
without
open
mind.
So
it's
so.
How
can
we?
A
How
do
how
does
opa
fit
in
and
the
secret
here
is-
is
basically
the
policy
decision
model
where
you
have
a
service
and
when
I
say
service,
this
could
really
be
anything,
it's
anything
who
accepts
requests
and
that
could,
of
course
be
a
a
microservice,
an
http
api,
a
database
kafka
or
or
what
have
you
anything
that
services
requests
and,
and
of
course,
most
most
software
components
does
that
in
some
form.
A
So
when
is
when
a
request
is
received
in
in
our
service,
what
it
then
does
it
reaches
out
to
oppa,
and
that's
also
another
request.
It's
just
http
oppa
is
normally
run
as
a
server,
so
that
service
reaches
out
to
oppa,
and
it
asks
based
on
on
the
policy.
You
have
and
the
data
you
have
and
as
part
of
the
query,
you
can
also
include
more
data.
Maybe
you
have
some
information
on.
A
Where
is
this
request
heading
like
for
what
path
and
and
who
is
the
user,
making
this
request
so
based
on
the
policy
you
have
based
on
the
data
that
you
have,
and
maybe
some
data
that
I
provide?
Should
this?
Should
this
request
be
allowed
or
denied?
A
That
would
be
a
very
common
scenario
and
the
input
provided
to
oppa
is
just
json
and
the
output,
like
the
decision,
oppa
returns,
is
also
just
json,
so
any
service,
that's
capable
of
speaking
http
and
json-
can
thus
integrate
well
with
oppa,
so
that's
kind
of
how
how
we
can
work
with
so
many
different
vendors
technologies
and,
and
so
as
for
deployment
oppa
is
a
self-contained
binary.
So
it's
a
single
file.
A
A
Kubernetes
has
this
concept
of
sidecar
containers,
where
you
run
at
where
you
run
opa
as
a
container
inside
the
same
pod
as
your
application,
and
the
purpose
of
this
is,
of
course,
to
minimize
latency,
because
since
each
request
entering
your
application
is
going
to
consult
oppa,
you
you'd
want
that
to
go
to
be
as
fast
as
possible,
so
having
open
run
on
the
other
end
of
the
data
center
or
even
in
some
other
part
of
the
world.
A
That's
not
gonna
work
for
for
most
applications
and
again
the
way
most
applications
communicate
with
oppa
is
through
the
rest.
Api
I'll
show
some
alternative
ways
later.
There's
also
a
go
library
available.
If
you,
if
your
application
is
written
in,
go
oppa
is
also
written
and
go
so
so
that
makes
it
easy
to
integrate.
A
In
that
way,
there's
for
envoy
and
istio,
based,
like
service
mesh,
meshes
there's
a
ready-made
kind
of
version
of
oppa
to
to
work
with
that
scenario.
And,
finally,
you
can
also
compile
policies
to
to
web
assemblies.
So
you
can.
You
can
run
oppa
in
that
in
pretty
much
any
context
where
webassembly
runs
so
rego
is
a
declarative,
high-level
policy
language
which
is
used
by
oppa
and
with
declarative.
We
just
mean
that
sort
of
like
sql,
rather
than
saying
exactly
how
you
want
something
done.
A
You
just
say
what
you
want
done:
an
open
policy
just
like
a
real
world
policy.
I
guess
consists
of
a
number
of
rules.
That's
pretty
much
what
a
policy,
the
definition
of
a
policy
and
a
rule
in
oppa
can
return
true
or
false
a
boolean
rule.
That's
that's
very
common
in
for
for
authorization.
You
just
want
to
know.
Is
this
allowed
or
not,
but
it's
not
limited
to
that
again.
Oppa
returns
json,
so
any
any
data
type
or
value
available
in
json
is
also
available
for
your
opa.
A
A
Oppa
includes
150
plus
built-in
functions
and
it's
not
a
general
purpose,
programming
language,
so
these
functions
are
kind
of
adapted
to
the
policy
or
to
for
policies
pretty
much
so
things
like
dealing
with
json
web
tokens
date
and
time
ip
address
ranges
and
things
that
make
sense
from
a
policy
perspective
and
oppa
ships
with
a
unit
testing
framework.
So
you
can
also
like,
after
you
have
written
your
policies,
you
can
also
test
them
in
isolation,
so
kind
of
build
confidence
in
that
these
policies
do
what
you
intend.
A
It's
a
very
well
documented
project.
I
think
it's
I'm
obviously
a
little
biased,
but
I
think
it's
one
of
the
better
documented
open
source
projects
and
for
trying
hope
out
without
even
downloading
anything,
there's
the
rego
playground,
which
is
an
interactive
playground
where
you
can
try
policy
change,
our
tweaks
and
parameters
in
the
input
and
and
then
evaluate
the
policy
and
see
what
happens
and
that's
I'll
I'll.
Give
you
a
demo
on
that
in
a
few
minutes.
A
But
before
I
do
that,
we've
talked
about
policy
and
and
again
I
I
I
think
I
mentioned
that
there
are
the
two
things
that
oppa
takes
into
account
when
it
makes
its
decisions,
it's
policy,
but
it
is
also
data,
so
this
data
could
either
be
provided
as
part
of
the
request
as
part
of
the
query
input,
and
we
call
that
input
data,
but
it
could
also
be
provided
asynchronously
to
opa,
either
by
pushing
data
into
oppa
or
pulling
or
have
a
oppa
pulling
data.
We
call
those
data
bundles.
A
A
Finally,
there's
also
an
http
send
like
an
http
client
that
you
can
use
from
inside
of
your
policies
to
to
reach
out
to
other
endpoints
and
and
fetch
data
at
policy
evaluation
time.
That's
obviously
not
ideal.
So
if
you
can
avoid
that,
you
probably
should
because
again
we
want
to
minimize
latency.
We
want
these
decisions
to
be
as
fast
as
possible,
but
in
some
cases
we
really
need
the
data
to
be
up
to
date
or
we
need
the
data
we
need
to
know
now
like.
A
What's
the
what's
the
status
right
now
in
some
at
some
remote
end
point
so
in
that
case,
it's
there
for
you,
I
think
I
managed
the
bundle
api
already
and
these
management
apis
they
really.
A
This
is
not
where
you'd
start
your
oppa
journey,
but
this
is
once
you
have
10
20,
maybe
50
or
hundreds
of
opus
you're,
eventually
going
to
need
some.
Some
form
of
management
and
oppa
offers
a
number
of
management
advice
for
for
that
purpose,
so
the
bundle
api
I
mentioned
before
it's
a
way
for
oppa
to
to
go
out
and
retrieve
policy
and
data
from
some
remote
endpoint.
A
The
decision
log
api
is
is
super
important.
I
think
it's
it's
opus
way
to
to
actually
report
back
on
the
decisions
it
took,
so
any
decision
oppa
ever
takes
is
logged
and-
and
I
think
that's
also
in
larger
organizations
where
you
have
this
like
super
diverse
environment-
and
I
know
a
previous
employer-
I
was
at
we
had
eight
or
nine
programming
languages
running
in
in
our
microservice
environment
and
obviously
everyone
did
logging
their
own
way.
A
So
it
was
even
even
though
we
know
what
to
search
for
it
was
really
hard
to
find
things
like
authorization
decisions
if,
if
those
were
even
log,
so
oppa
unifies
this
as
well
and
there's
a
status
api
not
as
important
but
just
a
way
for
oppa
to
kind
of
report
back
that
it's
good
and
healthy
discovery,
api
for
for
fetching
config
from
remote
endpoints
as
well.
A
Okay.
So
at
this
point
I'm
gonna
give
you
all
a
quick
demo
of
of
rego
and
and
how
that
works.
I'm
gonna
exit
the
presentation
mode
and
show
you
the
rego
playground
and
how
that
looks
so
to
our
left.
Here
we
have
an
empty
policy.
A
All
policies
belong
to
a
package
or
like
a
sort
of
like
a
namespace
or
module
in
in
other
languages.
In
this
case,
we
just
call
it
play
and
to
our
to
a
right
here
we
have
input
or
kind
of
simulate
input,
since
there's
really
no
real
request
going
on
here.
So
in
this
case,
I
prepared
some
and
I
I
just
made
an
input
where
sort
of
what
you
could
expect,
maybe
from
a
microservice.
A
A
So
what
a
policy
then
would
look
like
in
rego.
A
Allow
itself
doesn't
mean
anything
to
oppa,
it's
not
a
keyword
or
anything,
but
the
name
of
the
rules
are
totally
arbitrary
and
and
of
course,
this
is
also
to
to
enable
this
kind
of
general
purpose,
so
so
allow
might
make
sense
in
authorization
context,
but
not
in
others,
but
in
this
case
we
called
it
rule
allow
and-
and
in
this
case
and
the
rule
name
is
followed
by
a
body
and
it's
kind
of
inverted
to
how
you'd
work
with
kind
of,
if
or
conditional
things
in
other
programming
languages.
A
A
So
if
we,
for
example,
say
input
now
we
reference
something
in
the
input
we
say
request
and
we
see
method
it
is
equal
to
get
and
if
we
evaluate
this
now,
we'd
see
that
the
allow
rule
is
true,
because
this
condition
was
true.
So
it's
how
you,
how
do
you
normally
write
this
in?
I
don't
know
javascript
or
something.
It's
probably
something
like
this.
If
input
is
equal
to
get
and
then
after
each
line,
each
condition
is
handed
together
with
the
next
line.
A
A
So
if
we
want
to
change
that,
we
could
just
say
that
by
default,
allow
should
be
false,
and
we
evaluate
this
now
and
now
we
see
okay.
Instead
of
of
getting
nothing
back.
We
we
get
at
least
to
know
that
this
was
not
allowed,
and
if
I
change
this
back
you'll
see
that
once
again
it
it
should
be
working.
A
F
A
Yeah
that
was
you're
one
step
ahead
of
me.
That
was
exactly
what
where
I
was
getting
to
so
the
way
you
do
that
is
you
actually
just
add
another
alarm.
So
now
we
say
that
this
should
be
true.
If
somebody
tries
to
read
from
the
user's
end
point,
we
should
allow
that
we
can
also
say
that
the
request
method
is
good
and
we
just
copy
that,
because
that
should
be
the
same
so
and
we
evaluate
so.
A
So
when
you
evaluate
you'll
see
which
one
of
these
rules
evaluated
to
true-
and
in
this
case
of
course
it's
it's
the
put
rule
so
so
this
would
be
a
super
simple
example
of
how
to
offer
policies
in
rego
and
of
course,
there's
there's
a
lot
more
to
it.
All
these
built-in
functions
there's
many
language
constructs
and
so
on
and
so
forth.
But
I
I
just
wanted
to
kind
of
provide
a
basic
idea
of
what
a
regal
policy
looked
like
and
and
how
how
a
policy
evaluation
works.
A
So
with
that
in
mind,
I'll
I'll,
just
I
I
did
some
special
slides
here
for
for
for
you
for
this
context,
because
in
cicd
deployments
there
are
some
things
to
consider.
And
of
course
you
guys
are
are
the
experts
here.
A
So
so
you
tell
me
if,
if
I'm
wrong
here,
but
one
thing
is
that
in
this
this
context,
when
you,
when
you
kind
of,
have
a
build
or
a
deployment,
you
might
not
want
to
have
an
http
server
like
oppa
running
at
all
times,
because
many
of
these
build
tasks
and
so
on.
A
They
just
spin
up
something,
and
then
they
do
what
they're
meant
to
do
and
then
they
kind
of
just
then
they
shut
down
and
of
course
you
could
still
have
oppa
running
somewhere
else
and
and
then
query
that,
but
there
are
fortunately
other
ways
to
evaluate
policy.
Oppa
also
has
a
command
called
oppa
eval,
which
you
can
use
to
to
do
like
one-off
evaluations
of
of
data
and
policies.
So
you
say:
here's
my
policy,
here's
some
data.
A
What
what
would
you
decide
and
and
then
oppa
just
provides
an
response
to
that
and
shuts
down
pretty
much?
I
mentioned
in
passing
before
one
of
the
subprojects
of
oppa
is,
is
named
conf
test
and,
and
they
kind
of
take
oppai
val
to
to
the
next
level
where,
where
you
build
a
test
suite,
and
you
run
that
policy
based
tests
on
data
files,
so
configuration
files,
deployment,
resources
or
or
what
have
you,
and
so
you.
A
You
normally
run
that
as
part
of
on
your
ci
cd
pipe,
I
mean
say
like
if
you
check
in
new
configuration
files
or
you
make
changes
to
them,
we're
going
to
run
these
tests
on
all
those
files
and
if
you
violate
something
in
our
policy,
we're
we're
gonna
fail
this
build
and
another
a
nice
thing
with
confessed
is
so
oppa
itself,
virtually
json
and
jamal,
and
the
contest
kind
of
extends
on
that
to
to
work
with
many
other
formats,
which
I
think
is
common
in
in.
In
this
context,.
A
So
some
specific
ci
cd
use
cases
which
or
at
least
the
most
common
one
common
ones
for
oppa,
I
don't
say,
they're
the
most
common
ones
for
anything,
but
for
oppa.
I
think
these
are
probably
the
most
common
ones.
A
First,
it's
validation,
yeah
and
then
there's
triggering,
and
then
this
kubernetes
admission
control-
and
I
think
by
far
the
most
common
one
is
is
probably
to
do.
Validation
and
and
validation
is,
is
just
to
either
scan
some
resources,
scan
configuration
or
or
make
any
any
form
of
policy
decision
based
on
on
whatever
data
is
available
and
of
course
it
could
be
time-based.
Data
like
you
cannot
do
pro
prod
deploys
on
black
friday
or
you
can't
do
it.
A
If
no
one
is
on
call,
it
could
also
entail
that
for
production
deployments
we
need
to
find
there
need
to
be
a
sign
off
for
from
somebody
else,
so
that
that
would
be
deployment
policies,
but,
of
course,
developers
demand
to
know
more
increasingly
I'd
say
like
they
want
to
know
as
early
as
possible,
if,
if
they
did
something
wrong,
so
oppa
is
also
can
also
run
like
confidence.
You
can
obviously
run
that
on
on
your
local
machine.
A
You
can
install
it
as
a
pre-merge
hook
or
pre-commit
hook,
and
so
you'd
have
like
on
on
each
commit.
You
you'd
run
in
to
make
sure
that
you're
not
committing
in
something
that
violates
policy
and
for
terraform
and
other
infrastructure
as
code
solutions,
oppa
is
also
available,
and
finally,
we
we
already
mentioned
conf
test
and
how
that
works.
A
So
you
can,
you
can
write
policies
to
make
sure
that
even
docker
files
or
npm
files,
and
so
on,
follow
certain
guidelines
and
policy,
triggering
that's
a
more
advanced
use
case
where
you
actually
create
workflows
or
you
have
opa
itself,
create
workflows.
Workflow
specs.
Remember
when
I
told
you
that
opel
open
decisions
are
are
json
and
or
jaml,
so
when
you
think
of
it,
like
workflow
specs,
are
also
json
in
general,
in
95
of
all
cases,
that's
kind
of
how
we,
how
we
work
with
the
declarative,
build
and
deployment
pipelines.
A
So,
given
that
you
load
context
into
oppa
and
this
context
could
be
taken
from
aws,
your
cloud
provider,
github
data
data
from
your
deployment
environments
and
then
you
could,
then
you
could
ask
opa,
queries
and
and
have
not
oppa
just
returned
yes
or
no,
but
actually
return
an
entire
like
workflows
back.
A
A
Finally,
there's
the
kubernetes
admission
controller
and-
and
this
isn't
this
isn't
specific
to
ci
cd,
but
given
how
how
many
of
these
ci
cd
systems
that
run
inside
of
kubernetes
and
the
kind
of
our
kubernetes
native,
I
think
it's
still
it's
still
an
interesting
angle
to
cover
so
the
kubernetes
and
mission
controllers.
A
A
So
if
you
say
I
want
to
deploy
this
application
and
you
say,
cube
cdl
apply
and
then
you
provide
some
resources.
Then
you
can
provide
a
policy
that
says
unless
there
are
there's
a
label
for
marking
which
team
deploy
this.
It's
not
going
to
go
we're
going
to
deny
that
there
needs
to
be
a
cost
center
label
or
there
needs
to
be
some
annotation
or
each
each
application
must
have
at
least
one
replica
or
two
replicas
or
or
else
we
don't
consider
that
safe.
A
So
things
like
that,
that's
what
we
call
policy
guard
rails
where
we
can.
We
can
have
some
assurance
in
knowing
that
not
even
if
we
can
give
kind
of
the
keys
to
our
developers,
so
they
can
deploy
at
their
own
will
it
doesn't
mean
that
anything
goes,
there's
also
the
mutating
admission
controller,
which
is
not
as
commonly
used.
But
it's
it's
also
a
pretty
interesting
feature
of
the
kubernetes
api.
A
Where
you
don't
where
you
don't
just
say
this
goes
or
doesn't,
but
you
actually
mutate
a
resource
on
its
way
to
to
be
created
or
updated,
and
there
are
some
good
use
cases
for
it.
A
But
it's
also
rather
I'd
say
it's
it's
it's
a
it's
a
little
risky
because
essentially
the
the
developer
or
whoever
deploys
a
resource
they
have
no
way
of
knowing
that
you
actually
mutated
the
resource
on
its
way
in
so
what
they
see
in
their
configuration
file
or
in
their
deployment
spec
might
not
then
correspond
to
what
was
actually
deployed
so
that
it's
just
it's
a
bit
of
a
yeah.
It's
there
are
useful
applications
for
this,
but
I
think
be
careful
with
with
that.
A
A
So
you
can
say
that
sure
you
can
deploy
tasks
or
pipelines
or
or
whatever,
but
it's
they're
all
gonna
pass
our
admission
controller
and
our
policies,
so
you
can
only
deploy
tasks
of
this
type
or
they
can't
be
too
complex
or
whatever
policy
makes
sense
for
for
for
you
yeah
just.
A
This
was
just
a
quick
illustration
of
how
kind
of
oppa
kind
of
jacks
into
these
modules
as
a
resource
base
on
on
its
way
to
be
persisted
in
etsy,
which
is
the
database
kind
of
behind
kubernetes.
So,
first,
the
request
is
authenticated
we
find
out.
Who
is
who
is
trying
to
do
this
and
if
that's
allowed
or
if
that
works,
we
pass
that
on
to
authorization,
and
if
the
request
is
authorized,
then
we
hit
these
admission
controllers.
So
first
is
the
mutating
admission
controller
and
followed
by
the
validating
admission
controller.
A
A
Okay,
so
that
was
pretty
much
it
on
oppa
rego,
quick
introduction.
I
think
I
have
a
few
minutes
left,
so
I
I
normally
include
this
for
developers
who
are
curious
about
like
we're
okay.
So
this
this
sounds
good
like.
Where
do
we
start,
and
I
normally
suggest
just
start
small,
even
if
even
if
oppa
is
can
can
even
if
it's
general
purpose-
and
you
can
use
it
like
in
all
these
and
all
these
spaces.
A
They
might
not
just
be
explicit,
but
they're
often
kind
of
tangled
into
code
or
in
in
other
contexts,
so
don't
really
try
and
identify
which
policies
you
have
already,
rather
than
just
try
and
write
new
policy,
and
once
you
once
you
have
identified
it
a
couple
of
policies,
then
you
can
start
to
delegate
some
of
those
responsibilities
to
oppa
and
again
you
don't
need
to
rewrite
your
whole
application
or
your
ci
cd
pipeline,
but
you
could
start
with
something
small,
maybe
a
single
endpoint,
maybe
a
role
or
something
like
that.
A
Deploy
that
and
you
build
experience
from
that
from
there
and
once
you
start
to
scale
up,
you
can
look
into
these
management
features.
I
mentioned,
like
logging,
bundle,
servers
and
so
on,
there's
the
star
academy,
which
is
an
excellent
resource
and
of
tutorials
or
video
tutorials
and
quiz
style
tests.
A
Also,
since
I'm
from
styra,
I've
mentioned
the
styra
das,
it's
the
declarative
authorizations
service,
which
is
our
commercial
control
plane
and
a
good
place
to
start.
If
you'd
like
to
know
more
or
like
to
continue,
the
discussion
is
the
oppa
slack,
and
with
that
I
say,
thank
you
and
if
there,
after
any
questions,
I'd
be
happy
to
answer
them.
F
Nice
job,
so
I
have
one
quick
question:
if
I
wanted
to
put
a
policy
check
into
my
jenkins
pipeline,
where
do
I
get
started?
You
know
what
do
I
need
to
install,
and
you
know
I
understand
you
know
from
your
example
what
I
need
to
write
from
the
policy
example.
But
what
do
I
actually
have
to
like
install
and
get
going
to
be
able
to
do
that
policy
check.
H
I
have
a
question
about
like,
for
example,
you
have
canary
deployment
and
then
you
are
collecting
metrics
via
promote
use.
Can
you
like
enforce
policies
based
on
what
you
scrap
from
promoters,
for
example,.
A
Oh
yeah
sure,
so
anything,
that's
anything.
That's
data
like
it
that
can
be
represented
as
json
or
jamo.
That's
that's
a
fair
target
to
to
use,
and
we
have
seen
policies
like
people
who
integrate
with
things
like
google
calendar
api
to
see.
If,
if
somebody
is
on
call
or
if
there's,
if
there
are
some
notable
events
that
that
should
be
taken
into
account
so
pretty
much
any
api
is
a
good
data
source.
If
it's.
F
Oh
one,
maybe
one
one
last
question:
where
are
the
policies
the
regal
stored?
Are
those
go
in
a
git
repository,
or
do
you
load
them
into
the
database
and
like
how
are
they
versioned.
A
Yeah,
that's
that's
a
good
question
and-
and
I
think
normally
yeah-
they
are
git
version.
So
one
of
the
benefits
of
of
of
clearly
working
with
policy
as
code
is
that
it's
not
just
code,
but
you
can
also
adopt
all
these
good
best
practices
that
you
have
when
you're
working
with
any
other
type
of
code.
So
your
policies
are
version
controlled.
A
You
work
with
pull
requests
and
code
review,
linters,
testers
and
so
on,
so
yeah
normally
you'd
store
policies
in
git
and
and
then
at
when
you
deploy
or
like
policy
deployment.
Then
you
package
that
into
one
of
these
bundles
or
so,
which
is
then
read
by
oppa.