►
From YouTube: Lightning Talk: Automating Industry Regulation (SoX, SoC... Balaji Sivasubramanian & Gopinath Rebela
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Lightning Talk: Automating Industry Regulation (SoX, SoC 2) Enforcement During Software Delivery - Balaji Sivasubramanian & Gopinath Rebela, OpsMx
The development teams in Enterprises are increasingly deploying to environments that must adhere to various industry regulations like SoX, SoC 2, FedRamp, etc. With the increased frequency of deployments and the need to audit them, these control and enforcement must be automated as part of the CI/CD process. This talk will show how to integrate OPA policy integration with Spinnaker and share sample policies for enforcing compliance rules based on real-world regulatory requirements. Also, we will demo the integration, including an audit of the policy enforcement.
A
Are
we
going
to
start?
This
is
going
to
be
a
lightning
talk.
This
is
10
minutes
a
short
one
So
today
we're
going
to
touch
on
how
to
automate
regulatory
enforcement
during
software
delivery.
So
primarily
as
the
the
issue
is
in
a
software
delivery
pipelines,
we
have
n
number
of
sources,
not
all
of
them
are
in
the
same
pipeline
and
you
have
different
stages
between
the
going
to
your
staging
environment,
to
the
production
and
in
between.
There
are
n
number
of
Security
checks.
A
Now,
how
do
we
bring
that
all
in
for
the
automation
we
will
go
through?
What
is
the
motivations
and
what
are
the
problems
you
would
face
in
automating,
this
security
compliance
and
couple
of
use
cases
on
what
we
have
done
with
that.
So
what
are
the
primary
drivers
for
compliance
automation?
Is
there
multiple
ways
people
are
trying
to
automate
these,
and
one
of
the
issues
that
one
faces
is:
how
do
we
speed
up
the
delivery
process
during
the
automation,
so
we
have
devsecop
sector
devops,
integration
of
Security
checks
in
the
delivery
pipelines
and
automating.
A
These
Security
checks
through
pipeline
enforcement,
and
all
of
these
are
happening.
Ad
hoc
and
now
one
of
the
problems
that
it
faces
is
when
you
present
the
guard
rails
to
the
developers.
How
do
we
present
that
it's
easier
for
developers
to
use,
and
also
it
doesn't
stop
them
from
deploying
their
regular
use
cases
to
their
testing
environments
and
testing,
but
once
they
start
promoting
to
higher
environments,
it's
easy
for
them
to
identify
what
checks
needs
to
happen
and
then
go
through
those
kind
of
checks.
A
So
that's
the
the
reason
why
you
need
a
way
of
integrating
your
SEC
Ops
into
your
delivery
pipeline
without
reducing
the
developer
productivity.
So
what
are
the
compliance
Dimensions
right
here?
We
are
specifically
looking
at
say
the
Spinnaker
based
delivery,
and
in
that,
how
do
we
enforce
this
CIA?
It's
a
confidentiality,
availability
and
integrity
for
your
applications.
Now,
not
necessarily
everything
can
be
done
in
the
Spinnaker
itself.
A
For
example,
when
you
have
this
availability
you're
looking
at
the
DDOS
production,
Das
production
for
the
applications,
it's
done
after
the
deployment-
let's
say
so-
that's
not
part
of
the
delivery
workflow,
but
we
should
be
able
to
get
the
data
and
use
that
to
analyze
and
provide
the
compliance
there.
But
what
we
can
do
with
the
Spinnaker
pipelines
in
the
delivery
process
itself
is
to
have
the
rbac
for
your
application
delivery.
A
It's
the
same.
Similarly,
the
Integrity
end-to-end
verification,
the
security
policies
they're
ensuring
the
vulnerability
checks
for
the
delivery
needs
to
be
integrated
part
of
the
system,
and
it
needs
to
be
automatic.
Also,
you
don't
want
to
have
an
explicit
stage,
that's
plugged
in
in
that
case
the
developers
will
not
be
able
to
do
their
own
pipelines.
So
these
things
need
to
happen
as
part
of
the
process
and
have
the
guard
rails
in
there,
but
not
explicitly
require
every
developer
to
know
how
to
do
these
right.
A
All
right
and
at
the
same
time
we
want
to
make
sure
that
any
changes
that
happen
to
the
pipelines
or
the
policies
that
are
captured.
So
what
are
we
talking
about
here?
If
we
have
the
delivery
pipelines,
I
mean
that
pipeline
can
be
one
pipeline
or
n.
Different
pipelines
happen
at
different
time
frames
within
the
delivery
process,
but
we
need
to
enforce
the
process
policies
like
the
requirements
that
index
given
production
environment.
A
It
must
follow
through
blue,
green
or
or
Canary
deploy,
or
it
has
to
go
through
a
vulnerability
check
with
no
critical
vulnerabilities
for
the
binary
to
be
deployed,
and
you
may
have
some
additional
admission
policies
for
there.
For
example,
for
some
of
the
VPC
deployments
you
may
say
for
the
production
deployments,
it
has
to
be
certain
type
of
VPC
with
the
private
subnets
and
additional
rules.
Therefore,
the
networking
for
it
all
of
that
needs
to
happen,
but
at
the
same
time,
for
the
same
binaries
or
applications
that
are
deployed
in
say,
integration,
environments.
A
You
have
much
relaxed
rules
for
it
where
you
want
to
be
able
to
let
the
QA
or
developers
to
test
it
out
their
applications.
For
their
dependencies,
so
what
does?
How
do
we
do
this
right?
So
all
these
things
can
be
done
through
the
external
policies,
but
one
of
the
problems
here
you
face
is:
where
is
the
data?
A
If
you
want
to
run
these
policy
checks,
so
one
of
the
ways
that
we
have
done
it
is
we
have
a
metadata
store,
as
the
delivery
process
happens,
with
the
systems
that
are
going
through
the
delivery,
all
the
data
for
the
binaries
that
are
generated,
for
example,
you
have
container
images
with
a
certain
tag.
They
have
a
shot
that
gets
generated,
so
we
store
that
information
and
when
it
goes
through
a
repository,
the
repository
change
information,
the
events
are
triggered.
A
We
store
that
information
and
then
the
binary
scan
data
that
comes
through
it,
the
metadata
for
that
is
also
stored.
So
once
the
testing
runs
after
the
testing,
there
is
a
data
that
gets
generated
through
the
testing
that
also
gets
stored
in
there.
Now,
at
the
point,
when
the
policy
admission
check
gets
triggered,
we
have
the
data
for
a
given
binary
that
is
being
deployed
for
say,
container
tag
or
a
VM
image
for
those
we
have
the
information
on
what
are
all
the
checks
that
it
went
through
through
that
process.
A
Then
we
can
then
apply
the
policies
on
that
data,
the
policy
engine.
Basically,
here
what
we
are
using
is
a
Opa
policy
and
the
the
trigger
would
be
the
the
deployment
time
based
on
the
plug-in
based
on
the
policy
set
in
the
plugin
to
the
cloud
driver.
It
triggers
the
policy
engine.
Similarly,
there
is
a
plug-in
for
the
Orca,
depending
on
the
pipeline,
that
we
are
running
it
triggers
the
policy
engine
and
so
in
the
policy
engine
now
accesses
the
data
from
the
metadata
store
and
applies
the
rules
on
it.
A
A
So
we've
took
to
give
an
example
of
a
say,
socks
policy.
So
that's
one
of
the
common
policies
that
we
see.
So
you
have
two
different
groups
of
individuals
providing
the
approval
for
deployment
to
the
production,
so
one
of
the
approvals
obviously
comes
from
the
qqa
or
the
developer
testing
and
the
second
one
policy
approval
could
come
from
the
operations
so
we'll
we
can
have
the
policy
that
says
there
are
during
the
part
of
the
pipeline.
The
trigger
done
by
the
user
is
different
from
the
approval
done
by
the
testing
or
operations.
A
It's
very
simple
policy,
because
now
we
are
collecting
the
metadata
from
the
different
stages
in
the
pipeline.
We
have
the
data
available
through
the
policy
engine
and
at
the
deployment
time
we
could
simply
run
that
policy
and
check
if
these
two
individuals
are
different
and
allow
the
to
go
to
production.
A
There
are
two
different
things
that
are
required
for
automating
their
compliance.
One
is
our
ability
to
collect
the
data
from
different
stages
within
the
pipeline,
and
the
second
is
writing
the
compliance
rules
on
top,
and
there
are
triggered
at
different
stages
in
the
pipeline
that
act
on
the
data
that
we
collected
right.
A
So
essentially
it
comes
down
to
integrating
the
security
checks
in
the
delivery
pipeline.
You
you
do
have
to
make
sure
that
the
security
checks
are
done
in
the
pipeline
and
then
ensuring
that
the
pipeline
pipelines,
when
they
are
run
all
trigger
the
policy
checks.
So
you
don't
have
to
have
different
stages
in
the
pipeline
to
trigger
it.