►
From YouTube: Pwning the CI Workflow and How to Prevent it
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
And
off
we
go
welcome
to
everyone.
Welcome
everyone
to
this
week's
cncf
live
webinar,
pawning,
the
ci
workflow,
and
how
to
prevent
it.
I'm
libby
schultz
and
I'll
be
moderating
today's
webinar
I'm
going
to
read
our
code
of
conduct
and
then
hand
over
to
stephen
giguere
and
barack
shaster
with
palo
alto
networks,
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee
there's
a
q,
a
box
on
the
right
hand,
side
of
your
screen,
the
chat
box.
A
Please
feel
free
to
drop
your
questions
there
and
we'll
get
to
as
many
as
we
can.
At
the
end.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct
and
please
be
respectful
of
all
of
your
fellow
participants
and
presenters.
B
Okay,
awesome
thanks
libby
yeah
welcome,
welcome
one
and
all
thank
you
to
the
cncf
for
hosting
this
webinar.
This
is
amazing.
This
is
pawning
the
ci,
the
github
action
edition
and
with
the
idea
that
we'll
eventually
maybe
do
a
gitlab
or
a
circle
ci
and
we'll
do
a
few
different
versions
as
we
as
our
research
progresses.
Let's
say
I'm
steve
jager.
This
is
this.
B
All
right,
so
the
the
obligatory
intros,
if
you've
never
seen
me,
do
anything
like
this.
Before
I'm
a
developer
advocate
at
bridge
crew
bridge
crew
by
prismacloud
at
palo
alto
networks,
I've
been
writing
code
since
1990
and
did
a
lot
of
quality.
Automation
worked
in
security
since
2014
for
a
bunch
of
different
companies.
If
you
find
yourself
in
london,
I
run
a
meetup
called
difficult.
C
Yeah,
I'm
I'm
a
friend
of
steve.
I
like
working
with
him
co-founder
and
city
of
richwood
that
was
acquired
a
year
ago
by
palo
alto
networks.
I
love
to
drink
wine.
So
if
you
have
any
recommendations
and
you
want
to
deliver
some
I'll
give
you
my
address
on
direct
messages
and
I
love
star
wars.
So
if
you
love,
if
you
have
spoilers
for
the
next
movie,
don't
share
them
over
dm.
B
Yes,
in
spite
of
founding
a
company
based
entirely
on
star
trek,
excellent
all
right.
Let's
that's
a
quick
whip
through
on
the
agenda
where
our
ci
today
I
already
mentioned,
is
going
to
be
github
actions.
We're
going
to
go
through
some
attack
vectors
and
we're
going
to
actually
do
some
of
the
attack
vectors
as
well,
which
is
the
exciting,
live
bit.
B
That's
going
to
go
completely
wrong,
probably
but
you'll
be
here
to
see
it
so
we'll
talk
about
the
threats,
the
different
positions
and
then,
of
course,
some
of
the
attack
vectors
we're
going
to
go
through
command
injection,
insecure
image
reference
we're
not
doing
that.
One
we're
going
to
talk
about
it.
A
B
I
I
mean,
but
I
should
probably
also
caveat
that
I'm
in
a
hotel
room,
so
internet
may
fluctuate,
so
I'm
gonna
turn
my
video
off
just
to
make
sure
that
I
I
minimize
the
disruption
for
now
setting
the
scene
a
little
bit.
I
I
want
to
talk
about
a
little
bit
about
the
os
top
ten,
because
in
2021
the
new
oauth
top
10
came
out
and
there
were
some
kind
of
significant
differences.
B
The
ones
that
we're
talking
about
today
is
that
misconfigurations
and
insecure
design
issues
came
up
at
well
kind
of
with
a
bullet
at
four
and
five,
and
that's
really
what
we're
talking
about
today.
The
move
to
cloud
native
has
meant
that
some
of
the
more
traditional
apsec
issues
like
input,
sanitization,
etc,
have
been
replaced
by
misconfigurations
and
supply
chain
risks,
which
is
which
is
fascinating,
and
that's
where
that's
really,
where
we're
going
to
focus
heavily
throughout
this
talk
all
right.
B
Github
actions
is
a
continuous
integration
or
and
or
continuous
delivery
system
that
allows
you
to
automate
your
build
test
and
deployment
pipeline
most
people
think
a
few
years
ago.
Github
is
just
where
you
put
your
code
and
now
you
can
actually
take
action
on
that
code
via
github
actions,
which
is
cool,
trigger
off
an
event,
and
then
your
runners
can
execute
different
steps
and
make
things
happen
and
we'll
see
some
of
that
shortly.
B
This
is
a
cut
and
paste
from
github's
documentation,
and
it's
intentional
because
of
the
way
they
give
examples
of
what
what
you
can
do
with
github
actions,
and
that
is
the
workflows
that
make
things
happen
are
in
a
specific
directory
called
github,
slash,
workflows
and
the
examples
that
they
get
give
are.
Perhaps
you
know
hypothetical
one
workflow
to
build
and
test
your
pull
requests
another
to
deploy
your
application
and
another
interesting
one
that
says,
you
can
add
a
workflow
to
add
a
label
every
time.
B
B
So
that's
like
crash
course
and
github
actions,
but
you'll
certainly
go
knee
deep
by
the
end
of
this
in
terms
of
what
it
is,
we're
going
to
do
now,
the
fundamental
problems
associated
with
github
actions-
and
this
is
maybe
something
that
we
would
say,
isn't
necessarily
a
design
issue.
But
it's
more
a
case
of
security
awareness
that
you
need
to
know
and
I'm
going
to
just
make
them
all
appear.
B
Github
can
and
often
will
run
a
new
workflow
that
you
create
in
the
github
workflows
path.
Even
if
that's
the
file
you
committed,
which
seems
probably
seems
kind
of
weird.
So
if
I,
if
I
create
a
new
commit-
and
it
happens
to
be
a
workflow
file-
that's
in
that
directory
and
you
can't
it
will
run
that
workflow
as
if
the
workflow
was
already
there,
which
is
like
seems
like
a
bit
of
a
paradox
and
it's
something
that
we're
going
to
play
with
and
we're
going
to,
let's
say,
create
some
abuse
cases
for
today.
B
The
second
one
we're
going
to
look
at
is
metadata,
like
the
name
of
an
issue,
for
example,
or
the
description
are
often
are
available
to
workflows.
Like
the
like
an
issue:
grooming,
one
that
we're
going
to
add
today
and
often
people.
There
are
a
lot
of
examples
out
there
where
people
are
using
those
inputs
for
a
variety
of
different
ways,
without
actually
checking
to
make
sure
that
something
malicious
hasn't
been
used
in
place
of
the.
A
B
B
Excellent,
okay,
so
we're
going
to
break
down
some
of
the
attack
vectors
we
mentioned
earlier
and
I'm
using
as
the
headlines
kind
of
the
suggestions
that
that
were
in
the
github
documentation.
I
do
a
lot
of
cutting
and
pasting
from
github
documentation
in
this
presentation,
so
the
idea
that
a
workflow
that
adds
a
label
every
time.
Someone
opens
a
new
issue.
B
The
example
where
we're
adding
a
workflow
to
build
and
test
pull
requests.
Well,
we
can
potentially
push
a
new
workflow
that
does
some
of
the
things
that
we
want
to
be
able
to
do
an
example
we've
got
here
is
I
could
push
a
workflow
that
actually
runs
a
command
to
the
github
api
that
will
auto
approve
my
own
comment,
my
own
pr,
which
is
weird
right,
but
it
is
possible
and
we're
going
to
talk
a
little
bit
more
about
the
power
of
the
built-in
github
token
that
is
associated
with
workflows
and,
of
course.
B
C
C
We
also
have
access
to
all
the
environment,
variables
connection
strings
for
databases,
even
if
they're
meant
to
be
used
in
tests
secrets
and
more
cpu
horsepower.
So
you
can
harvest
the
resources
of
that
machine
or
use
that
to
create
another
attack
or
learn
what
else
they're
out
there.
In
my
own
vpc
network.
B
B
I
want
to
push
the
approve
and
run
to
run
my
workflows,
and
I
guess
it's
psychologically
you
might
be
thinking
well,
my
workflows
run
all
sorts
of
security
checks,
and
so
of
course
I
want
them
to
run.
That
would
be
silly
for
me
not
to,
and
I
may
not
realize-
and
you
can
see
the
upward
arrow
there-
that
if
the
commit
is
a
workflow,
I'm
allowing
that
workflow
to
run
by
clicking
that
button,
which
is
kind
of
it,
can
be
easily
done.
B
C
B
Yeah
because
we're
humans-
and
we
love
to
click
it's
buttons,
and
so
the
idea
of
becoming
a
malicious
insider
is,
is
what
we're
going
to
kind
of
play
out
a
little
bit
today.
There's
a
lot
of
things
that
say
if
you're
a
first-time
contributor-
and
you
can
see,
there's
different
security
settings
down
there
in
the
in
this
image
from
the
github
settings.
So
you
can
require
approvals
for
first-time
contributors
who
are
new
to
github.
So
that's
probably
the
lowest
security.
B
The
default
is
the
middle
one
approval
for
first-time
contributors
and
then
all
outside
collaborators
with
the
default.
It's
actually
pretty
easy
to
become
a
first
time
contributor.
You
can
just
make
a
change
to
a
readme
file
or
do
something
quite
innocuous,
quite
simple.
So
then,
suddenly,
you
you're
past
some
of
these
initial
limitations
in
terms
of
what
you
can
and
can't
do.
So
it's
not
all
that
doesn't
require
all
that
much
real,
like
social
engineering.
To
make
that
happen.
B
C
C
It
has
secret
scanning,
it
has
unit
test.
It
has
a
static
analysis
test.
It
has
infrastructure,
as
code
configuration
tests,
a
bunch
of
a
lot
of
testing
to
make
sure
that
the
code
we
are
delivering
is
doing
what
it
should
from
the
business
logic,
reliable,
test
tested
and
secured,
and
it's
running
on
a
self-hosted
runner
on
our
own
vpc
on
our
own
segregated
environment.
C
C
If
I
had
aws
access
keys
to
gain
access
to
my
aws
access
keys,
where
my
self-hosted
runners
are
actually
running,
luckily,
we
had
some
controls
to
prevent
that
from
happening,
but
he
made
a
request
to
do
that.
Change
and
it
was
not
running,
but
if
I
would
have
the
default
configuration
or
a
bad
configuration,
and
I
would
have
hit
a
proven
run,
this
contributor
would
have
actually
have
our
set
of
environment
variables
printed
into
the
console.
A
B
C
B
That
would
potentially
present
a
login
form
that
say:
oh
you've
just
been
logged
out
of
github,
please
log
in
again
and
send
those
credentials
off
to
my
malicious
site,
so
a
very
dangerous
way
to
to
just
blindly
use
metadata.
That's
been
provided
without
thinking
about
how
how
how
you
should
do
it
and
it's
interesting,
because
it's
actually
quite
difficult
to
even
try
to
sanitize
that
content
so
best
to
not
do
that
be
careful
with
what
you
do
with
the
titles.
B
The
other
example
here
is
where,
if
we
search
I
can
there
are,
I
think
we
found
something
like
two
and
a
half
thousand
examples
where
people
were
echoing
the
issue
title
and
the
issue
body
into
the
log.
So
they
can
say
I'm
about
to
add
a
label
to
this
issue,
documentation
the
log
great
now
the
reality
is
well
what
happens
if
I
add
my
own
commands
to
the
issue
title
and
use
the
the
backtick,
as
you
can
see,
so
that
bash
executes
that
command
into
the
echo.
B
So
suddenly
I
have
remote
code
execution
inside
this
particular
issue
and,
let's,
let's
take
a
look
at
how
that's
going
to
play
out,
but
first
actually
I
should
introduce
you
to
the
many
moving
parts
that
are
part
of
this.
This
demo
on
this
side.
I
have
me
this
is
my
normal
github.
This
is
the
repo
that
I
have
made
in
prep
for
this
there's
a
workflow
in
it.
It
has
a
license
to
readme.
B
It's
very
big,
important,
read
both
lots
of
code,
there's
really
nothing
in
it
and
then
over
here
I
have
my
malicious
attacker.
Currently
is
an
external
person
because
loud
canadian,
as
this
person
is
called,
is
not
part
of
that
is
not
a
collaborator
in
that
repo
other
pieces
of
this
I
have
are.
I
have
a
site
here
called
webhook.site
and
that's
just
waiting
for
curl
commands
or
api
commands
to
to
reach
it.
So
it's
actually.
A
B
B
A
B
Labels-
I'm
just
going
to
do
the
echo
of
the
issue
title
and
I'm
going
to
suggest
that
this
is
something
this
is
my
first
contrib
contribution.
So
now
I
look
at
a
really
nice
person,
who's,
helping
and
suggesting
that
hey
on
your
site,
you
might
want
to
do
things
with
issues
and
and
that
that
is
it
so
I'm
going
to
propose
this
new
file.
B
We
can
see
the
pull
request
and
there's
our
approve
and
run,
and
I'm
pretty
happy
with
it.
I'm
going
to
take
a
look
at
the
files
that
changed
I'm
becoming
a
big
fan
of
loud
canadian,
because
oh
look
at
that
loud
kennedy
is
such
a
good
person
he's
trying
to
help
me
make
my
repo
better,
I'm
going
to
say,
approve
and
run.
B
B
B
Well,
what's
my
issue
going
to
be
it's
going
to
look
a
lot
like
and
I'm
going
to
cut
and
paste
it
because
there's
no
way
I'll
be
able
to
type
this
sensibly.
There's
my
backtick
paste
backtick.
So
this
is
the
first
potential
thing.
So
what
I'm
doing
here
is
I'm
going
to
get
all
the
environment
variables
I'm
going.
A
B
B
B
I
have
been
far
more
successful
than
the
attacker
on
chekhov.
I
now
have
all
the
environment
variables
and
poor
poor
borax,
aws
keys
are
out
in
are
sitting
in
my
in
my
public
repo,
so
I
can
go
from
there
not
too
bad.
Now.
This
is
a
gate
of
a
github
hosted
runner.
So
there's
nothing
really
of
any
damage
in
there.
But
you
can't
see,
though,
there's
an
awful
lot
of
information
even
on
a
github
hosted
runner
that
you
might
be
able
to
try
and
find
a
means
with
which
to.
B
C
Interim,
I
think
that
one
changing
the
logging
level
and
printing
more
data
out
that
you
wouldn't
want
to
print
usually
like
sensitive
data,
more
secrets
out
there
and
we
haven't-
talked
about
the
level
of
access.
The
github
token
is
giving
us,
but
I
guess
that
we
have
another
slide
on
it
later
on.
So
we'll
cover
this
later.
B
C
Environment
variables
can
actually
have
a
scope,
and
one
of
the
features
that
are
not
used
enough
in
github
is
the
ability
to
say
a
specific
environment.
Variable
belong
on
into
a
specific
environment,
for
example,
this
secret
belongs
to
production,
and
another
secret
belongs
to
them.
Scoping.
Those
environment
variables
is
enabling
us
to
have
environment
protection
rules
which
are
not
exactly
our
back,
but
there
are
a
set
of
controls
that
we
can
enforce,
for
example,
have
a
set
of
users
that
will
approve
any
usage
of
that
environment
variable.
C
And
within
that
pipeline
I
have
the
requirement
to
deploy
to
production
website.
My
website
is
called
github.com,
it
could
have
been
acme.com
or
something
else
who
is
the
allowed
practitioner
that
should
approve
any
change
to
my
production,
environment
or
a
set
of
practitioners?
If
I
want
two
people
to
have
their
eyes
on
that
last
change,
that's
fine
too.
I
can
create
an
environment
protection
rule
that
will
say
only
people.
Only
two
people
or
more
are
required
before
setting
up
a
new
version
of
github.com.
C
Another
thing
that
we
can
do
is
eliminate
the
need
of
putting
sensitive
data
in
environment
variables
and
secrets
from
the
first
place.
Github
have
exposed
the
ability
to
use
roles
and
assume
roles
to
have
ephemeral
access
of
our
self-hosted
runners.
So
let's
say
that
I
want
to
create
a
deployment
to
my
aws
account.
I
don't
have
to
use
aws
access
keys.
The
thing
that
I
can
do
is
I
can
use
the
zoom
role
and
to
get
to
have
temporal
access
and
within
aws.
C
I
can
limit
this
level
of
access,
even
if
it's
admin
required
for
deployment
to
come
only
from
a
specific
set
of
ip
addresses.
So
if
I'll
configure
all
of
the
deployments
to
come
from
a
trusted
ip
that
can
be
a
static
ip
within
a
trusted
subnet,
I
can
enforce
zero
trust
on
deployment
actions
that
are
happening
within
my
environment
and
I
will
not
have
any
access
keys
in
my
environment
variables
because
I'm
using
a
thermal
roles,
that's
another
option
to
protect
your
aws
tokens.
B
C
All
right,
let's
say
that
I
have
an
unsecured
workflow.
I
created
that,
but
it
could
have
been
a
legit
one
within
my
workflow
I'm
using
a
specific
image
for
my
job,
I'm
using
an
image
that
called
gay
kkws
nginx.
It
is
a
legitimate
or
looking
legitimate
image
that
will
create
a
web
server
within
my
integration
test
of
my
build
workflow,
but
on
the
next
slide,
we'll
see
that
actually
this
nginx
image
is
poisoned.
C
C
A
cryptid
or
cryptominer
will
be
executed
and
communicate
with
a
c2
server
just
because
the
image
that
I'm
using
is
not
a
lg
tool.
Now
this
image
used
to
be
existing
about
a
year
ago.
Docker
have
removed
it
from
the
docker
hub
registry.
But
let's
look
on
the
content
that
was
there.
Xm
rig
is
a
crypto
miner
that
can
be
executed,
and
the
entry
point
within
that
docker
file
was
just
renaming.
C
B
B
Now
I'm
going
to
combine
hack
three
and
four,
so
I
will
be
doing
three,
but
I'm
going
to
do
it
while
I'm
showing
you
four,
but
the
idea
here
is
just
to
introduce
you
to
the
concept
of
branch
protection
rules,
so
that
approvals
require
a
pull
request
before
merging
and
what
the
defaults
are
associated
with
that
because
by
default,
if
we
go
over
here,
my
my
branch
protection
is
off.
I
have
no
rules
whatsoever.
B
B
Fantastic
now
what's
interesting
about
this-
is
that
if
we
are
happy
with,
we
could
probably
do
a
whole
talk
just
on
all
of
these,
but
you
can
see
now
allow
force
pushes,
is
unticked,
there's
a
lot
of
set
very
good,
sensible
defaults
here,
we'll
talk
a
little
bit
at
the
end
about
requiring
sign,
commits
which
a
lot
of
people
don't
do
by
default,
and
that
requires
a
certain
amount
of
extra
work.
But
what
I've
highlighted
back
here
on
the
slide
is
the
very
teeny
tiny
awkwardly
positioned
one
there.
B
So
that
means
I
only
need
one
approval
and
okay
sounds
good,
but
at
least
I'm
doing
something.
The
good
news
is
that
branch
protection
rules
are
great
and
occasionally
maybe
the
d
and
the
defaults
are
actually
generally
pretty
good,
but
that's
one
interesting
default.
That
is
there
and
that's
what
we're
going
to
try
and
get
around.
So
we've
done
the
right
thing:
we've
got
our
branch
protection
on
there.
Now,
I'm
going.
A
B
A
B
B
A
B
B
B
B
If
we
want
to
look
at
a
little
bit
more
detail,
a
job
can
last
up
to
six
hours.
Actually,
it's
kind
of
a
long
time
I
mean
not
that
we
haven't
even
internally
exceeded
that
and
had
to
break
some
of
our
research,
but
it
means
okay.
I've
got
six
hours
of
life
for
a
single
job.
For
that
github
token
to
exist.
B
What
I
also
find
interesting
from
the
github
documentation
is
that
if,
for
some
reason
the
github
token
isn't
doing
what
you
want
it
to
do,
so
you
want
to
extend
the
capabilities
of
the
token.
Their
suggestion
is
to
create
a
personal
access
token
and
then
add
it
as
a
secret.
Now,
as
we've
already
discussed,
if
you
saw
the
way
that
I
export
exfiltrated
the
environment
variables,
if
I
could
do
the
same
with
secrets,
then
suddenly
I
would
have
a
potentially
significantly
persisting
github
token
that
doesn't
just
vanish
after
six
hours.
B
I
have
a
personal
access
token
that
might
do
some
real
damage,
and
so
here's
the
here's,
the
big
finish
now.
This
is
very
small,
so
I'm
going
to
zoom
in
on
there
and
show
an
example
of
what
I
could
do
in
a
workflow
now.
The
first
one
is
me,
echoing
all
of
those
secrets,
so
that
token
into
a
file,
and
then
I
send
that
file
to
myself,
just
like
I
did
before
with
the
environment
variables
out
to
my
malicious
web
webhook.site.
B
So
now,
if
there
is
a
github
token
that
is
potentially
significant
or
any
other
secrets
at
all,
I
have
all
of
them
and
then
afterwards
the
same
thing
that
I
did
on
the
issue.
Grooming
is
I'm
going
to
give
myself
all
the
environment
variables,
so
I
kind
of
am
attempting
to
get
the
keys
to
the
kingdom
out
of
this
particular
this
runner.
B
B
Is
an
organ:
there
was
a
particular
action
that
was
adding
to
the
capabilities
of
auto
merging
pull
requests,
and
in
order
to
do
this,
you
can
see
in
tiny
down
letters
down
there.
The
first
step
in
this
github
action
was
create
a
personal
access
token,
with
the
right
to
merge,
pull
requests
now
as
a
baddie
I'd
love
to
have
that
token.
That
would
be
fantastic,
because
not
only
could
I
approve,
but
I
could
emerge
so
that's
even
better.
B
So
then
I
went
and
searched
github
to
find
out
who
uses
this
auto
merge,
because
then
I
know
that
they
have
a
github
token
that
I
want,
because
otherwise
they
wouldn't
be
using
this
this
action
it
turns
out.
I
found
an
organization
I
made
that
name
up,
node
core
sure
that
makes
other
github
actions
and
they're
using
the
auto
merge
on
their
own
github
action
creation.
So
I
thought
excellent.
This
is
fantastic.
B
I
will
then
add
my
bad
code
to
that
action
and
suddenly,
I'm
in
one
of
those
bizarre
supply
chain
attacks
where
I'm
adding
codes
somewhere,
far
back
the
weak
link
in
the
supply
chain
and
people
who
are
using
that
are
now
somewhere
downstream,
and
it's
a
little
bit
like,
like
almost
like,
I
don't
say,
a
solar
winds,
but
I'm
I'm
manipulating
something
simply
because
there
was
an
over
privileged
github
token
that
I
was
able
to
extract
so
this.
This
is
a
hypothetical
scenario
that
I
may
have.
B
So
here's
here's
the
zoom
in
on
what
we
were
looking
at
earlier
and
then
you
can
see
I've
added
a
sleep
of
an
hour
so
for
some
reason
I
wanted
that
github
token
that
I
just
pulled
out
to
exist
and
I
wanted
an
hour
to
poke
around
with
it.
Okay,
I
can
submit
something
that
gives
me
a
bit
of
a
delay:
kind
of
cool.
B
B
So
not
only
do
I
have
all
the
keys,
but
I'm
actually
there
and
I
can
start
to
do
the
typical
pen,
testing
top
10
and
look
at
the
network.
Look
at
what
processes
are
running,
maybe
run
an
nmap
and
just
see
what
it
is
I
have
access
to
and
if
I,
as
barack
suggested,
if
I
have
access
to
a
particular
database,
I
can
kind
of
take
my
time
on
this
or
I
can
automate
what
I
want
to
do.
B
B
And
I'm
going
to
paste
in
that
huge
thing.
You
just
saw
called
big
c
I
2-
and
it's
rather
long,
so
I'm
going
to
get
a
lot
of
code
and
push
it
just
here.
Okay,
so
on
my
pull
request,
I
hope
this
is
a
not
too
small,
but
it's
going
to
come
in
and
it's
going
to
approve
the
pull
request
for
itself
and
then
start
to
run.
B
B
B
B
B
So
you
can
see,
I
should
I've
only
got
one
thing
here,
so
hopefully
that
works.
It
works.
It
says,
there's
one
review
required,
but
you
can
see
it's
actually
running
my
workflow,
I
don't
have
to
say,
approve
and
run
it's
actually
just
going
to
do
it,
which
is
kind
of
like
kind
of
crazy.
But
that's
what
that's
the
entire
thing
that
we're
trying
to
take
advantage
of.
C
B
Something
was
going
to
go
wrong.
My
approve
failed.
I
was
probably
something
a
permission
I
missed
somehow,
with
my
collaborator
to
auto,
approve
myself
darn,
but
that's
fine.
The
rest
of
it
was
worked
just
fine,
so
you
can
see
up
over
here
now
I
have
my
github
token,
my
environment
variables
and
a
login
on
the
runner,
even
though
the
approved
didn't
work.
That
is
actually
I'm
pretty
happy
with
that
and
things
I
can
do.
We
talked
about
many
things
that
I
could
do.
I
mean
something
that
is
sort
of
interesting
is.
A
B
C
B
B
B
B
B
C
B
So
that-
and
that
is
exactly
what
these
steps
do-
yeah-
that
when
they
work,
if
the
branches,
if
we
don't
rush
it
and
the
branch
works,
you
can
do
that,
you
can
delete
the
phone,
you
can
add
a
file,
you
can
add
it
to
somebody
else
and
when
you
come
back
over
here,
if
you
can
use
your
imagination,
the
pull
request.
Contents
will
change
away
from
being
the
workflow
content
and
that
will
just
be
an
instant
readme.
B
This
would
have
been
gone
and
there
would
have
been
something
very
innocent
there,
so
where
we
would
have
had
a
reverse
shell,
we
would
cover
our
tracks
and
now
that
we
only
have
eight
minutes
left,
I'm
out
of
time
to
actually
redo
this
again,
which
is
very
disappointing,
but
it
will
leave
you
in
suspense
next
time.
We
have
to
do
this
talk,
it
will
probably
work
better
and
I
should
always
record
my
live
demos,
just
in
case
they
blow
up.
B
But
the
best
practices
we
are
meant
to
learn
from
this
and
I'll
put
them
down
here
quickly
in
the
interest
of
time
yeah
and
we've
seen
all
of
them.
Turning
on
branch
production,
not
adding
permissive
github
tokens
using
a
short
life
span,
personal
access
to,
if
you
do,
go
that
route
and
give
that
token
as
little
privilege
as
you
as
it
needs,
don't
run
workflows
unless
you're
100
sure
be
careful
when
you're
adding
contributors,
because
it
could
be
a
social
engineering
kind
of
exercise
and
use
the
environments.
B
B
Nci
pipeline
is
code
just
like
what
we
just
saw
and
it
looks
rejects
from
github,
gitlab
and
bitbucket
more
brainworks
to
come
soon
and
the
other
all
my
windows
have
rearranged
an
example
of
that
being,
for
example,
if
I
was
to
run
check
up
as
simple
as
this.
On
the
example
files
that
I've
got
here
like
tell
me
a
secret.yaml,
we
can
see
that
it
runs
a
series
looking
for
curls
with
secrets,
looking
for
netcast
looking
for
ip
addresses
and,
of
course,
in
this
one,
it
found
that
I
was
trying
to
curl
out.
B
Because
can
you
run
it
as
your
first
github
action
to
make
sure
that
the
workflows
that
you're
about
to
approve
and
run
aren't
going
to
be
the
thing?
That's
malicious,
probably
a
good
idea.
I
would
think
because
you
can
find
that,
although
all
of
the
things
that
I
did
today
are
preventable
via
check
off
and
best
practices,
particularly
when
they
work,
we
only
have
five
minutes
left,
so
the
takeaways
secure
design
takes
work.
Unfortunately,
open
source
tools
are
there
to
help.
B
This
configurations
are
first
class
problems
defaults
as
usual
are
not
secure
and
pipelines
code
security
can
and
should
be
applied
to
all
phases
throughout
the
ci.
All
of
this
can
be
done
very
very
easily
and
with
the
help
of
additional
automation.
That
is
the
end.
I'm
sorry
that
big
finish
didn't
work.
That's
so
frustrating.
A
A
B
A
All
right,
well
steven
barack
thank
y'all
so
much.
I
know
you're
at
a
conference.
So
thank
you
very
much
for
taking
the
time,
and
I
hope
everyone
at
your
booth
enjoyed
this
too,
and
we
will
see
y'all
next
time
and
thank
you.
Everyone
for
joining
us
for
cncf
live
webinar.
Please
remember!
Next
week
we
will
not
have
any
online
programs
due
to
kubecon
cloud
native
con
europe,
and
hopefully
we
will
see
you
all
there
we'll
see
y'all
next
time.