►
From YouTube: Kubernetes Policy, Governance...- Jim Bugwadia, Anca Sailer, Jayashree Ramanathan, Robert Ficcaglia
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Kubernetes Policy, Governance, And Compliance: A WG Policy Update - Jim Bugwadia, Nirmata; Anca Sailer, IBM Research; Jayashree Ramanathan, Red Hat; Robert Ficcaglia, Sunstone Secure
Speakers: Jim Bugwadia, Jayashree Ramanathan, Anca Sailer, Robert Ficcaglia
Kubernetes policies can help simplify management particularly of multiple clusters, scale Day 2 operations, and automate security and resiliency and software engineering concerns, thereby optimizing cost of operations. Policies also serve as the building block to help enforce multi-cluster governance and deliver continuous compliance and readiness for audits. The Kubernetes Policy Working Group (WG) focuses on defining overall architecture recommendations and guidance on both current policy related implementations as well as future policy related proposals in Kubernetes. Join this session to find out about the working groups current and upcoming projects, and also learn how you can get involved to learn and contribute.
A
Are
we
we're
good?
Okay,
all
right?
Well,
congratulations.
You
made
it
to
the
policy
work
group
update.
If
you
I
say!
Congratulations!
If
you
are
here
to
learn
more
about
kubernetes
policy
and
compliance,
it
means
that
you
probably
have
achieved
Elite
status
in
your
career,
where
you
can
tell
people
what
to
do
and
if
they
don't
listen,
you
can
write
code
that
forces
them
to
do
it
so
welcome
I,
guess
we'll
do
a
quick
round
of
introductions.
B
C
D
A
So
what
do
we
do
in
the
policy
work
group?
So
our
Charter
initially
was
to
help
Define
the
architecture,
the
designs,
the
nomenclature,
if
you
will
for
policy
and
kubernetes
and
and
of
course,
supporting
the
ecosystem
and
cncf
and
I-
think
it's
Martin
Fowler,
who
once
pointed
out
that
there
were
really
only
two
hard
problems
in
software
naming
things
and
something
to
do
with.
Caching,
anyway,
the
jokes
don't
get
better,
but
we
have
been
busy
trying
to
define
a
common
output
for
policy
reports.
A
We've
defined
a
white
paper
that
lays
out
policy
architecture
that
we'll
be
speaking
to
shortly
and
we're
hoping
to
invite
the
community
in
the
vendor
Community
the
projects,
the
sub
projects,
to
discuss
how
policy
framework
can
fit
together
and
support
the
different
services
and
in
a
way
that
meets
compliance,
regulatory
requirements,
but
also
in
general.
No
knowing
how
your
system
is
going
to
run
in
a
declared
State
and
making
sure
that
declared
State
matches
the
actual
state.
A
One
of
our
efforts
to
date
has
been
to
align
this
with
other
industry
groups
and
so
that
the
the
policy
construction
policy
enforcement
can
be
reused
in
many
different
Industries,
and
one
of
those
efforts
is
a
project
sponsored
by
nist
in
the
US
called
oscow
and
we'll
talk
a
little
bit
more,
how
our
efforts
have
aligned
with
that
oscow
schema
and
how
it
helps
enforce
policy
and
distribute
the
results
of
those
policies
across
systems.
So
with
that
I'll
hand
it
over
to
Jim.
B
All
right,
thank
you,
Robert
yeah,
so
just
one
one
quick
thing
I
want
to
add
like
within
the
cncf
there's
various
types
of
organizations
right,
so
you
have
technical
advisory
groups
that
span
multiple
projects.
You
have
you
know
the
special
interest
groups
are
sigs
that
are
focused
on
particular
areas
within
a
project
like
kubernetes,
and
then
you
have
working
groups
that
are
also
cross-functional
and
Report
into
multiple
segs
right.
So
from
that
landscape
perspective,
like
Robert
explained,
our
Charter
is
to
figure
out
for
kubernetes
policy
and
governance.
What
exactly
does
that
mean?
What
is
needed?
B
How
do
we
align
across
you
know
all
different
concerns
within
kubernetes,
so
one
of
the
things
we
did
about
a
year
or
so
ago
is
we
wanted
to
publish
a
paper
that
talks
about
what
kubernetes
policy
management
is
and
we
use
reference
architectures
from
the
industry
from
authorization
there's
the
xactimal
architecture
that
we
leverage
and
the
to
define
the
terminology
here
within
kubernetes
or
within
a
cloud
native
system
itself.
You
have
multiple
policy
enforcement
points
and
of
course
all
of
us
are
running.
You
know
if
you're
running
kubernetes,
you
have
multiple
clusters.
B
So
that's
where
you
would
enforce
policies
in
kubernetes,
you
have
extensible
admission
controllers,
which
lets
policy
engines
like
caverno
and
opa
gatekeeper.
You
know
function
and
add
customizable
policies
there.
So,
given
these
policy,
you
know
enforcement
points
and
keep
in
mind,
you
might
want
to
enforce
policies
in
your
CI
CD
pipeline.
Also,
at
you
know,
runtime,
as
well
as
at
admission
controls.
B
Then
you
need
a
policy
Administration
point
which
is
managing
policies
across
your
fleets
of
clusters
or
just
you
know,
just
the
different
environments
like
staging
Dev
test,
QA
Etc
and
finally,
you
have
you
know
you
want
to
enrich
policies
with
information.
This
could
be
from
within
the
cluster
like
through
the
API.
Server
could
be
from
external
data,
because
policy
decisions
have
to
be
made
very
fast,
typically
in
a
couple
of
seconds
at
admission
controls,
so
you
need
to
bring
in
the
right
data
to
policies
anyway.
So
the
paper
is
available.
B
You
know,
and
we
this
is
a
live
document.
It's
managed
in
our
GitHub
repo,
so
feel.
Please
do
give
it
a
read.
Give
you
know
post
your
feedback.
We
are
looking
at
evolving
the
paper
and
we
will
publish
a
V2
fairly
soon
right
with
some
learnings
and
as
kubernetes
evolves
as
well.
Another
aspect
I
want
to
quickly
touch
on,
and
this
is
a
project
we
completed
and
it's
ongoing
as
well
is
to
define
a
custom
resource
definition.
So,
as
most
of
you
probably
know,
kubernetes
is
designed
to
be
extensible.
B
It
allows
you
to
you,
know
using
open,
API,
V3,
schema,
Define,
custom
resources
and
those
resources
act,
like
you
know,
native
you
know,
constructs
like
pods
and
worker
nodes
Etc,
which
can
be
managed
through
the
kubernetes
API.
So
we
added
a
custom
resource
definition
to
collect
policy
results
and
format
them
into
reports
which
could
be
you
know
extracted
through
the
kubernetes
apis.
B
The
benefit
here
was
to
standardize
the
way
kubernetes
policy
results
are
retrieved,
because
if
you
look
at
kubernetes
security
there's
a
broader
set
of
concerns
right,
you
have
runtime
security
at
one
end
of
the
spectrum,
you
have,
you
know,
configuration
security
which
can
be
applied
again
at
admission
controls
in
your
CI
CD
pipelines.
You
have
things
like
you
want
to
verify
signatures
and
attestations
for
software
supply
chain
security.
You
have
other
things
like
you
might
want
to
do
vulnerability,
management
and
periodically
check
if
each
image
has
an
up-to-date.
B
You
know
vulnerability
report
software
buildup
materials
is
also
becoming
very
important,
so
all
of
these
concerns
have
to
come
together
and,
typically,
what
we
saw
previously
is
every
policy
engine
had
a
different
way
of
reporting
results.
So
standardizing
this
allowed.
You
know
the
any
operator
to
retrieve
these
reports
through
the
kubernetes
apis
itself
in
a
very
standard
format.
So
this
again
is
something
that
we're
maintaining
within
the
working
group.
B
So
the
reporting
is
done
by
policy
reporter,
which
is
a
sub-project
of
caverna,
and
the
translation
is,
you
know,
a
contribution
from
an
IBM
team
which
takes
the
standard
report
in
the
policy
for
a
crd
format
and
converts
it
into
oscow.
So
lots
of
interesting
things
coming
up
and
and
that's
the
benefit
we
see
of
standardizing
year,
which
allows
other
layers
of
tools
to
be
built
in
this
chain.
So
those
are
two
of
the
you
know.
B
C
Thank
you,
Jim
yeah,
so
as
Jim
and
Robert
outlined,
the
focus
of
the
work
group
so
far
has
been
to
Define
overall
architecture
for
policy
management
and
kind
of
also
standards
of
how
the
various
policy
engines
can
report
the
results,
because
you
know
we
can
all
agree
that
there's
not
going
to
be
a
single
policy
language
out
on
the
planet
right.
There
are
going
to
be
multiple
and
we
have
to
deal
with
that.
C
So
then,
the
what
we
are
focusing
on
right
now
is:
why
do
customers
do
policy
management?
They
do
it
because
it
is
a.
It
is
a
means
to
an
end,
and
so
what
is
the
end
goal
right?
So
the
various
end
goals,
one
could
be.
You
know
maintaining
continuous
security,
Readiness
and
audit
Readiness.
Another
goal
is
to
comply
to
Regulatory
Compliance
standards.
C
A
third
goal
is
to
reduce
the
operational
cost
of
operating
the
environment
right
because,
as
people
know
right
what
teams
application
teams
just
want
to
deploy
their
workloads
and
get
their
applications
going
so
security
compliance
becomes
like
afterthought,
and
so
the
more
we
can
make
it
easy
for
them
to
accomplish
that
by
minimizing
the
operational
cost.
I
think
that's
important.
C
So
that's
where
governance
comes
into
play,
so
the
two
Focus
areas
that
we
are
focusing
on
next
are
one
is
to
produce
a
draft
paper
on
kubernetes
governance,
because
the
term
governance
is
used
in
so
many
different
contexts.
So
we
want
to
kind
of
highlight
what
do
we
mean
by
that
and
how
policy
management
can
help
you
achieve
that
goal
and
the
second
one
is
to
bridge
the
kubernetes
policy
management
Concepts
to
compliance
management,
because
ministers
are
standards
such
as
oscal
related
compliance,
and
we
want
to
bridge
the
two
and
kind
of
articulate.
C
C
So
that's
really
what
they're
trying
to
do
and
what
that
means
is,
if
you
think
about
an
Enterprise,
there
are
so
many
different
personas
who
are
interested
in
this
topic
right.
You
have
the
site,
reliability,
Engineers
or
administrators,
who
are
actually
managing
the
platform.
You
have
the
secops
people
who
are
focused
on
security
aspects.
You
have
compliance
Engineers
who
have
to
produce
evidence
for
Audits,
and
you
have
the
CSO
who
is
setting
the
Enterprise
standards,
security
standards
and
so
on.
So
you
have
all
these
different
personas
and
they
all
come
into
play.
C
C
So
that's
really
what
we
are
looking
at
and
the.
How
is
we
want
to
represent
the
best
practices
as
policies,
and
we
want
the
policies
to
be
managed
as
source
code
in
git,
just
like
any
other
source
code,
and
then
you
have
tools
available
so
that
all
these
different
personas
can
be
involved
in
how
those
policies
are
defined,
and
then
they
get
deployed
using
githubs.
And
then
you
have
a
regular
monitoring
on
the
posture.
C
With
respect
to
the
various
policies
you
detect
violations,
you
remedy
the
violations
automatically
when,
whenever
possible,
or
in
some
cases
you
know,
if
you
have
to
follow
a
it
process,
fine,
you
can
open
service
now
tickets
or
to
get
that
automation
rolled
out
and
and
also
you
can
do
some
analytics
to
fine-tune
the
policies
right
so
I
think
that's
the
overall
approach
and
the
benefit
of
doing
all
this
is,
as
I
said.
You
result
in
day-to-day
collaboration
between
all
the
stakeholders
and
personas
who
who
need
to
be
involved.
C
You
reduce
the
operational
cost
by
automating
things,
and
you
also
have
the
smes
who
are
knowledgeable
about
the
various
aspects,
actually
authoring
the
policies,
because
you
can't
expect
an
SRE
to
be
an
expert
in
all
aspects
of
security
and
resiliency
and
so
on
right.
So
the
various
people
who
have
that
expertise
and
you
want
to
bring
them
through
the
github's
methodology,
so
they
actually
are
doing
this,
and
we
also
want
to
do
this
in
a
more
open
fashion.
C
So
we
have
a
project
called
open
cluster
management,
which
is
the
CNC
of
sandbox
project,
and
we
want
to
kind
of
use
that
as
the
way
to
kind
of
Define
these
policies
and
collaborate
and
a
community
approach.
So
a
call
for
all
of
you
here,
I'm
really
glad
to
see
this
crowd.
So
the
call
and
request
is,
you
know,
come
and
participate
and
help
us
progress
this,
because
I
think
by
collaborating
we
can
all
contribute
and
Tackle
this
difficult
problem.
Thank
you
with
that.
I'll
turn
it
over
time.
D
So,
let's
see
Jay
I
just
mentioned
that
we
try
to
align
with
standards,
and
you
know
with
the
open
Community
for
collaboration,
so
the
standard
that
we
are
looking
here
is
the
nist
standard
for
compliance
as
code.
It's
called
oscal.
It
stands
for
open
security,
control
assessment
language
and
has
two
major
parts.
One
is
the
machine
readable
language
itself.
It
provides
about
seven
or
eight
schemas
that
correspond
to
the
various
compliance
artifacts
that
the
the
various
personas
in
compliance
will
manage.
D
The
second
part
is
the
framework
with
automated
support
for
automated
traceability,
meaning
that,
at
the
end
of
the
day,
when
I
get
a
result
or
I'm
talking
about
fixing
a
control
in
a
plan
of
action
and
milestones,
we
are
not
talking
about
a
label
in
some
spreadsheet
somewhere.
It
is
all
traced
back
to
the
catalog
that
we
originally
started
with.
So,
if
you
already
missed,
you
may
know
that
list
853
has
its
own
GitHub
government
GitHub,
and
the
ID
that
you
have
in
your
results
will
be
traced
back
to
the
controls
there.
D
So
in
terms
of
the
artifacts.
So
let's
give
an
example
right,
so
all
those
catalogs
and
what
we
talked
about.
What
is
what
exactly
is
is
that
about
so,
if
we
start
with
the
top
layer,
we
have
examples.
I
hope
you
recognize
some
of
them,
Regulatory
Compliance.
They
all
can
also
be
organizational
policies.
D
I
make
a
differentiation
here
between
capital,
P
policy
and
small
P
policy,
because
this
term
is
overloaded
and
when
we
are
talking
about
things
like
nist
or
HIPAA,
or
the
organizational
big
body
of
requirements
right,
we
talk
about
capital,
P
policies
and
in
Industry
they
are
typically
found
out
there
as
PDF
or
spreadsheets
format,
and
they
are
very
difficult
to
be
used
in
programmatic
interfaces
or
exchanges.
So
what
Oscar
does
it
takes
that
and
allows
to
represent
those
as
code
as
follows?
D
Right,
so
the
the
bread
and
butter
of
a
regulation
is
its
controls,
so
the
controls
are
represented
in
the
in
Oscar
in
the
Oscar
catalog
or
the
Oscar
profile.
Oscal
profile
is
a
subset
of
the
full
catalog
with
resolved
parameter
values,
so
I'm
selecting
as
a
seesaw
I'm,
selecting
this
particular
Baseline
I
select
the
values
and
I
represent
that
as
a
profile
in
Oscar.
Now
we
are
moving
from
the
realm
of
regulation
in
the
realm
of
technical
area,
so
we
are
talking
in
the
technology
about
rules
about
technical
controls
in
terms
of
a
particular
technology.
D
So
we
know
that
istio
right
has
to
be
this
or
that
way
that
the
Pod
has
this
or
those
restrictions.
So
we
are
talking
about
those
policy
rules.
Again
this
is
small
P
policy
and
in
in
Oscar
we
use
the
compliances
called
oscal
component
definition
to
allow
a
vendor
or
a
you
know,
a
service
provider
to
represent
the
mapping
between
the
controls
in
the
capital
P
policy
to
the
rules,
the
technical
controls
right
for
a
particular
product.
Those
are
the
the
technical
controls,
the
items
that
we
can
validate
right.
D
They
are
implemented,
they
may
have
apis,
they
may
have
you
know,
yaml
configuration
that
we
can
check
and
validate
the
results
from
that
right
are
represented
in
oscal
in
the
Oscar
assessment
result.
The
bottom
line
right
the
is
about
the
in
the
case
of
kubernetes.
We
have
a
lot
of
declarative
code
to
express
those
policies
and
we
have
an
example
here
so
for
sc28,
which
was
minus
control,
we
mapped
to
the
unsure
sensitive
resources
right,
which
is
the
technical
control
within
the
kubernetes
spots,
and
then
we
have
the
representation
right.
D
The
descriptive
declarative
code
down
there
so
to
link
it
back
to
what
we
have
today
in
the
working
group
in
the
policy
result
working
group.
We
have
this
report
that
is
done
at
the
policies
code
level.
So
right
when
we
go
into
the
policy
code,
we
get
out
of
the
compliances
code
Realm
and
we
move
into
the
policies
code.
So
when
Jaya
was
mentioning
Robert
about
bridging
right,
the
two
we
are,
we
are
looking
at
of
having
this
linkage
done
across
the
stack.
D
So
we
are
able
to
support
automation
so
what
we
do
in
the
working
group.
We
have
a
result
that
is
harvested
from
the
policies
code
report
and
we
translate
it
in
the
assessment
result
format.
So
Jaya
mentioned
about
the
different
personas.
I
know
this
is
a
lot.
Hopefully
when
this
is
get
a
recording,
you
can
look
at
them
individually,
but
you
see
how
the
Oscar
artifacts
are
mapped
to
those
individual
Persona
allowing
them
to
manage
and
to
author
those
artifacts.
D
Without
you
know,
working
on
each
other's
toes,
so
The
Regulators
are
going
to
use
the
catalogs
and
predefined
profiles.
The
control
providers
will
Author
those
component
definitions
with
the
mapping
system
owners
create
the
environment
they
subscribe
to.
You
know
the
the
services
deployed,
the
Clusters
Define,
video
scopes
and
Associate
these
various
profiles,
PCI
HIPAA,
whatever
is
of
needed
seesaw,
will
Define
the
baselines
right
and
the
parameters
that
are
need
to
be
associated
with
those
baselines
and
the
at
the
end
of
the
day.
D
If
you
do
fed
ramp,
you
need
a
system
security
plan
and
the
goal
to
use
those
artifacts
to
generate
the
system
security
plan
as
much
as
possible.
In
automatic
profession,
so
now,
if
you
go
from
this
realm
of
the
compliance
down
into
the
peps
right,
we'll
have
the
assessments,
the
policy
enforcement
tools
like
everno,
the
Oppa
gatekeeper
Falco,
that
will
be
the
source
of
those
results.
So
what
we
have
today
in
the
working
group
you
see
in
the
continuous
ping
here
we
support,
like
the
obvious
with
the
system
owner,
you
are
creating
those
environments.
D
We
are
able
to
collect
the
assessment
results
and
next
we
are
looking
to
be
able
to
support
the
the
specification
of
different
profiles
in
order
to
to
help
Bridge
into
the
next
level
in
the
in
the
oscal
framework.
So
here
is
an
example
of
how
the
nist
how
they
are
working
with
the
policy
result.
Yaml
is
translated
to
the
Oscar
right,
so
you
have
the
format
of
yaml
on
the
left
and
the
Oscar
on
the
right
so
to
to
summarize
right.
D
A
Yeah
I
think
we
have.
Are
we
at
the
end,
so
I
just
want
to
invite
everyone
to
attend
our
work
group
sessions.
We
meet
every
second
Wednesday
at
8,
A.M
Pacific.
So
in
almost
two
weeks
we'll
have
our
next
session
and
of
course
you
can
find
our
content
on
YouTube.
We
have
a
slack
Channel
and
yeah
look
forward
to
question
we'd
like
to
open
up
the
to
questions
from
the
audience,
and
we
have
the
you
know
the
project
perspective.
A
We
have
the
Enterprise
perspective,
we
have
a
developer
perspective
and
my
perspective
comes
from
the
audit
and
compliance
world,
so
any
questions
that
the
audience
might
have.
Otherwise
we
might
have
a
little
back
and
forth
here
on
the
stage
when
I,
when
I
started
off,
maybe
open
up
some
of
the
questions,
so
I
think
it
would
be
important
to
discuss
what
the
challenge
is
for
managing
policy
at
scale
and
I.
I.
Think
you
know.
Probably
all
of
you
here
have
some
perspective
on
that.
A
B
I
can
give
a
quick
perspective
from
what
we're
seeing
and
you
know
so,
nermata
my
company.
We
also
have
a
policy
engine
caverno,
which
is
one
of
the
Alternatives.
You
know
in
terms
of
enforcing
policies,
and
then
we
provide
governance
and
management
Tools
around
it.
So
what
we
typically
end
up
seeing
is
you
know.
First
of
all,
keeping
policies
consistent
across
all
clusters
requires
best
practices
like
git
Ops,
Etc
right,
so
you
have
to
fall
into
that
cloud-native
way
of
doing
things,
but
typically
within
an
Enterprise.
B
It's
not
just
a
matter
of
you
know,
setting
policies
and
then
you're
done
and
everybody's
going
to
be
compliant.
You
need
to
manage
policy
exceptions
in
a
flexible
manner,
so
we
have
ongoing
projects
and
things
going
on
with
that
to
be
able
to,
you
know,
have
Enterprise
type
workflows
around
that,
so
the
right
team
and
and
the
big
problem
is:
how
do
you
do
that
in
a
cloud
native
declarative
manner
as
well?
D
Could
add
to
that
that
I
think
the
the
problem
that
Robert
arises
is
one
of
the
most
difficult,
because
it's
a
multi-dimensional
problem.
The
scalability
right
is
in
in
a
multi-inational
domain
and
besides
the
policies
themselves,
we
are
looking
at
the
way
that
those
policies
expose
themselves
in
terms
of
being
configurable
or
in
terms
of
providing
the
results
so
being
able
as
a
security
and
compliance
provider
to
manage
across
such
a
variety
of
native
interfaces
is
another
dimension
of
this
scalability.
D
So
this
is
where
oscal
comes
into
the
place
and
I
realize
now
I
miss
to
discuss
during
the
presentation
so
that
we
live
time
for
questions
our
open
source
compliance
project
Trestle,
where
those
personas
get
a
collaborative
platform
to
author,
their
compliance
artifacts
via
the
interfaces
of
their
choice.
This
is
another
problem,
another
dimension
of
this
scalability
compared
to
the
operating
operation
team
or
the
devsecos,
where
the
type
of
skills
are
kind
of
uniform.
D
When
you
go
into
the
compliance
you
go
from
the
compliance
officer
down
to
the
developer,
you
have
all
the
skills
from
working
only
with
spreadsheets
or
working
only
with
text
or
working
only
with
code.
So
what
stressum
allows
those
personas
to
manage
the
artifacts
through
the
interface
of
their
choice?
So
we
support
spreadsheet
translation
marked
out
translations
the
type
of
translation
that
you
have
seen
here
from
yaml
to
to
the
Json
for
Oscar,
and
the
key
point
is
that
they
are
all
maintained
as
a
unit
of
unified
common
denominator,
the
oscal
four
months.
D
C
The
second
thing
I
found
is,
as
I
mentioned
earlier,
there's
not
going
to
be
a
single
policy
language
out
there
there's
going
to
be
multiple,
you
know,
gatekeeper
Opa
was
getting
a
lot
of
traction
and
then
qno
is
now
getting
traction
right.
So
we
already
have
two
and
then
there
are
all
these
security
tools
that
are
out
there.
There
are
already
supporting
some
of
these
capabilities.
They
have
their
own
built-in
roles
and
so
on.
So
you
need
like
a
framework
that
allows
you
to
integrate
all
these
multiple
policy
engines.
C
So
I
think
that
is
another
critical
piece
as
well,
because
you
can't
tell
customers
to
just
okay.
You
need
to
adopt
this
right
because
they
may
already
be
have
adopted
other
other
things,
so
we
need
to
be
able
to
cater
to
that,
and
the
other
thing
is
when
you
have
all
these
different
policy
engines
and
they
have
their
own
policy
files
or
yaml
files.
C
C
Also
finding
is
a
couple
of
days
ago
there
was
a
talk
attended
where
I
found
that
the
sixth
security
is
actually
focusing
on
mapping
some
of
their
security,
best
practices
into
industry,
253
and
those
kind
of
standards
and
I
think
what
I'm
seeing
is
and
I
talked
to
a
couple
of
customers,
and
they
also
mentioned
this
challenge
of
policy
management
and
dealing
with
compliance,
and
you
know
even
justifying
you
know
to
their
teams.
Why
do
I
need
to
add
another
policy
right
being
able
to
bridge
that
to
business
goals?
C
A
I
understand
that
way
and
I'm
reminded
literally
you
know,
sitting
next
to
the
river
and
the
bridge.
It's
like
there's
this
big
gap
between
you
know
the
developers
who
want
to
move
fast
and
add
features
and
functionality
and
then
kind
of
on
the
other
side,
the
ciso-
and
you
know,
regulatory
folks,
security
Ops,
who
want
to
make
sure
things
are
safe,
right
and
yeah.
E
D
Catalog
profile
all
these
artifacts,
they
are
the
same
whether
I'm
looking
at
the
content
like
infrastructure
as
code
right
that
that
I
need
to
deploy
so
pre-deployment
artifacts
or
the
runtime
environment
right
I'm,
following
the
same
I'm,
HIPAA
or
I'm
right,
I'm,
not
PCI,
left
and
hip
are
right.
So
the
the
artifacts
that
we
develop
or
the
personas
that
we
are
talking
about
author
are
the
same.
What
is
different
may
be
the
policy
so
go
from
compliance.
D
We
go
into
the
policy
realm
now
there
is
this
a
new
approach,
especially
that
oppa
is
providing.
Where
is
right
ones
and
use
multiple
times,
meaning
that
even
the
policy
that
I'm
writing
is
the
same
and
I
apply
the
same
one
left
and
right
again:
I'm
talking
about
Apples
to
Apples,
right
infrastructure
is
code
and
and
the
environment
that
I
deploy.
If
we
are
looking
at
the
compliance
of
the
pipeline
itself,
obviously
it's
a
different
set
of
you
know,
rules
and
so
on.
D
But
if
we
compare
apples
to
apples,
you
want
to
write
once
and
use
multiple
times,
and
this
means
that
we
bring
the
differentiation
only
at
the
level
of
abstraction
of
the
evidence
and
then
all
the
rest.
We
want
to
be
the
same.
So
it's
another
way
to
address
the
the
scalability
of
that,
because
it
if
at
each
layer,
I
have
another
set
of
artifacts
another
set
of
policies,
it
it
multiplies
and.
C
C
A
And
just
one
more
thing
to
add
to
that,
because
I
think
the
especially
for
the
supply
chain
and
if
anyone's,
actually
looked
at
an
s-bomb
and
tried
to
you,
know,
make
sense
of
that.
You
quickly
realize
that
you
have
to
build
out
a
tooling
and
a
design
that
allows
you
to
aggregate
all
this
data
and
align
it
with
policy
with
with
other
tooling
right.
A
Here's
the
definition
of
what
my
system
or
product
supports
here,
the
policies
that
can
be
enforced
either
against
this
or
with
this,
and
you
know
it
comes-
becomes
a
very
reusable
set
of
assets
that
then
you
know
with
other
tooling
I
I
saw
an
example
for
Opa,
where
you
can,
you
know
point
it
to
any
open,
API
and
then
it'll
generate
policy
based
off
of
logic
and
templates.
So
we
get
to
a
point,
hopefully
where
the
policy
rules
themselves
are
being
at
least
generated
in
template
form,
and
then
you
know
different
subject
matter.
E
C
That,
in
a
more
open
fashion,
right
because
right
now
what's
happening
is
everybody
is
dealing
with
this
problem
on
their
own.
So
if
you
can
standardize
and
as
Robert
was
saying,
if
we
can,
if
the
technology
providers
also
can
collaborate
and
expose
the
parameters
needed
right,
then
it
becomes
easy
for
everyone.
D
And
to
give
you
a
you
know
a
peek
into
the
next
like
Oscar
roadmap.
Another
scalability
problem
is
that,
right
now,
if
we
have
to
provide
the
you
know
the
assessment
and
the
reports
for
hip
power
for
PCI
or
for
we,
we
all
the
time
or
most
of
the
time
we
start
from
scratch.
So
what
was
called
brings
now
is
another
type
of
mapping.
D
So
what
G
mentioning
is
between
the
capital,
P
policy
and
small
people
policy
right
regulation,
controls
and
policy
oppa
is
now
Oscar
is
now
bringing
up
a
mapping
support
between
controls
so
that
I'm
able
now,
if
I,
have
the
results
for
a
particular
regulation
to
reuse
the
evidence
and
the
results
for
another
regulation
through
this
mapping.
So
yet
another
solution
right
to
the
scalability
when
I
have
multiple
policies.