►
Description
Securing your Tekton Pipeline - Vincent Demeester & Ivan Font, Red Hat
Tekton is a cloud native CI/CD solution. There are many CI/CD solutions exist today and TektonCD intend is not to replace them but it's designed to offer a standard building block for such CD services on Kubernetes. It gives you granular control over your entire CI/CD pipeline. By using Kubernetes native CRDs one can define individually composable tasks that can be glued together to create and execute any modular CI/CD pipeline. But what are ways in which we can incorporate security throughout your CI/CD pipeline? Here we introduce tools built on Open Policy Agent to help you secure your CI/CD pipelines. In this talk we’ll provide an overview of Open Policy Agent along with projects like Gatekeeper (delivered as part of OpenShift) and Conftest, and demonstrate ways to incorporate them into any stage of your pipeline.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
Hi,
thank
you
for
joining
us
for
this
session
on
securing
your
tecton
pipeline.
My
name
is
vincent
de
mister.
I'm
a
software
engineer
at
red
hat,
I'm
the
architect
of
openshift
pipeline,
which
is
the
distribution
of
pipe
of
tecton
pipeline
that
we
ship
as
part
of
openshift,
and
I
am
one
of
the
leader
of
the
tecton
community
upstream.
A
A
So
what
is
tekton
in
a
nutshell?
Tecton
is
an
open
source
project
that
aims
to
provide
a
set
of
shared
and
standard
components
for
building
kubernetes.
Still
cigd
system
will
go
a
bit
more.
How
it
does
this.
It's
governed
by
the
continuous
db
foundation
and
contribution
are
coming
from
a
lot
of
companies.
Google,
red
hat
cloud
b's,
ibm,
pivotal
and
many
more
like
apple.
Let's
try.
It's
a
very
active
community
right
now.
A
In
in
curious
for
the
user
to
describe
its
pipeline,
this
means
you
would
describe
your
pipeline
with
the
same
language.
You
describe
your
services
or
your
deployments
or
even
your
code,
and
this
also
means
you
can
use
all
the
tools
you
are
used
to,
while
interacting
with
tyrannos,
but
with
tecton
everything
runs
into
containers.
Your
pipeline,
your
task
of
steps.
All
this
concept
will
run
into
containers
and
even
the
control
plane
of
tecton
will
run
into
containers.
A
You
can
build
images
using
kubernetes
tools,
of
course,
building
an
image
is
just
one
thing:
tecton
can
do
and
to
to
to
build
those
images
you
can
use
anything
that
would
run
into
a
container,
so
image
builder
can
echo
jib
co.
I
can
even
use
docker
in
docker
if,
if
you
have
the
right
permission
on
your
cluster
to
do
so,
usually
in
your
pipeline,
you
also
want
to
deploy
things
and
you
can
deploy
a
multiple
cloud
platform.
A
Of
course
you
can
deploy
on
communities,
but
it's
not
you
don't
need
to
deploy
on
the
currencies
you're
in
and
you
can
deploy
on
virtually
anything
as
long
as
you
have
the
tools
inside
your
image.
One
example
of
this
is,
if
you're,
using
the
orca
command
that
is
coming
from
a
mac
station.
I
think
you
can
provision
macstadium.
A
Or
a6
images
or
machines-
and
you
can
run
you
test
against
it
and
then
destroy
them
after
right
and
also
takedown
ships
are
provides
some
powerful
user
interface
upstream
there's
two
user
interface.
One
is
the
cli
called
dkn
which
allows
you
to
interact
with
your
pipeline
and
your
tasks,
your
logs
start
new
pipeline,
etc.
A
A
So
a
few
concepts.
Usually
we
do
split
the
concept
into
two
categories
on
the
left:
the
definition
types
on
the
right,
runtime
or
execution
types.
So
on
the
left,
you
have
initially
the
step.
What
is
a
step?
It's
just
a
command
that
will
run
into
a
container
with
a
set
of
environment
variables
volumes.
A
A
A
And,
finally,
you
have
the
pipeline,
which
is
a
graph
of
task
with
some
inputs
and
outputs
inputs
and
outputs
could
be
pipeline
resources,
but
they
are
deprecated
or
could
be
workspace,
parameters,
secrets,
etc
and
those
the
gra.
This
graph
of
task
is
obviously
going
to
be
executed
in
a
certain
order
and
as
it's
a
graph,
some
a
task
can
run
into
parallel.
Sometimes
I
could
wait
for
our
others,
etc.
We'll
dig
a
little
bit
more
into
examples
on
the
right
side.
There
is
the
execution
part.
A
So
when
you
define
a
task
or
a
pipeline,
you
define
what
it
should
do,
but
when
you
apply
them
to
your
cluster,
nothing
is
going
to
happen.
You
need
to
actually
start
it's
by
creating
a
task
and
for
a
task
or
a
pipeline
run
for
pipeline
and
what
you
do
is
you're
referencing
a
pipeline
for
pipeliner,
for
example,
and
you
bind
things
to
it,
you
you
actually
pass
the
correct
parameters
with
the
correct
values.
A
A
So
in
a
schema.
This
is
how
it
looks.
You
have
your
pipeline,
which
is
composed
here
in
in
four
tasks.
The
task
one
has
two
step:
three
steps.
The
two
tasks
are
depending
on
this
task.
When
you
have
one
step
and
there's
a
final
task,
that
just
depends
on
the
one
on
the
top.
That
has
two
steps.
The
I
and
the
o
in
circle
are
the
inputs
and
outputs
they
could
be
here.
In
this
example.
A
They
are
pipeline
resources,
but
they
could
be
parameters,
workspace,
etc,
and
you
have
the
pipeline
run
on
on
and
below,
which
is
gonna
reference.
The
pipeline
pass
it
some
pipeline
resources,
and
this
will
result
in
a
bunch
of
tasks
on
at
least
one
for
each
task
defined
in
the
pipeline.
There
could
be
more
than
one
because
there
is
a
retry
mechanism
that
can
be
defined
and
that
can
allow
the
user
to
say.
I
want
to
retry
this
task
twice
or
thrice,
or
many
more
time
until
it
succeed
but
yeah.
A
So
let's
look
a
little
bit
of
how
it
looks.
You
know
yaml
currently,
so
as
any
currencies
object,
there's
the
api
version
in
the
kind
the
api
version
for
pipeline
is
ticked.
On
the
dev
slash
the
version
right
now
we
are
at
the
version
v1
beta1
and
the
kind
for
a
task
is
going
to
be
task.
Then
you
have
the
metadata
with
the
name,
the
labels
you
can
put
on
this
etcetera
annotation
and
the
spec,
which
is
the
core
of
the
task.
A
Here
we
show
just
the
parameters,
so
you
can
define
a
set
of
parameters
that
will
that
the
pipeline,
or
the
task
run,
will
need
to
specify
when
executing
this
task.
So
this
can
be
things
like
the
folder.
You
want
to
be
in
the
tag,
your
image,
etc.
It's
it's
it's.
It
can
be
anything
you
can
pass
either
strings
or
array.
A
Then
there's
the
steps.
So
here
each
step
can
be
named.
You
can
also
have
unnamed
steps
here.
We
have
one
step
which
is
build
and
it's
gonna
use
the
image
calling
with
the
tag
114
and
the
comment
will
be:
go,
build
dot,
slash,
dot,
dot,
dot
which
is
gonna,
build
whatever
is
in
the
current
folder
and
the
rest
of
the
hierarchy.
A
One
thing
to
note:
here:
we
are
using
command
inside.
Instead
we
could
use
script
and
under
script.
You
would
give
it
a
script
as
a
text
and
the
script
is
not
limited
to
any
language
so
by
default,
if
you
don't
specify
any
shebang,
any
shebang.
So
the
hashtag
explanation
point
it's
going
to
use
bash,
but
you
could
write
your
script
in
python
in
ruby
anything
that
can
be
script
as
long
as
the
image
you're
using
as
the
binary
it's
going
to
work,
and
now
we
can
jump
on
the
pipeline
definition
of
tecton
pipeline.
A
So
similarly
api
version
kind
here
the
kind
is
pipeline,
the
name
is
calling
build
and
the
spec
is
gonna
have
parameter
parameters,
workspace,
anything
that
you
would
have
also
on
on
on
task
here.
I
I
kind
of
run
out
of
space,
so
I
didn't
put
them
and
you
can
have
the
task
so
here
we
have
two
tasks:
the
task
named
checkout,
which
will
check
out
the
code.
A
And
you
know
you
cannot
run
after
so
this
is
how
you
just
you
declare
dependency
between
tasks.
Here
we
are
asking
pipeline
to
run
my
builds
after
we
do
the
checkout,
obviously,
to
get
the
source
code
and
yeah.
That's
a
quick
introduction
to
takedown
pipeline
now.
I
I'll
give
the
hand
to
ivan
to
talk
about
opa.
B
So
what
is
the
open
policy?
Agent
oppa
is
an
open
source,
cncf
graduated
project
and
is
a
general
purpose
policy.
Engine
oppa
enables
you
to
decouple
the
policy
decision
making
from
policy
enforcement,
so
your
application
can
offload
policy
decisions
to
oppa,
using
a
query
to
understand
this
a
little
further.
Let's
take
a
look
at
this
diagram.
B
Let's
say
you
have
an
application
service
running
somewhere.
This
can
be
any
application
service
running
in
any
system,
whether
that's
inside
of
a
cluster
such
as
kubernetes
or
outside
at
the
top.
We
have
a
request
that
comes
into
the
service
from
there.
The
service
needs
to
evaluate
some
policy
that
it
needs
to
enforce
the
service.
Then
queries
opa
by
passing
it
json
as
input
as
shown
on
the
left.
B
B
B
B
B
B
B
B
B
B
Now
that
we've
gained
some
understanding
about
what
opa
is
and
how
it
integrates
with
kubernetes
using
gatekeeper,
we
can
shift
towards
how
to
integrate
oppa
with
tecton.
One
of
the
best
use
cases
for
techton
and
opa
is
to
leverage
oppa
to
secure
your
techtom
pipelines
to
create
a
dev
secops
process.
B
This
is
a
diagram
to
visualize
the
flow
of
execution
for
a
tecton
pipeline
gatekeeper
can
be
inserted
into
the
flow
in
several
ways.
Here
we
see
oppa
being
used
with
gatekeeper
as
a
validating
admission
web
hook
to
evaluate
policies
to
determine
whether
it
should
allow
or
deny
the
deployment
of
your
application.
B
B
Gatekeeper
can
also
be
inserted
earlier
in
the
pipeline
to
effectively
shift
left.
Your
dev
set
cops
process
in
order
to
insert
oppa
earlier
in
the
pipeline.
We
can
leverage
the
server
dry
run,
feature
of
kubernetes
to
allow
the
gatekeeper
admission
controller
to
pass
or
fail
the
pipeline
before
proceeding
with
the
rest
of
the
pipeline
tasks.
B
B
B
Of
course,
the
use
of
a
test
registry
such
as
this
example
is
exactly
the
kind
of
thing
you
want
to
prevent.
So,
while
the
commit
is
flowing
through
the
tecton
pipeline,
we
can
look
at
the
gatekeeper,
constraint,
template
and
constraint,
resources
that
are
configured
to
prevent
unauthorized
registries
from
being
used
to
deploy
images.
B
B
B
B
So
you
can
see
our
gatekeeper
policy
acted
as
a
last
resort
safety
net
that
has
prevented
the
deployment
of
an
image
from
an
untrusted
registry-
okay,
great,
but
the
developer
had
to
wait
for
the
entire
pipeline
to
nearly
complete
in
order
to
eventually
see
it
fail,
that's
rather
time
consuming
and
expensive.
Wouldn't
it
be
great
if
we
can
shift
left
so
that
we
can
add
these
safety
checks
earlier
in
the
pipeline,
so
the
developer
can
receive
more
immediate
feedback.
B
B
Now,
let's
rerun,
the
last
pipeline
run
we'll
just
alt
tab
to
switch
over
to
our
tecton
dashboard,
and
we
can
see
the
list
of
pipeline
runs
here.
The
previous
one
has
failed,
so
here
we
can
quickly
restart
the
last
pipeline
run
now,
let's
switch
back
and
observe
how
the
pipeline
run
is
doing
using
the
tecton
cli
tool.
B
Again,
we
can
see
that
we
first
fetch
the
repository
successfully,
but
now
we
attempt
to
apply
the
opa
policy
immediately
after
using
server
dry
run,
and
it's
failed
for
the
exact
same
reason,
because
the
container
oppa
example
app
has
an
invalid
image.
Registry
allowed
registries
are
quay
to
I
o
okay
cool,
so
we've
managed
to
give
the
develop
the
developer
feedback
earlier.
All
this
was
done
using
gatekeeper,
but
there's
another
alternative
using
comptest
and
we'll
try
now.