►
Description
Cristian Klein, Head Architect @ Elastisys, is doing a demo on how to integrate a CI/CD pipline with Elastisys Compliant Kubernetes.
This is a video clip from Elastisys Compliant Kubernetes office hour #7.
Read the open source documentation for Elastisys Compliant Kubernetes here: https://elastisys.io/compliantkubernetes/
A
So
before
you
even
start
thinking
about
ci
cd,
I
would
very
much
like
you
to
do
everything
manually,
because
I
often
hear
people
they're
saying
like
well.
Ci
cd
is
really
important
to
us
and
it
will
solve
all
of
the
issues.
But
my
experience
is
that
if
you
do
not
master
this
process
manually,
you
are
doomed
to
fail
while
doing
it
automatically.
A
So
in
particular
what
I
noticed
that
most
of
the
companies
out
there
that
are
struggling
with
ci
cd
or
that
perhaps
are
having
a
bad
experience,
is
maybe
because
they
don't
have
a
proper
testing
strategy.
Maybe
they
don't
have
enough
liveliness
probes
into
their
containers
in
order
to
make
sure
that
while
the
deployment
is
stopping
its
rollout
and
things
like
that,
so
my
suggestion
is
start
first
doing
everything
manually
and
then,
while
you
are,
and
then
at
the
point
where
you're
confident
that
well,
the
manual
process
is
working
correctly
and
it's
kind
of
getting.
A
A
If
I
were
to
give
a
comparison,
you
never
learn
how
to
fly
with
an
autopilot
when
you're
in
your
first
day
of
flight
school
right.
You
would
first
go
to
the
basic
principle
of
how
do
I
control
this
machine
to
begin
with,
and
then,
when
you
finally
master
this,
then
you
would
know
how
to
also
lose
use
the
autopilot.
A
Similarly,
also
with
the
car
you
will,
you
will
never
learn
how
to
drive
by
cruise
control
or
by
speed
limiter
on
your
first
day.
It's
the
fact
that
you
have
a
machine
between
you
and
the
actual
system
that
you
want
to
control,
so
the
cruise
control
cicd
pipeline
actually
makes
things
more
complicated
for
in
the
beginning,
because
you
now
need
to
understand
not
only
the
system.
The
final
system
that
you
want
to
control,
but
also
the
integration
between
you
and
that
system,
so
make
sure
that
you
understand
each
piece
separately
before
you
put
them
together.
A
And
I
just
wanted
to
highlight
that
our
documentation
very
much
reflects
also
this
mindset,
so
cicd
is
rather
laid
in
the
user
guide
exactly
to
send
out
this
message
that
you
need
to
master
a
lot
of
things,
for
example,
setting
up
proper
alerts
in
case
something
goes
wrong
with
your
application
orders.
Roller
doesn't
work
properly
before
you
can
think
about
csd
integration.
A
Now,
when
it
comes
to
csd
integration,
compliant
kubernetes
does
not
come
up
with
its
own
solution.
It
does
not
impose
anything
like
that.
It's
it's
battery,
not
included.
When
it
comes
to
cicd
pipelines.
However,
it
can
be
integrated
with
pretty
much
any
cicd
solution
out
there
that
that
you
want
to
use.
A
Let's
briefly
discuss
about
two
styles
of
csd
pipelines,
so
I
hear
very
many
people
that
they
think
cicd
is
one
thing
or
they
think
that
it's
another
thing
and
they're
actually
talking
about,
let's
say
completely
to
two
completely
different
styles
of
ci
cd.
So
let's
clarify
this
from
the
very
beginning,
so
you
have
certain
styles
in
which,
basically,
you
have
a
csd
worker.
My
favorite
system
is
gitlab
ci
or
github
actions
that
listens
to
changes
in
your
git
repository
and
then
upon.
A
These
changes
is
running
a
script
or
is
running
a
workflow
or
an
action
whatever
the
terminology
differs
slightly
from
cicd
pipeline
to
another,
but
the
principles
are
the
same,
and
these
will
then
push
changes
into
the
kubernetes
cluster
and
when
you're
doing
this
kind
of
thing,
it
slightly
simplifies
triggering
actions
as
a
result
of
changing
the
git
repository
right.
Normally,
we
have
very
tight
integration
between
these
two
systems,
both
in
github
and
gitlab.
A
So
the
second
you
push
something
to
git,
gitlab
and
github
will
immediately
react
to
that
and
will
make
the
necessary
changes
so
that
integration
is
a
bit
easier.
On
the
other
hand,
you
need
to
be
a
lot
more
mindful
about
how
exactly
are
you
going
to
give
github
actions
or
gitlab
ci
access
to
your
kubernetes
cluster?
And
besides,
I'm
going
to
demonstrate
in
this
particular
today,
I'm
going
to
demonstrate
how
you
set
up
the
right
credentials
in
the
csd
pipeline,
but
you
should
also
probably
think
about
white
listing,
for
example,
or
sorry
ip
allow
listing.
A
A
So
when
I
say
listening
to
changes
that
can
happen
in
two
ways,
either
by
a
polling.
So
every
five
minutes,
argo
cd
would
check
with
the
git
repository
hey,
do
you
have
any
new
changes
or
not,
or
sometimes
it's
possible
to
do
a
bit
more
reactive
integration
by
setting
out
something
like
web
hooks
and
at
the
end
of
the
day,
argo
cd
then
takes
those
changes
and
so
pulls
those
changes
and
then
again
connects
the
kubernetes
api
to
enforce
those
changes
and,
in
case
you're
looking
for
the
second
style
of
csd
pipelines.
A
A
If
your
git
repository,
for
example,
is
internal
and
is
isolated
from
the
production
environment
which
I
have
seen
happening
in
some
environments,
how
exactly
will
you
make
sure
that
rings
cluster
has
access
to
it
and
so
on
and
right
now
I
feel
that
there
is
no
better
or
worse
style,
it's
just
trade-offs
and
make
sure
that
you're
choosing
the
solution.
That
is
the
right
one
for
you
and
for
your
organization.
A
Today
I
will
demo
the
push
style
ci
cd,
so
I
will
show
specific
how
to
use
github
actions
in
order
to
push
changes
that
are
making
a
git
repository
into
the
kubernetes
cluster,
however,
be
mindful
about
the
fact
that
this
works
for
any
kind
of
push
type
ci
cd,
so
it
works
both
for
gitlab
ci
for
github
actions
for
azure
devops,
if
you're
still
using
jenkins.
It
works
also
for
that
and
so
on.
So
please
focus
on
the
principles
that
I'm
about
to
highlight
and
not
on
the
exact
technical
solution.
A
So
the
first
thing
that
you
should
do
is
always
check
if
you're
on
the
correct
cluster.
So
here
I
see
that
I'm
on
my
demo
environment
seems
to
be
the
right
cluster.
That's
good!
Let
me
check
if
I'm
also
in
the
correct
name
space,
so
I'm
running
in
the
main
space
demo,
one
that's
great,
and
now
let
me
check
what
exactly
my
user
can
do,
knowing
that
kubernetes
has
so-called
privilege
escalation
prevention,
so
I
cannot
create
a
role
which
has
more
permissions
than
my
own
user.
A
A
A
A
I
would
personally
recommend
against
it,
but
it's
your
choice.
Does
it
need
to,
for
example,
create
secrets,
or
do
you
rather
want
to
manage
secrets
outside
your
csd
pipeline
and
then
just
give
access,
just
configure
the
deployments
to
allow
access
to
your
from
your
application
to
those
secrets
and
so
on
and,
like
I
said
this
is
also.
This
is
a
very
good
moment
to
think
about.
Okay,
which
exact
permissions.
Do
I
need
the
cicd
pipeline
to
have
in
order
for
it
to
successfully
complete
its
task.
A
A
And
then
I
will
look
in
deploy
ci
cd
role
and,
as
you
can
see,
I
have
created
a
role
for
the
csd
pipeline.
It's
allowed
to
fully
manipulate
conflict
maps,
spots,
features
and
services
same
with
deployments.
It
needs
replicas
that
in
case
you
want
to
use
helm,
upgrade
minus
minus
weight,
which
makes
a
lot
of
sense.
In
certain
cases
it's
allowed
to
use
to
create
horizontal
pod,
auto
scalers.
A
That's
also
something
that
is
very
commonly
used
in
applications
ingresses,
which
you
need
in
order
to
give
access
from
outside
the
cluster
into
your
application,
and
then
prometheus
rules
and
service
monitors
are
in
order
to
export
metrics
and
to
set
alerts
for
application.
Specific
metrics
and
network
policies
are
like
we
present,
like
we
discussed
at
length
in
previous
sessions,
are
pretty
much
the
equivalent
of
firewalls
in
the
kubernetes
world,
so
this
feels
reasonable
right.
I
did
not
give
my
csd
pipeline
too
many
permissions.
A
That's
actually
a
very
good
question,
simon,
unfortunately
they're
having
quite
a
lot
of
attacks
that
have
not
targeted
production
infrastructure
directly.
Rather
they
have
targeted
the
cicd
pipeline,
and
this
is
often
let's
call
them
a
more
neglected
attack
vector
the
ci
cd
pipes
are
usually
very
powerful.
They're
often
allowed
to
create
and
destroy
infrastructure,
they're,
often
running
backup
jobs.
They're
they're
often
used
to
enforce
various
workloads.
A
So
if
your
csd
pipeline
is
under
attack
and
somebody
managed
to
get
more
position
than
necessary
there,
then
they
are
in
a
very
good
position
to
then
inflict
infiltrate
into
your
production
environment
and
potentially
do
damage
to
customer
data.
So
by
reducing
the
amount
of
permissions
that
your
cicd
pipeline
has
towards
the
production
environment,
you
are
further
reducing
risk
and
are
minimizing
the
damage
that
can
happen
in
case
an
attack
is
happening.
A
So
to
this
end,
I'm
going
to
create
a
service
account
for
the
cic
pipeline,
and
I
forgot
to
mention
something
that
maybe
is
interesting
at
this
point.
So
if,
at
some
point
I
give
I
try
to
give
the
csd
pipeline,
I
try
to
create
a
csd
role
that
is
more
powerful
than
myself.
This
operation
here
would
fail,
and
it
would
give
me
a
big
warning.
I
can
even
demonstrate
later
in
case
you're
interested
about
it,
but
otherwise
our
documentation
also
highlights
these
errors
and
this
error
and
tells
you
how
to
recover
from
it.
A
A
A
A
With
that
being
said,
now
I
have
a
service
account.
What
do
I
do
next?
I
somehow
need
to
take
this
service
account
and
to
configure
it
in
my
csd
pipeline
and
in
order
to
achieve
that,
I'm
going
to
extract
a
cube
config
from
the
from
the
service
account.
So
maybe
I
can
also
demonstrate
this
a
little
bit.
A
A
At
the
end
of
the
day,
you
will
just
get
a
magic
cube
config,
which
is
suitable
to
be
used
in
your
csd
pipeline,
handle
it
with
care,
because
anybody
who
can
disclose
this,
who
can
see
this
is
going
to
pretty
much
be
able
to
do
whatever
your
csv
pipeline
can
do
against
your
kubernetes
cluster,
I'm
going
to
type
it
out
here,
just
so
that
everybody
can
appreciate.
This
shake
be
mindful
about
the
fact
that
I
have
already
by
the
time
you
see
this
particular
video.
A
I
have
already
erased
this
service
account
and
these
roles,
so
don't
even
try
to
hack
me
yeah
and,
as
you
can
see
it
pretty
much
looks
like
any
kind
of
cube,
config
out
there
with
the
certificate
authority
of
the
cluster
and
then
it's
a
token
based
authentication
for
people
who
are
fluent
in
reading
base64.
You
might
even
recognize
the
beginning
that
is
specific
for
jw
tokens,
and
this
is
what
will
identify
towards
the
commission's
api
that
well
you're.
Trying
to
connect
to
kubernetes
with
this
particular
service
account.
A
Okay,
now
that
we
actually
created
a
cube
config
that
has
everything
that
is
needed.
Let
me
now
show
you
how
to
actually
use
it,
and
this
part
is
very
specific
to
github
actions
but,
like
I
said
it
doesn't
need
to
be.
The
principles
are
pretty
much
the
same
for
gitlab
ci
or
for
jenkins
or
for
azure
devops,
so
I
have
already
created
a
small
fork
of
the
official
compliance
documentation.
A
The
reason
why
I
created
a
fork
is
because
I
didn't
want
to
add
a
github
action
for
this
particular
demo
in
the
public
documentation,
so
I
just
do
it.
In
my
private
repo
and
here
I
have
created
a
file
called
app
deploy,
which
contains
the
workload
workflow
that
is
specific
for
app
deployment
and
for
those
of
you
who
have
already
used
github
actions
before
this
must
feel
really
familiar.
So
I'm
basically
just
reacting
on
pushes
on
the
main
branch
I
set
here
some
environment
variables,
which
are
pretty
much
taken
from
the
documentation.
A
How
to
manually
configure
the
application
and
then
what
the
cicd
pipeline
is
doing,
and
you
tell
me
if
there
is
a
huge
difference
or
not,
but
as
you
can
see,
if
you
want
to
manually
deploy
your
application,
we
recommend
to
configure
a
few
environment
variables
and
that's
what
the
cicd
pipeline
is
also
doing,
and
afterwards
your
chance
really
essentially
need
to
run
help
upgrade,
and
that
is
exactly
I
I
just
copy
pasted
this
command.
I
didn't
really
think
it
through
or
process
it
or
anything
like
that.
A
A
So
in
this
particular
case,
I
basically
chose
to
send
the
cubeconfig
as
its
content
base64
encoded
as
a
secret
to
the
csd
pipeline,
which
then
needs
to
be
serialized
and
pretty
much
put
into
a
cubeconfig
and
then
in
order
to
make
cube
control
happy.
I'm
also
setting
some
permissions
to
make
sure
that
the
cubeconfig
is
not
world
readable,
which
kubernetes
cubecontrol
doesn't
really
like
to
see.
A
Okay
and
at
least
in
github
actions,
there
are
two
ways
of
setting
this
particular
secret:
either
you
make
it
a
repository
secret,
in
which
case
all
of
the,
in
which
case
that
secret
is
available
to
all
of
your
workflows
or
you
can
make
it
an
environment
secret,
in
which
case
you
have
to
specify
for
which
environment
whose
which
environment
secrets
do
you
need
in
this
particular
action.
And
then
you
have
a
little
bit
of
a
better
separation
right.
A
A
B
B
A
A
Github
will
have
detected
that
the
git
repository
has
changed
and
it
will
immediately
run
the
pipeline.
This
particular
pipeline
is
well
organized
in
the
steps
that
you
have
just
seen
pretty
much.
There
is
a
setup
cube,
config
step,
and
then
there
is
the
deploy
step
which
yeah
this.
This
particular
step
is
just
creating
the
cube
config
and
then
this
particular
step
is
just
running
home
upgrade,
as
you
have
seen.
Also
when
I
did
this
particular
step
manually
and
then
these
messages
should
also
be
familiar.
A
It's
pretty
much
what
you
would
have
seen
in
your
own
terminal.
Had
you
run
these
commands
manually
from
your
laptop
and
then
at
the
end
of
the
day
the
application
is
being
deployed
and
it
works,
and
I
can
actually
also
show
that.
Well,
I
typed
I
had
the
terminal
in
the
background
which
did
q
control,
get
odds,
minus
minus
watch
and
it's
pretty
much
what
you
would
expect,
so
the
containers
are
being
created,
they
they
are
being
set
to
running
and
everything
works.
A
A
A
A
A
There
is
a
bit
of
a
setup
time
right
until
my
particular
job
is
being
loaded
and
things
like
that,
but
eventually
it
killed
one
of
the
two
yeah.
Eventually
it
created
a
new
deployment
and
then
the
deployment
controller
killed
one
of
the
two
odds,
because
I
only
asked
for
a
replica
equal
one-
and
I
can
show
this
also
without
watch
just
to
make
sure
that.
Well,
I
can
demonstrate
that
indeed,
right
now,
there
is
only
one
pod
of
my
application
run.
A
A
If
you
also
want
continuous
integration,
then,
as
I
have
demonstrated
previously,
you
can
use
hardware
robot
accounts
and
then
you
use
those
as
a
secret
in
your
csd
pipeline
and
then
it's
pretty
much
the
same
principle.
You
just
docker,
build
docker,
sorry,
docker,
login,
docker,
build
docker
push
done
and
then
afterwards
you
would
need
to
seriously
think
about.
Do
you
want
to
do
ci
first,
so
pretty
much
just
create
container
images
based
on
source
code
and
then
do
ci
separately.
A
A
So
it's
and
I
wouldn't
say
that
there
is
a
better
or
worse
option.
I
think
that
you
simply
need
to
take
a
decision
on
that
document.
Why
you
made
that
particular
decision.
It
could
be
that
this
decision
also
needs
to
change.
So
maybe,
while
you're
a
fast-moving
company
with
few
users,
you
might
just
want
to
fuse
the
icd
together
just
to
get
code
shipped
as
quickly
as
possible.
A
But
then
later
as
your
product
matures
and
your
user
base
increases,
you
might
want
to
be
a
bit
more
careful
and
then
you
might
want
to
detach
cis
from
cd.
So
you
might
want
to,
for
example,
only
build
the
container
images
in
phase
one.
Then
you
might
want
to
have
a
cd
pipeline
that
pushes
all
of
those
changes
to
staging
to
maybe
a
user
acceptance
environment,
and
then
only
when
you
convince
yourself
that
everything
is
fine
push
those
changes
into
production
and
then
it
can
have
simpler
or
more
complicated.
A
Rollout
plans
again
depends
on
where
you
are
with
your
with
your
user
base,
basically
and
the
maturity
of
your
product,
and
what
are
you
more
worried
about?
Are
you
more
worried
about
time
time
or
are
you
more
worried
about
your
product
not
seeing
sufficient
uptake
whatever
your
choice,
kubernetes
can
has
a
solution
for
all
of
them.