►
From YouTube: Least Privilege Container Builds with Kaniko on GitLab
Description
How to build containers on GitLab CI without Docker privileged mode.
Companion working example project: Kaniko Docker Build - https://gitlab.com/guided-explorations/containers/kaniko-docker-build
If you find this helpful, please give the video a thumbs up and "star" the project :)
Join Darwin (DarwinJS) to review the concepts and some working example code that you can use directly!
Table of Contents:
00:00 - Intro
00:22 - Defining the Problem
01:44 - The Kaniko Solution
02:09 - Guided Exporations are Working Examples
03:04 - GitLab CI w/ Kaniko Walkthough
05:25 - Environment Scopes for Variables
06:52 - Adding CI Metadata Labels
07:11 - Adding Ad Hoc Tags at Build Time
08:06 - Kaniko Bug Workaround
08:47 - CI Pipeline Logs
09:22 - Viewing Results in Registries
09:47 - Tested Runner Types
10:05 - Links and Wrapup
A
Let's
take
a
look
at
the
original
problem,
so
this
problem
originates
when
we
have
to
use
docker
and
in
a
special
mode.
So
we'll
take
a
look,
quick
look
at
how
it
works
normally,
so
normally
you
build
up
a
docker
host,
you're
gonna,
put
an
operating
system
on
there
and
load
up
docker
and
turn
on
its
daemon
and
then
you're
going
to
put
docker
containers
on
there
now
built
into
the
framework.
Is
the
ability
to
block
specific
types
of
permissions
from
the
containers?
A
Not
all
things
are
blocked,
but
selectively
things
that
are
important,
that
we
would
be
would
compromised.
A
host
operating
system
are
blocked,
so
that's
kind
of
your
standard
operating
mode.
Now,
one
of
the
challenges
we
run
into
is
when
building
containers
using
docker.
We
have
to
enable
something
called
privileged
mode.
So
what
this
enables
is
we
are
able
to
have
full
permissions
from
whatever
docker
demon
has
on
that
host.
A
Those
full
permissions
are
passed
through
to
containers,
so
if
they
want
to
try
to
access
the
hosts,
they
can
access
it
with
whatever
permissions
the
demon
has,
and
so
of
course,
it's
a
big
problem.
You
probably
run
into
a
lot
of
guff
from
your
security
department,
understandably
they're
concerned
about
anything
like
this.
It
allows
full
permissions
to
the
operating
system
level
and
then,
if
you're
running
this
inside
of
a
cloud,
you
know
what
permissions
does
that
instance
have
within
that
cloud.
A
So
this
can
be
a
pretty
big
challenge
and
one
of
the
ways
it
has
emerged
to
address
this
is
Kanak.
Oh
now,
what
a
Kanaka
allows
us
to
do
is
keep
our
standard,
docker
daemon
configuration
and
still
be
able
to
generate
containers,
and
so,
when
we
built
do
those
container
builds,
we
still
have
the
permissions
blocking
that
we're
familiar
with
with
normal
docker
daemon
processes.
So
let's
take
a
look
at
how
we
do
this
now
in
gitlab.
This
particular
repository
is
available
publicly.
A
It's
something
we
call
guided
exploration
and
it's
designed
to
help
you
on
board
to
new
concepts
or
ideas
with
working
examples.
If
you
take
a
look
through
the
readme,
it
discusses
what
gitlab
features
are
needed
in
order
to
facilitate
this
particular
pattern.
It
talks
about
individual
patterns
that
are
necessary
in
order
to
do
this
build.
It
also
helps
you
understand
some
things
that
you
may
not
be
able
to
view
in
the
public
view,
so
you
can't
see
CIC
variables
in
this
this
particular
repository.
A
So
it's
telling
you
here
in
this
table
which
CIC
variables
you'll
need
to
create
to
make
the
entire
pattern
work
correctly.
It
also
talks
a
little
bit
about
other
cross
references
of
where
to
find
information
and
other
possible
uses
of
the
example.
So
guided
explorations
is
something
you
can
use
and
implement.
You
can
go
and
take
a
look
around
at
this
one,
and
you
can
also
grab
a
copy
into
your
own
group
or
your
own
instance.
Let's
take
a
look
up
the
yamo
file
and
see
exactly
what
is
happening
here
now.
A
We
do
have
some
extra
information
in
here
that
just
has
to
do
with
building
containers,
so
we'll
kind
of
skip
over
some
of
that.
But
first
of
all
we
have
the
image
name
right
here
and
this
particular
image.
As
of
the
recording
of
this
video,
the
image
I
had
to
use
is
almost
the
very,
very
latest,
so
almost
the
edge
image
for
debug.
We
do
need
to
use
the
debug
image
so
that
we
get
the
Clyde
that
we
needed
in
order
to
process
the
commands.
A
We
also
override
the
entry
point
right
here
so
that
we
can
do
our
own
operations
and
call
Kanaka
directly.
Then,
as
we
go
down
to
the
individuals
jobs
here,
we
can
see
a
couple
interesting
things.
So
the
first
thing
is
that
this
particular
container
required
me
to
create
the
Kanaka
folder.
So
I
don't
know
that
it's
completely
working
properly
that
may
not
be
possible
or
may
not
be
necessary
in
the
future,
but
the
way
that
I've
done
it
here
shouldn't
cause
you
a
problem.
A
If
that
folder
does
indeed
exist,
then
we
have
to
create
our
authorizations
and
in
this
case
we're
using
a
base64
encoding
so
that
whatever
characters
you
might
have
used
in
the
Nick
username
or
the
password
will
translate
correctly,
and
then
we
called
the
Kanna
co-executor
using
a
command
line.
The
command
line
is
rather
long
here,
let's
get
into
edit
mode,
so
we
can
see
it
a
little
bit
better.
A
So
our
canna
Co
command
line
is
calling
a
docker
file
with
our
project
directory
as
our
Kanaka
context,
and
then
our
destination
switch
is
how
we
set
up
tags
and
we
also
have
a
label
switch
as
well,
and
we
do
it
for
two
different
examples.
So
we
wanted
to
do
it
for
gitlab
CI,
the
built
in
container
registry
in
gitlab
and
then
also
for
docker
hub,
and
the
reason
is,
is
that
the
authentication
within
the
gitlab
CI
example
is
pretty
transparent
because
it's
using
built-in
variables
to
create
that.
A
So
these
variables
here
CI
registry
users,
the
AI
registry,
password
CI
registry
and
a
get
lab
job.
Those
are
all
automatically
set
to
be
the
registry
and
authentication
information.
That's
used
in
order
for
you
to
use
the
built-in
container
registry
right
here.
I
will
be
taking
a
look
at
that
in
a
minute,
but
because
of
that
it
can
be
kind
of
confusing,
then
to
understand.
Well
how
do
I
push
to
a
different
registry?
Maybe
I
want
to
push
the
docker
hub
or
an
ECR
in
Amazon
I?
A
Don't
I,
don't
want
to
use
the
built-in
one
or
I
want
to
use
both.
So
this
build
actually
does
both
and
what
it
does
is
it's
using
the
concept
of
an
environment
in
order
to
allow
us
to
set
a
different
set
of
variables
for
this
additional
build,
so
I'm
going
to
go
into
my
CI
CD
settings
and
we'll
take
a
look
at
the
variables
and
the
fact
that
they're
scoped
so
right
over
here,
you
can
see
this
list
of
variables
and
to
the
right
here.
The
scope
is
pushed
to
docker
hub.
A
A
It
wasn't
entirely
necessary
to
use
that
feature,
but
you
can
see
right
here
the
flexibility
that
it
allows
us
that
we
can
have
two
builds
going
to
two
different
locations
and
we
don't
have
to
do
a
lot
of
messing
around
with
how
to
do
the
variables
so
because
of
that
it
pulls
those
CI
CD
variables
from
the
variable
set
rather
than
using
the
default
ones
that
they
had.
Two
up
would
do
and
then
the
command
line
is
identical
as
far
as
the
processing
of
the
additional
docker
push.
A
So
that's
kind
of
the
CI
CD
variables
also
there's
a
couple
other
little
things
in
here
that
aren't
directly
to
do
with
lease
privilege
containers,
but
one
of
them
is
creating
a
bunch
of
labels
that
track
back
to
the
gitlab
CI
information.
So
this
creates
this
variable
with
all
of
these
label
commands.
It's
then
used
in
both
of
the
docker
push
commands
and
then
also
we
are
doing
we're
taking
a
list
of
additional
tags
that
you
could
give
us.
A
So
if
you
specify,
when
you
push
this
job,
whether
you
do
it
through
an
API
call,
whether
you
do
it
through
a
schedule
whether
you
do
it
through
the
run
pipeline,
you
can
give
a
variable
additional
tag
list
and
those
tags
will
also
be
added
on
to
any
image.
So
just
a
couple
of
little
tricks
for
containers
in
general,
also
the
canna
co-executor.
It
does
a
couple
things
and
it's
not
apparent
exactly
what
it's
doing,
because
you're
not
using
your
standard
docker
commands
what
the
chemical
executor
is
doing
is.
A
It
is
preauth
in
first
so
before
it
even
tries
to
build
the
image
it
goes
and
checks
if
it
can
get
into
the
registry.
You
can't
tell
if
it's
successful,
it
never
tells
you
that
it
did
that.
But
if
it
fails,
it'll
tell
you,
hey,
I
couldn't
touch
your
registry
and
then
at
the
end
of
course,
it
actually
pushes
the
image
at
the
end
of
the
build
and
the
problem
I
had
to
solve
and
why
I
needed
this
specific
container
was
I
would
pass
the
preauth
check.
A
But
then,
when
I
went
to
do
the
push
I
get
an
authentication
error.
So
if
you're
getting
that
specific
situation
where
you
pass
the
preauth
check,
but
then
you
get
an
authentication
error.
When
you
try
to
push
the
container,
it
might
be
due
to
the
version
of
the
can
of
coke
container
you're,
actually
using.
A
Let's
take
a
look
at
some
of
the
other
files
inside
of
our
just
at
the
docker
file,
so
the
docker
file
is
super
simple,
we're
just
using
busybox
and
we're
going
to
just
echo
to
the
screen
that
we
built
this
with
canna
code.
So
this
also
keeps
the
sample
very
small
as
far
as
hitting
the
container
registries.
A
A
And
then
the
same
for
pushing
to
get
lab,
so
it's
going
to
look
identical.
The
only
difference
is
our
CI
variables
that
we
talked
about
earlier.
In
addition,
let's
take
a
look
at
our
container
registries,
so
if
we
go
into
our
container
registry
right
here
in
get
lab,
we
can
see
that
we've
built
the
image
and
it's
pushed
it
with
the
requested
tags.
So
let's
also
take
a
look
at
the
image
out
on
docker
hub,
so
you
can
see
that
it
also
built
out
to
this
location
as
well.
A
So
you
can
use
this
to
build
to
any
container
register
you
want.
I
have
tested
it
on
get
lab
comm
shared
runners,
as
well
as
on
our
kubernetes
runner
on
my
own
cluster.
So
those
various
mechanisms
should
work
just
fine
and
if
you
have
any
problems
with
it
feel
free
to
reach
out
on
the
guided
exploration
repository
with
an
issue.
A
So
there's
the
guided
exploration
URL,
so
you
can
go
out
and
play
with
it
yourself.
You
can
either
look
at
the
results
or
make
a
copy
that
repository
and
get
playing
with
it
right
away.
Also,
if
you
need
any
help
figuring
out
your
container
build
scenarios,
I
really
love.
My
role
that
get
lab
is
the
solutions
architect,
because
we
get
to
help.
A
You
understand
what
it
is
that
we
can
do
with
the
tool
to
help
you
meet
your
objectives,
relieve
pain
points
and
see
ICD,
and
any
of
the
other
things
that
get
lab
can
do
for
you.
So
if
you'd
like
to
have
a
Solutions
Architect
help,
you
out
feel
free
to
get
in
touch
with
us
at
our
sales
URL
there,
and
we
can
get
someone
to
I
help
you
out.
So
thanks
a
lot.
I
hope
that
you're
gonna
be
happy
that
you
can
go
back
to
your
security
folks
and
tell
them
Nana
and
NF.