►
From YouTube: How to secure your CD pipelines/workflow - 7 Tips
Description
GitLab CI/CD is one of the best solutions in this industry, however, when it comes to deployments, things get more complicated because some of the security features are involved. This video explains what's need to be configured to maximize the security on your deployment pipelines/workflow.
If you have any questions, please leave a comment below or create a new issue in GitLab open source project https://gitlab.com/gitlab-org/gitlab/-/issues/new.
References:
- Permissions: https://docs.gitlab.com/ee/user/permissions.html
- Protected branches: https://docs.gitlab.com/ee/user/project/protected_branches.html
- Protected variables: https://docs.gitlab.com/ee/ci/variables/#protect-a-custom-variable
- Protected environments: https://docs.gitlab.com/ee/ci/environments/protected_environments.html
- Set environment scope to variables: https://docs.gitlab.com/ee/ci/variables/#limit-the-environment-scopes-of-environment-variables
- Cross-project pipelines: https://docs.gitlab.com/ee/ci/multi_project_pipelines.html
A
Gillab
cicd
is
one
of
the
best
solutions
in
this
industry,
but
when
it
comes
to
cd
pipelines,
the
things
get
more
complicated
because
bunch
of
security
related
features
are
involved.
So
I
give
you
seven
tips:
how
to
secure
your
cd
pipelines
and,
let's
dive
into
it,
hey.
What's
up,
this
is
xinyan,
I'm
senior
engineer
in
goodluck.
I
sometimes
give
you
cool
tips
and
tricks
on
gitlab's
cicd
features.
This
channel
also
provides
more
company
activities
such
as
newly
introduced
features
in
upcoming
milestones.
A
So
if
you
are
interested,
please
consider
subscribing
the
bunch
of
security
features
that
are
available
for
protecting
uscid
workflow,
for
example,
protected
branches,
protected
tags,
protected
environments,
so
many
protected
features
out
there,
but
because
of
that
users
easily
get
confused
about
which
features
should
be
used
for
which
scene
which
proper?
What
purpose?
And
actually
I
saw
that
many
users
are
using
these
security
features
in
a
slightly
unexpected
way.
A
So
please
make
sure
that
you're
correctly
configure
these
things
without
further
ado,
I
give
you
your
first
tip,
so
the
first
step
I
give
you
is
that
setting
a
proper
load
to
team
members.
Now
there
are
five
roles
available
in
gitlab
guest,
reporter
developer,
maintainer
and
owner,
and
the
giving
permissions
increase
from
left
to
right.
So
the
guest
has
a
list
permission,
whereas
owner
has
a
full
control
on
your
project.
A
Now,
what's
important
here
is
that
maintaining
a
role
above
has
access
to
project
setting
this
project
setting
includes
all
of
the
product
features,
for
example
product
devaluables.
These
protected
valuables
also
tend
to
include
production
secret.
So
please
make
sure
that
if
the
person
has
access
to
production
environment,
then
the
person
should
be
maintaining
a
role
or
above,
but
if
the
person
should
not
have
access
to
production
environment
at
all,
then
the
person
should
be
developer,
developer
role
or
below
tip
number
two
is
protect
the
deployment
branch.
A
Now
in
a
typical
city
workflow.
Every
time
a
new
comet
is
merged
into
master
branch.
A
new
deployment
pipeline
is
created,
so
you
want
to
make
sure
that
going
to
project
setting,
protect
the
branch
rules
and
then
the
deployment
branch,
for
example,
master
branch
is
only
modifiable
by
maintaining
our
role
or
above
now
the
secret
behavior
of
this
feature
is
that
the
other
team
members
who
don't
have
access
to
the
protected
branch-
they
also
don't
have
a
permission
to
run
a
pipeline.
A
So
this
feature
is
useful
to
prevent
them
from
running
a
deployment
pipeline
accidentally
tip
number
three
is
protects
the
production
secret
now
without
secrets.
Your
deployment
job
will
never
succeed,
for
example,
deploying
to
aws
deploying
to
gcs
or
even
azure.
They
always
require
secrets
to
process
the
deployment
to
their
infrastructure.
Now
you
can
define
these
secrets
into
your
project
setting
and
the
variable
section,
but
you
want
to
make
sure
that
these
variables
are
protected
if
the
variables
are
protected.
These
variables
are
exposed
only
on
deployment
pipelines
on
protected
branches
in
the
other
world.
A
It
prevents
the
secrets
from
being
exposed
on
random
pipelines
on
random
future
branches.
Tip
number
four
is
protects
the
production
environment.
Now,
let's
assume
that
there
are
a
bunch
of
operators
and
then
developers
in
your
project,
and
some
of
them
has
maintained
a
role,
but
you
want
to
make
sure
that
only
operators
have
access
to
production
environment.
A
In
this
case
you
go
into
product
setting
and
then
protect
the
environment
section
and
create
a
renewal
that
production
environment
is
only
deployable
by
operators
by
doing
so
developers,
even
if
they
have
maintenance
role
are
losing
permission
to
execute
deployment.
Job
to
production
of
production,
server,
tip
number
five
set
the
environment
scope
to
the
protected
variables.
Now
we
covered
protected
branches,
variables,
environments
and
then
now
it's
time
to
set
the
environment
scope
so
implement.
The
scope
on
variable
is
basically
that
the
variables
expose
on
deployment
pipelines
to
production
environment.
A
Now,
let's
say
there
are
a
bunch
of
deployment
pipelines,
for
example,
deploying
to
staging
environments.
You
want
to
make
sure
that
the
production
secret
is
not
exposed
on
this
type
of
diplomatic
pipelines,
so
you
set
the
environment,
scope
and
then
deployment
pipelines
only
have
the
production
sequence
when
it
deploys
to
production
server.
Only
tip
number
six
define
the
production
secrets
on
runner
side.
Now.
What
is
runner
runner
is
an
actual
job
executor
for
your
pipeline
jobs.
A
For
example,
you
create
a
new
pipeline
on
your
project
and
the
pipeline
set
as
transitions
to
pending
to
running,
to
success
or
fail.
These
jobs
are
not
executed
in
globe
itself,
but
it's
executed
by
external
program
that
has
a
capability
to
actually
execute
the
deployment
scripts
that
defined
on
your
gila
yama.
A
Now,
if
you're
using
on
gitlab.com,
you
don't
need
to
do
anything
for
runners,
because
gila
provides
shared
runners
by
default,
but
when
it
comes
to
deploying
the
pipelines,
it's
worth
consulting
to
set
up
fronts
by
yourself,
because
it
has
more
flexibilities
that
now
you
can
define
production
secrets
on
random
side.
In
the
previous
tips,
we
covered
that
you
can
define
secrets
on
project
setting
variable
section,
but
now
you
can
move
these
things
to
run
outside.
By
doing
so,
you
can
effectively
prevent
the
other
maintenance
from
reading
the
secrets
unnecessarily.
A
When
you
set
up
a
new
runner,
there
are
two
checkpoints.
The
first
point
is
to
set
the
proper
run
attack.
Now,
when
you
register
a
new
runner,
cli
prompts
you
to
set
our
runner
tag
and
you
make
sure
that
the
tag
is
corresponding
to
the
tag
defined
on
git
level
yum.
The
second
point
is
that
to
make
sure
your
runner
is
protected,
you're
going
to
run
a
setting
page
and
make
sure
that
protect
checkbox
is
on.
By
doing
so,
runner
can
run
on
pipelines
on
protected
branches.
A
Only
by
using
these
options,
you
can
make
sure
that
the
runners
run
on
diploma
jobs
only
before
getting
to
the
last
tip.
Why
don't
you
smash
the
like
button
for
me?
If
you
get
the
value
out
of
this
video
tip
number
seven
is
to
separate
the
project
for
operators.
Let's
say
you
are
in
a
large
organization
and
large
project.
There
are
many
job
roles:
there:
release
managers,
operators,
salaries,
internet
managers,
engineering,
lead,
etc.
Question
is
what
role
do
you
give
to
them,
for
example,
engineering
leaders?
A
Maybe
they
should
have
maintainer
role
and,
of
course,
operators
should
have
a
maintenance
role,
because
they
need
access
to
products
and
environments.
There
are
so
many
maintenance
in
your
project.
The
problem
is
that
all
of
them
have
an
access
to
project
setting
that
might
include
production
secrets,
but
you
don't
want
some
of
them
to
access
to
the
secrets,
because
they
are
not
supposed
to
do
that.
So
how
do
you
solve
the
problem?
A
One
of
the
solutions
is
to
create
a
new
project
for
operators
and
moving
all
cd
configuration
to
the
new
project,
including
guillaume
celliamo,
and
assign
only
operators
to
the
new
project.
By
doing
so,
you
can
isolate
their
cd
permissions
from
the
original
project
and
prevent
developers
from
accessing
to
the
cd
configuration,
and
you
can
connect
the
developer
project
and
operator
project
by
cross
project
pipelines.
I
won't
go
into
the
details
of
cross
project
pipelines,
but
just
in
case
I
will
share
the
link
in
the
description
below
so
please
check
it
out.