►
From YouTube: Securing your Kubernetes Delivery Pipelines with Notary and TUF - Liam White & Michael Hough
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
Securing your Kubernetes Delivery Pipelines with Notary and TUF - Liam White & Michael Hough, IBM (Intermediate Skill Level)
As the cloud native ecosystem matures, the focus shifts more towards security. One of the key challenges in this area for enterprises is ensuring that you trust the code that's running in your production environment and that it hasn't been tampered with by malicious third parties. In this session, you'll learn about how Notary addresses this problem, how to get started with Notary and your image registry, and how you can use Kubernetes admission controllers to verify your images against Notary.
About Liam
Liam is part of the IBM Cloud Container Registry team and a core contributor to Istio. He works on the registry and its Notary integration and is currently leading the migration of the registry service onto Kubernetes and Istio. He is an advocate of open source technology both utilising and contributing to multiple projects.
About Michael
Michael works on the IBM Cloud Container Registry team. He has worked on code from the Docker Registry open source project, and is now focusing on integrating Notary with the Container Registry service. He has presented and led labs about Kubernetes and IBM Cloud Container Service at IBM conferences.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Okay,
so
welcome
to
our
talk
on
security
and
kubernetes
clusters,
with
no
three
and
tough
we're
going
to
talk
about
by
ensuring
the
security
of
container
workloads
using
trusted
images.
That's
kind
of
the
notary
part
of
things,
then
we're
gonna
talk
about
how
you
would
go
about
applying
this
to
your
cuban
entities
clusters.
We
can
introduce
our
open
source
solution
to
solve
this
problem
and
then
we're
going
to
go
through
a
bit
of
a
demo
of
it
in
action.
A
So
my
name
is
Liam
white
I'm,
a
software
engineer
at
IBM
cloud,
I
work
on
the
IBM
cloud
container
registry
team,
so
that's
dr.
registry
as
a
service
offering
for
IBM
clients
and
I'm,
also
a
core
contributor
on
sto
its
handles
up
there.
If
you've
got
any
feedback
on
the
talk,
let
me
know
and
if
it's
my
call
to
let
me
juice
himself
cool
my.
B
Name
is
Michael
I'm
on
the
same
team
as
Liam
and
I've
contributed
to
the
notary
project,
as
my
Twitter
and
github
credentials
feel
free
to
send
me
messages
if
you
have
any
questions
or
anything.
Okay,
so
I
want
to
kick
off
with
a
simple
statement.
Security
is
hard.
It's
a
really
challenging
problem
to
solve
effectively
with
security.
You
get
a
balancing
act
between
control
and
freedom,
the
more
towards
control.
You
go
little
slower,
you
can
move
and
there's
potentially
big
problems.
If
you
get
that
wrong,
there's
no
one-size-fits-all
solution
for
it
either.
B
Finding
the
right
balance
is
up
to
you
and
your
company
containers
have
improved
freedom
and
velocity,
but
does
that
come
at
the
cost
of
control?
If
you're
running
containers
in
your
production
environments,
how
can
you
make
sure
that
the
apps
that
run
inside
your
production
environments
are
what
you
think
they
are
then
that
you
trust
the
content
inside
them?
B
I'm
not
talking
about
who's,
deploying
here,
I'm
talking
about
what
the
problem
of
who
deploys
things
solve
by
our
back
configuration
inside
your
cluster
and
controlling
who
has
access
to
perform
operations,
but
if
you've
got
multiple
people
deploying
to
production
that
doesn't
control
what
they
deploy.
You
have
multiple
clusters,
maybe
for
your
development
and
your
staging
in
your
production.
What's
to
stop
somebody
who's
allowed
to
deploy
stuff
to
production,
accidentally
deploying
dev
code
there
or
a
third-party
app
that
hasn't
been
properly
audited,
speaking
of
which,
if
you've
got
requirements.
B
That
code
needs
to
be
vetted
by
certain
teams
like
security
or
QA
before
it
goes
to
production.
How
can
they
sign
off
on
a
release
before
that
goes
to
production,
and
is
there
a
digital
footprint
of
that
that
your
cluster
can
verify
and
assert
that
that's
been
carried
out
before,
allowing
that
to
be
deployed
and
that
the
content
that's
being
deployed
is
the
content
that
was
reviewed
in
the
first
place
that
didn't
work
died?
B
Okay,
what
about
the
bad
guys
as
well?
If
you
have
malicious
third
parties
that
get
access
to
your
container
registry,
how
can
you
protect
against
them?
Being
able
to
replace
your
production
app
code
with
something
nasty,
the
answer
to
that
is
to
digitally
sign.
It
trust
a
digital
contents,
a
solved
problem,
you
use
a
digital
signature,
but
where
do
you
store?
Those
signatures
for
container
images,
inter
notary
notary
is
a
CNC
F
project
that
allows
you
to
sign
stuff.
B
It
first
started
out
as
being
part
of
the
docker
trust
content,
trust
stack
and
it
allows
you
to
store
content
trusted
data
and
allows
you
to
verify
who
has
approved
it.
It
implements
a
specification
called
the
update
framework
which
is
designed
for
secure,
yet
flexible
verification
of
production
assets.
It's
got
handy
stuff
for
outage,
free
verification
of
things,
so
you
can
rotate
your
keys
easily
and
things
like
that.
It's
good
to
check
that
out.
The
website
was
in
the
keynotes
I
think
it
was
the
update
framework
Daioh.
B
Now
the
content
that
we
store
in
this
case
is
docker
image.
Digests
a
doctor
image
digest
is
the
sha-256
hash
of
the
image
content.
Now,
at
the
moment,
there's
no
known
vulnerabilities
that
in
sha-256
that
allow
you
to
replace
the
content
inside
something
with
something
that
has
gives
the
same
hash.
All
the
vulnerabilities
that
I'm
aware
of
at
least
have
allow
you
to
replace
a
hash
thing
with
some
other
beta,
but
basically,
if
you've
got
a
hash-
and
you
know
that
you
know
that
that
content
is
the
same.
B
B
So
how
do
that's
really
not
working?
Normally
when
you
pull
an
image,
docker
queries
the
registry
for
the
digest
associated
with
the
content
of
that
image,
in
this
case
I'm
using
simplified
language,
but
the
daemon
asks
the
registry
for
the
digest
for
have
been
to
latest.
The
registry
gives
you
that
and
then
it
sends
a
subsequent
request
to
the
registry
to
pull
the
content
for
that
repository
at
that
digest.
B
B
Now
why
not
just
use
docker
content
trust
as
it
comes
in
your
cluster?
You
can
go
on
to
your
cluster
workers
and
restart
the
docker
daemon,
just
with
the
flag
for
Stockert
wanted
trusts
to
be
turned
on
the
big
problem
with
doing
that
is
that
docker
content
trust
is
an
on
or
an
off
option.
If
it's
on
everything
has
to
be
signed.
If
it's
off
it
doesn't
verify
anything.
B
But
what,
if
there's
other
people
that
you
trust
some
things
like
the
coolest
images
aren't
necessarily
signed,
but
you
still
want
to
be
able
to
run
them
in
your
cluster.
If
you
want
to
run
Prometheus
or
things
like
that,
they
might
not
be
signed,
or
at
least
the
latest
versions
might
not.
You
might
need
to
decide
whether
you
want
to
copy
those
into
your
own
namespaces
and
sign
them
yourselves
and
we'll
audit
them
that
way,
but
yeah
it's
out
and
out
of
the
box.
Install
of
kubernetes
won't
behave
very
well.
B
If
you
just
turn
docker
content
trusts
on,
but
simply
dr.
Content,
Trust
isn't
powerful
enough
for
kubernetes.
Kubernetes
is
a
powerful
tool
that
deserves
powerful
trust
management
and
more
control
over
what
you
can
deploy
and
where,
rather
than
just
disabling
dct
on
you're,
not
sorry
enabling
DCT
on
your
nodes.
So
we
need
an
application
that
enables
the
clusters
to
communicate
with
the
trust
server.
B
A
Works
again,
Lee,
it's
my
clicker,
maybe
only
works
for
me.
So
admission
controllers,
admission
trollers
are
basically
web
hooks
that
you're
triggered
during
these
resource
creation.
So
if
you
go
into
the
background
of
what
happens
when
you
create
a
resource
in
coop
or
workloads
or
pod,
something
like
that,
you
create
the
resource
with
cube
seats,
you'll
apply.
The
API
server
receives
that
request
request.
A
So
recently
you
have
added
the
ability
to
add
custom
admission
controllers,
so
these
customer
mission
controllers
work
in
the
same
way
that
the
built-in
ones
work
it's
that
trigger
during
the
creation
of
the
object
by
the
API
server.
So
after
after
authentication
and
authorization
against
the
API
server,
the
cube
AP,
the
cube
api
serve
and
then
reach
out
to
some
of
these
admission
web
hooks
and
they'll
respond
with
the
correct
or
they'll
respond
with
their
the
relevant
information.
The
customization
of
a
c
or
additional
acs
allows
you
to
add
the
custom
mutation.
A
So
that's
that's
how
you
would
go
ahead
and
fix
the
digest.
So
there
are
two
types
of
workbooks.
This
me
buzzing.
There
are
two
types
of
web
hooks
that
are
interest
to
us,
so
we've
got
validates
commission
web
hooks,
which
were
added
in
coupon
a
and
validates
commission
web
hooks
are
basically
a
yes
or
no.
You
can't
deploy
this
thing
and
then
we've
got
mutate.
Commission,
web
hooks
and
mutating
admission
web
hooks
are
basically
a
yes,
you
can
deploy
this
if
you
apply
these
patches
or
no
you're
not
allowed
to
deploy
this
at
all.
A
So
how
does
this
relate
to
notary?
Well,
like
Michael
mentioned
earlier,
when
you
create
generally,
when
you
create
an
workload
in
communities,
you're
going
to
give
it
the
full
image
name
with
the
tag
and
like
again
like
Michael,
said:
that's
not
immutable,
that's
just
a
pointer
to
a
digest
somewhere
and
how
to
add.
So
how
do
we
know
someone
hasn't
pushed
over
top
of
this?
What
we
want
is
something
immutable.
So
what
we
want
is
something
looks
like
that,
which
is
the
digest,
and
preferably
we
want
to
be
able
to
ask
notary.
A
So
if
you
install
the
mutating
web
book,
this
is
kind
of
the
flow
you
would
do
with
no
true
so
resource
creation
request
comes
in
the
API
server
will
call
out
to
your
mutating
in
webhook.
The
mutating
emission
webhook
will
ask
notary
for
the
trust
information
for
all
of
that
image
repository
so
for
every
tag
basic.
Basically,
it
will
give
you
a
collection
of
digests
back
and
it
will
send
the
signatures
back.
A
Like
micro
mentions,
the
mutating
webhook
will
then
look
for
the
most
recent
trusted
digest
and
mutate
the
sent
back,
a
mutation
request
to
the
API
server.
So
what
do
these
look
like?
This
is
kind
of
this?
Is
generic
admission
or
mutation,
emission,
webhook
requests
or
general
requests?
I
think
is
all
admission
across
right
yeah.
So
if
you
wanted
to
use
your
own,
you
can
use
some
of
this
information
as
well,
but
I'm
gonna
give
it
a
specific
example
of
what
we're
doing
so.
A
This
is
the
API
server
calling
out
to
the
web
hook.
It
has
a
UID
as
that
it
has
a
kind
and
a
resource
which
is
bottom
pods
in
this
case,
as
the
namespace,
the
requester
workloads
being
deployed
into
and
that
it
has
the
operation.
So
this
is
a
create
and
then
it
has
the
object,
which
is
the
Jason
bye
slice
of
the
actual
objects
you're
trying
to
create.
A
So
what,
basically,
this
request
is
saying
is
someone
is
trying
to
create
a
pods
in
the
default
namespace?
Our
response
is
this
an
omission
response
struct.
It
looks
something
like
this,
so
we've
got
the
UID
again
that
will
have
to
match
the
UID
of
the
admission
request.
We've
got
a
large.
This
is
the
true
or
false.
Yes,
you're
allowed
to
deploy
this.
If
you're
not
allowed
to
deploy
this,
it's
usually
useful
to
give
a
to
give
the
API
server
a
message
to
give
back
to
the
user.
A
So
this
particular
one
isn't
a
very
useful
image
message,
because,
just
as
on
Trust
image,
we
usually
give
better
error
messages
than
that,
but
this
is
just
an
example
and
we're
gonna
return.
The
four
or
one
code,
though
now
it'll,
also
have
to
contain
a
patch
type.
So
this
is
Jason
patch
widths,
which
is
an
ITF
standard
and
the
patch
itself,
which
is
a
white
slice
of
a
slice
of
patches.
So
what
does
a
patch
look
like
again?
A
This
is
just
the
ICF
Jason
Pat
standard
we've
got
the
operation
which
is
replace
we're
saying
to
the
API
server
I
want
you
to
replace
the
first
container
in
the
pots
back
and
the
image
field
in
that
first
container.
That's
what
that
container,
/
0,
/
images
and
then
the
value
I
want
you
to
replace
it
with.
So
what
we've
now
effectively
done
is
we've
taken
the
tag
that
you
asked
to
be
created
and
we've
verified
with
notary
that
this
is
the
digest
you
actually
wanted
and
that's
what
we're
going
to
deploy.
A
So
we've
come
up
with
an
open
source
solution
for
this
problem.
It's
called
port
CRS
port
CRS
means
gatekeeper
in
Greek,
because
all
good
kubernetes
projects
have
to
be
in
Greek.
It's
open
source
and
available
here
on
github.com
/
y
vm,
/
port
tiaras.
Currently
we
only
support
the
IBM
cloud
notary
server,
but
we're
happy
to
work
with
people
to
support
your
your
notary
instances.
A
The
reason
that
this
isn't
necessarily
a
trivial
task
is
because
you
have
to
map
the
notary
server
to
the
registry
that
it
talks
to,
and
that's
obviously
going
to
be
via
the
image
name
and
with
with
our
own
one.
We
obviously
know
how
how
that
maps
and
that
type
of
thing,
but
with
more
generic
solutions,
we
need
to
come
up
with
a
more
for
more
generic
notary
server
instances.
We
need
to
come
up
with
a
more
generic
solution,
so,
like
I,
said
we're
happy
to
work
with
other
people
that
support
your
support.
A
Others
know
treants
notary
instances
so
as
a
security
tool
that
was
designed
with
security
in
mind.
So
if
you
haven't
got
any
policies
in
any
of
so,
if
you
haven't
defined
any
policies,
we're
just
going
to
blanket
block
everything.
The
idea
is,
you
have
the
whitelist
images,
so
that's
general
security,
best
practice
of
whitelisting,
rather
than
blacklisting.
We
fell
close.
A
So
if
you
have
running,
if
you're,
managing
a
multi-tenant
cluster
for
a
group
of
developers,
you
can
define
specific
policies
for
specific
namespaces
kind
of,
like
you
do
with
cluster
rolls
and
rolls
this
similar
thing
and
we've
written
it
in
a
way
so
that
it's
easier
to
build
other
image
checks
on
top
of
it.
So
what
this
means
is,
if
you
want
to
do
other
image
validation,
you
can
reuse
a
lot
of
our
libraries
and
our
code
and
that
type
of
things
so
internally
the
IBM
cloud
registry
has
a
vulnerability
advisor
internally.
A
We
have
code
that
reuses
a
lot
of
the
open
source
code
and
then
it
builds
on
top
of
the
CID.
You
have
to
do
some
CID
regeneration
regeneration
of
the
client
set
code,
so
people
who
have
written
controllers
before
know
that
there's
a
CID
generation
for
the
client
set
so
you'd
have
to
do
that
and
then
obviously
you
have
to
write
your
own
custom
code
to
handle
that
policy
when
it
comes
in.
A
But
it's
relatively
easy.
So
this
is
our
cluster
image
policy
definition,
so
basic
cube,
CID
we've
got
a
policy
spec
and
the
repositories
field
or
the
repositories
here,
which
is
a
slice
of
basically
docker
repository
repository.
Sorry.
So
what
this
one
is
basically
saying
is
I
want
oak
cluster
wide
I
only
want
images
from
the
limb
white,
slash
Kubik,
on
docker
hub
namespace,
as
long
as
they've
been
signed
by
someone,
there's,
no
trust
pinning
here.
This
is
just
a
blanket
someone
has
signed
them.
That's
not
very
realistic
example.
So
it's
gone
to
more
realistic
example.
A
So,
again,
cluster
white
image
policy
and
what
this
one
basically
says
is
I
want
to
be
able
to
deploy
anything
from
the
Liam
white
namespace
on
docker
hub
as
long
as
it
has
been
signed
by
this
public
key
in
this
secret.
So
that's
what
that
sign
of
secrets
field
is
there
and
the
secret
name.
So
this
is
what
the
secret
will
look
like.
This
is
obviously
just
create
a
normal
cube
secret.
A
The
metadata
name
has
to
match
a
sign,
a
secret
name
that
was
listed
in
the
classroom,
each
policy,
so
that's
secret
name
there,
so
we
can
find
it
and
then
the
data
itself.
So
the
name
has
to
be
the
sign
of
role
that
you're
looking
for
so
that
might
be
the
QA
team,
the
security
team.
That's
that
type
of
thing.
That's
we
need
to
check
for,
and
then
the
public
key
is
their
public
key
that
matches,
obviously
the
private
key
pair
or
it
matches
the
private
key
of
the
person.
Who's
actually
signed
the
image.
A
Now,
if
you
want
some
kubernetes
namespace
granularity
as
opposed
to
the
registry
namespace,
which
is
a
slightly
different
concept.
So
if
you
want
to
be
able
to
enforce
on
just
a
specific
namespace,
then
you
would
define
something
like
this.
This
is
exactly
the
same
cluster
wide
policy,
but
now
we're
just
enforcing
it
on
a
single
namespace,
so
partly
due
to
time
constraints,
but
mostly
because
we're
cowards
we've
got
a
pre-recorded
demo,
so
I'll
hand
over
to
Michael
and
Michael
can
graduate
to
it.
You
don't
need
that.
B
Okay,
good
start.
Okay,
so
Porteous
is
a
home
chart.
So
the
first
thing
I'm
going
to
do
is
install
helm
and
initialize
it
to
install
tiller.
Then
I'm
gonna
clone
the
github
port
ers
project
to
just
change
directory
to
where
the
Helms
is
next
thing.
I'm
gonna
do
is
install
the
channel,
that's
just
a
helm,
install
you
can
dive
a
little
bit
more
into
what
this
is
doing
in
the
top
left.
That's
cube,
CTL
get
or
just
to
show
everything
happening.
B
Bottom
left
is
our
jobs
just
to
show
you
our
C
IDs
and
things
like
that
being
created.
Top
right
is
the
CRTs
themselves,
and
the
bottom
right
is
that
image
of
Mission
config.
That's
our
mutating
admission
web
hook
right
there,
so
the
jobs
are
all
done.
So
that's
pretty
much
done
and
ready
to
switch
back
cool
and
you
get
a
nice
message
to
say
when
done
install
so
never
look
more
into
that
mutating
web
app.
We
create
a
figuration
called
image
admission,
convict
we're
looking
at
us
all.
B
The
way
down
here
create
an
update
on
a
whole
bunch
of
resources.
There's
that
failure
policy
to
say
fail.
That
will
tell
the
cube
API
server
that
if
it's
not
there
to
respond
to
a
request
to
deny
it
okay,
let's
start
deploying
some
stuff.
First,
let's
have
a
look
at
that
cluster
image
policy.
So
we
install
a
cluster
image
policy
by
default
and
the
requirements
on
that
are
to
enforce
trust
for
every
image.
So
you've
got
name
star,
Trust
enabled
tree.
B
So
if
I
go
and
have
a
look
at
a
workload
and
just
move
into
my
playground
and
look
at
Liberty,
so
Liberty
is
a
IBM
application
server.
It's
just
a
handy
image
to
pull
from
at
the
moment,
that's
pulling
from
my
private
unsigned
image
of
IBM
Liberty.
So
if
I
quit
that
and
then
issue
a
cube,
apply,
I've
aliased
keep
CTL
to
a
plot
to
K,
because
I'm
lazy,
but
you
see
no
valid
trust
data
for
unsigned
unsigned.
It's
that
tag
at
the
end,
but
it's
just
handy
that
fits
there.
B
So
now,
if
I
go
and
edit
the
cluster
image
policy
and
go
and
disable
that
so
Trust
to
disabled
I'll
set
that
to
false
now,
when
I
try
to
issue
that
same
deployment
again
so
I'm,
just
gonna
K
apply
Liberty
Gamal
again
without
changing
the
file.
That's
all
that's
allowed.
You
need
to
keep
an
eye
out
and
make
sure
that
you
put
proper
are
back
on
your
policies
because
of
that,
in
this
case,
I'm
gonna
go
have
a
look
at
to
that
pod
and
just
show
down
at
the
bottom
in
the
logs.
B
And
man
I
type
slowly
so
now
I'm
going
to
deploy
a
signed
workload.
Now
IBM's
public
images
are
all
signed.
So
that's
a
really
handy
image
to
use
so
I'm
going
to
use
the
IBM
Liberty
public
image
from
the
bluemix
registry,
so
I've
just
changed
that
yeah.
The
different
image
that
is
now
signed,
I'll
apply
that
and
that's
deployed
so
with
trusts,
enabled
and
signed
image
gets
deployed
and
when
I
then
should
go
and
show
the
container
that
one
has
been
mutated,
so
container
image
that
digests
well.
B
B
So
that's
just
a
docker
push
is
exactly
the
same
way
as
before,
but
this
time
after
pushing
the
image,
it's
also
going
to
push
on
trust
data
into
the
notary
server.
So
that
will
prompt
me
to
generate
some
keys,
excellent
and
now
that's
a
signed
image
and
that's
signed
in
my
private
in
my
private
namespace
in
the
container
registry
and
I
can
edit
that
deployment
put
that
signed
image
into
the
deployment
and
deploy
that
with
the
trust
verification
enabled.
B
Let's
go
one
step
further,
though,
and
do
proper
trust
pinning.
So,
firstly,
we
need
a
signer
keeper,
so
for
that
let's
generate
one.
We
use
docker
trust
key
generate
the
dr.
trois
commands
anew
in
docker,
1712,
I,
think
and
they've
just
come
out
of
experimental,
but
they
handy
to
interact
with
notary,
so
I've
created
a
public
key
pair
there's
the
public
key,
the
private
key
automatically
gets
injected
into
my
daughter,
trust
chain
and
I.
Don't
need
to
worry
about
it.
B
B
That's
what
I
generated
just
so
happens
that
I
like
more
pigeons,
just
a
thing
that
asked
me
for
the
repository
key
just
to
prove
that
I
have
the
ability
to
add
signers
into
that
repository,
it's
sort
of
an
authentication
by
keys
and
now
I'll
just
issue
a
sign
command,
because
I've
got
that
private
key
on
my
machine.
I
can
issue
a
sign,
and
this
time
it's
asked
me
for
the
mole
pigeon
key.
B
So
now
that
image
that
we
pushed
before
is
signed
using
my
mole
pigeon
key
just
to
prove
that
I
was
going
to
do
docker
trust
inspect
you
have
to
give
that
the
pretty
command
now
to
make
it
not
Jason,
but
they
go
and
they
go.
So
that
shows
that
the
latest
tag
up
there
has
that
digest
and
has
been
signed
by
Moulton.
B
B
That's
the
name
of
the
secret
that
I
created
okay.
So
now,
if
I
were
to
go
and
look
at
the
workload
that
I
was
pushing
before
that's
working
off
of
the
trust.
The
signed
public
image-
that's
not
signed
by
me.
So
when
I
equip
this
and
I
apply
that
into
the
cluster,
that's
rejected
with
a
slightly
less
pleasant
message,
but
there
you
go,
but
you
can
see
at
the
bottom,
no
signature
found
for
role
null
pigeon.
B
And
that's
all
that's
what
I've
got
and
that
will
show
that
that
that
pod
has
been
mutated.
You
can
use
that
configuration
to
basically
set
that
as
fine-grained
or
not
fine-grained
as
much
as
you
want
it
anywhere
in
your
cluster.
If
you
have
multiple
namespaces,
that's
weird:
if
you
have
multiple
next
phases,
you
can
add
different
policies
for
different
teams
to
scale
up
to
whatever
size,
Enterprise
you've
got.
A
Okay,
so
that's
the
end
of
our
talk:
I'll
toot
answers
on
there.
If
you
have
any
feedback
or
further
questions
on
poor
TRS,
we
can
probably
also
answer
some
questions
on
notary
as
well.
We
like
to
ask
you
to
go,
get
another
play
around
with
it.
If
they're
only
you've
got
if
you
come
across
any
issues
or
you
have
any
feature,
requests
just
raising
it
on
github
and
with
that
we'll
take
questions.
B
A
B
B
The
question
was:
how
would
we
integrate
it
with
a
CID
CI
CD
pipeline?
So
basically
you
just
install
it
into
your
cluster
and
as
long
as
your
CI
CD
is
sending
request,
queue,
API,
server
or
doing
coop
CTL
apply
or
things
like
that,
and
then
the
emission
webhook
will
run
yeah.
It's
the
same
installation
policy
as
before
everything
goes
through
the
mission
webhook
you.
B
Yeah
they
yeah,
then.
In
that
case
you
have
to
have
docker
content.
Trust
turned
on
in
order
to
push
the
images
and
you
have
to
give
your
CI
the
signing
keys
as
well.
So
sorry,
the
public
images
in
the
bluemix
registry
are
pushed
using,
say,
ICD.
The
CI
just
has
a
key
that
we
pull
in
from
store.
You
know
back
in
yes,.
C
B
B
So
that's
what
I
did
with
the
daca
trust
sign
command.
That
image
was
already
in
the
registry
and
that
wasn't
adjusted
as
long
as
the
local
machine
is
aware
of
that
being
the
signed
image
and
it
has
the
latest
trust
data.
So
in
other
words,
if
you
turned
up
a
Content
trust
on
before
you
pull
the
image
in
order
to
run
your
tests,
then
you
can
yeah.