►
From YouTube: OpenShift Commons Briefing: Securing OKD at Multiple Layers - Marc Boorshtein (Tremolo Security)
Description
Case Study: Securing OKD at Multiple Layers with Marc Boorshtein (Tremolo Security) Edit
Dec 19 @ 9:00 am
Case Study presentation on Securing OKD at multiple layers – OKD, FreeIPA, OPA and OpenUnison. Marc Boorshtein of Tremolo Security will do a deep dive into securing an OKD (Red Hat's OpenShift open source) deployment both at the OKD level and at the host level. We’ll also walk through how we integrated OPA to provide both validating webhooks and mutating webhooks for injecting Kerberos keys into containers for accessing Windows file shares and SQL Server databases.
Slides: https://blog.openshift.com/wp-content/uploads/OpenShift-Commons-Briefing-Securing-OKD-Tremolo-Security.pdf
A
Well,
hello,
everybody
and
welcome
again
for
joining
us
for
another
OpenShift
Commons
briefing.
Today
we
have
one
of
my
good
friends,
Marc
portioning
from
tremolos
security,
giving
us
our
last
openshift
Commons
briefing
of
2018.
It's
been
quite
a
year.
We
just
came
off
pucon
and
Marc,
and
everyone
was
there,
so
it
was
great
to
catch
up
with
him
there,
but
we're
really
pleased
to
have
him
again
talking
about
securing
okd,
in
other
words,
OpenShift
open-source
version
which
is
been
renamed
recently.
Okay,
be
from
origin.
A
If
that
looks
unfamiliar
to
you,
you
go
to
ok
di,
oh
and
you
can
get
all
of
the
same
stuff
that
you
ever
got
before,
just
renamed
it
and
I'm
gonna.
Let
Marc
introduce
himself
and
take
it
away.
We'll
have
live
Q&A
at
the
end.
If
you
have
any
questions,
and
this
recording
will
get
posted
on
YouTube
later
this
afternoon,
so
take
it
away.
Marc
thanks.
B
Diane
and
thanks
again
for
letting
us
come
on
and
share
our
experiences
here,
so
we're
gonna
be
telling
two
story
from
this
presentation.
The
first
is
looking
at
here
to
get
multiple
layers
in
okd.
So
a
lot
of
times
folks
will
talk
about
container
security
or
they'll
talk
about
the
authentication
process.
We're
gonna
look
at
from
the
host
all
the
way
up
to
the
container
and
vice
versa.
So
we're
gonna,
look
at
that
from
multiple
layers
and
then
the
second
story,
we're
going
to
tell
is
accessing
Windows
resources.
B
One
of
the
things
that
makes
this
customer
so
interesting
is
that
they
are
working
in
a
legacy
Windows
world.
They
wanted
that
they
have
information,
that's
locked
up
in
Windows
resources
and
so
marrying
the
cloud
native
ideas
in
openshift
with
the
legacy
world
of
Windows.
So
so
we're
going
to
be
telling
both
those
stories
so
real,
quick
who
are
we
tremolo
security?
And
what
do
we
do
so?
B
Our
slogan
cloud
native
Identity,
Management,
and
so
what
that
means
to
us
is
that
we're
small
or,
like
dynamic
you'll,
often
find
us
spending
a
lot
of
time
in
Cabernets
and
openshift
communities.
We
also
have
integrations
with
popular
content
management
systems,
so
wordpress
drupal
sharepoint
pretty
much
any
application.
You
can
think
of.
We've
probably
done
integration
with
it,
dotnet,
etc.
We
also
integrate
at
the
system
host
level
and
the
infrastructure
level
where
we're
going
to
be
talking
a
lot
today,
and
so,
if
you
check
our
website,
we've
no
great
integrations
there.
B
B
They
want
a
secondary
place
to
store
authorization
data
and
then,
when
they
access,
sifts
and
sequel
server,
they
had
to
do
it
as
the
user
running
the
application.
So
it's
I
mark
or
Sheen
I'm,
going
to
log
in
and
do
some
work
and
my
applications
are
going
to
start
talking
to
these
sifts
drives
discuss
to
think
that
it's
mark.
It
can't
be
a
service
account
doing
and
that's
needed
for
compliance
reasons
on
their
end,
and
then
they
want
to
have
Kerberos,
aware
pods.
They
didn't
just
want
to
have
to
inject
credentials
into
an
application.
B
People
didn't
want
to
have
to
do
all
this
manually,
and
you
know,
of
course
everything
needs
to
be
done
securely,
so
we
started
off
talking
about
the
layers
of
a
lot
of
times.
Folks
talk
about
authentication,
but
you
know
you
always
want
to
have
multiple
overlapping
layers
of
security.
So
that
way,
if
one
way
or
fails,
there's
something
to
back
it
up.
So
the
network
side
you're
talking
about
firewall
right,
you
know
at
the
front
door
to
open
creation.
B
You
know-
and
you
also
want
make
sure
that
folks,
that
don't
have
access
to
certain
resources
can't
get
to
it,
so
you
have
authorization
and
then,
where
the
the
coarse-grain
ability
of
kubernetes
are
back
solutions
fail
or
aren't
fine-grained
enough.
Now
you
have
a
tool
and
admission
controllers.
There
are
more
details
that
we're
going
to
talk
about
here,
so
openshift
provides
things
like
SCC's,
so
that
gives
you
the
ability
to
define
what
your
pod
can
do.
B
B
We
decided
to
go
with
free
IPA,
so
if
you're
not
familiar
with
free
IPA,
think
of
his
active
directory
for
Linux,
it's
a
tool
from
Red
Hat
that
really
makes
bridging
the
Linux
and
Windows
world
much
much
easy
as
it
takes
care
of
all
of
the
kind
of
nitty-gritty
of
Kerberos
Trust
and
things
of
that
nature.
It
also
has
some
really
great
features
of
being
able
to
extend
Active
Directory
users
into
your
Linux
environment
without
making
changes
to
Active
Directory.
B
We
made
really
extensive
use
of
that,
and
so
in
that
that
was
the
first
decision
we
made,
but
it
was
when
we
built
out
our
okay,
the
infrastructure
we're
going
to
do
so,
a
free
IPA
and
we're
going
to
set
up
what
was
called
a
domain
level
trust,
that's
the
default
trust
between
Active
Directory
and
free
IPA,
and
so
that
means
that
users
from
Active
Directory
can
log
into
your
Linux
resources,
but
users
that
are
built
inside
the
free
IPA.
Only
in
your
Linux
domain,
don't
then
have
access
to
Active
Directory.
B
This
kind
of
gives
us
the
best
of
both
worlds:
users
from
ad
or
able
login,
but
there's
no
back
washing
into
Active
Directory
everything
stays
isolated
so
now.
The
next
question
that
came
in
was
how
we
gonna
orchestrate
all
this.
You
know
we
wanted
to
have
a
place
where
we
could
store
authorization
groups.
So
free
IP
is
a
great
choice
for
that,
but
we
need
to
be
able
to
do
authentication
now.
Okay,
dee
can
do
authentication
with
the
ad
out
of
the
box.
B
However,
we
decide
to
put
open
unison
in
front
of
that,
because
the
long
term
goals
were
to
go
beyond
LDAP
authentication
against
AD.
Sam'l
was
one
thing
that
we've
talked
about.
You
know
everything
Elysa
my
opinion.
Everything
in
okay
Dee's
should
be
considered
privileged
access
management,
and
so
multi-factor
is
another
thing
that
we
talked
about
and
so
injecting
open
Unison
into
the
process
early
gives
us
a
proxy
layer.
Basically
to
do
that.
B
The
second
piece
was
orchestration
of
free
IPA.
One
of
the
things
that's
interesting
about
free
IPA
is
there's
a
a
feature
called
a
view,
a
user
view.
So
the
idea
is,
is
that
if
I
have
a
user,
an
active
directory
that
we
need
to
add
attributes
to,
but
we
can't
inject
them
into
active
directory,
open
or
I'm?
Sorry,
free
IPA
will
let
us
apply
this
view
to
it
where
it'll
store
those
attributes
locally
and
associate
it
with
the
user.
B
External
groups,
inside
of
free
IPA,
so
that's
what
allows
you
to
add
a
user
from
Active
Directory
to
a
free,
IPA
authorization
decision,
and
then
we
also
added
a
code
that
would
let
us
generate
the
IDs.
We
need
the
linux
ID
or
the
POSIX
ID
is
really
out
of
free
IPA
and
then
store
them
in
this
default
view.
So
that
way
we
had
consistent
access
to
the
IDS.
So
by
combining
open,
unison
and
free
IPA,
we
really
created
a
very
seamless
integration
with
free
IPA.
B
So
then,
the
next
thing
that
we
ran
into
was
we
wanted
to
be
able
to
limit
how
we
wanted
to
be
able
to
perform
limits
outside
of
just
our
back,
our
backs
great,
but
it's
not
very
coarse-grained.
Once
you
have
access
to
something
at
the
API
level,
you
can't
then
say
that
only
certain
aspects
of
that
are
available
and
so
kerbin
a
is
an
open
chef.
Has
this
great
feature
called
mutating
and
validating
web
hooks
to
be
able
to
extend
the
authorization
process,
and
so
there's
a
cognitive
foundation
project
called
OPA
open
policy
agent.
B
That
makes
it
really
easy
to
build
these
types
of
policy.
Now
you'll
see
here
that
okay
D
is
communicating
through
open
unison
to
get
the
OPA.
That's
because
we
need
to
add
some
capabilities
that
OPA
didn't
have
out
of
the
box,
and
we
felt
that
the
easiest
way
to
do
that
was
to
use
open
and
shifts
or
excuse
me
open,
unisons,
built-in
integration
with
okay
D.
So
now
we're
just
thrown
a
lot
of
architecture
at
you.
B
So
let's
talk
about
key
caps,
so
the
the
mechanism
that
we
wanted
to
use
for
having
our
applications
inside
of
pods
talked
Kerberos
was
via
key
tabs
for
a
few
reasons.
One
we
don't
want
store
passwords.
That's
just
a
really
bad
idea
to
the
customer.
Didn't
want
to
store
key
tabs
as
secrets,
primarily
because
the
assumption
was
that
there
would
be
more
open
shift
admins
than
there
would
be
IPA
admins,
and
so
they
wanted
to
really
limit
the
scope
of
how
these
key
tabs
get
stored.
B
So
the
process
we
decided
to
go
through
was
to
actually
deploy
the
key
tabs
on
each
of
our
worker
nodes,
the
idea
being
that
didn't
matter
which
pod
fired
up
the
key
tab
would
be
available
and
then
we're
relying
on
host
level
security
through
IPAs
host
based
access
controls
to
limit
the
access.
So
if
somebody
logs
in
you
know
SSH
is
in,
they
might
have
access
to
their
own
key
tab,
but
they
wouldn't
have
access
to
anybody
else's
key
tab
and
so
that
that's
how
we're
limiting
the
access
there.
B
So
then
the
question
becomes:
how
do
we
distribute
these
key
tabs?
Well,
this
is
where
ansible
comes
in,
so
john
osborne
I
came
up
with
a
great
idea.
I
was
chatting
on
Twitter
trying
to
figure
out
how
to
do
this,
and
he
said
you
know
what
you
could
run
ansible
as
a
pod
and
a
job,
and
so
that's
exactly
what
we
did.
B
It
was
a
great
idea
on
his
part,
and
so
what
happens
is
when
somebody
actually
gets
says:
I'm
gonna
deploy
a
new
key
tab
and
and
just
to
define
what
key
tab
is
the
key.
That
is
basically
a
special
file
or
your
password.
There's
a
one-to-one
correspondence
between
your
password
and
a
key
tab.
Your
password
changes.
You
need
to
update
your
key
tab.
The
big
difference
is:
is
that
the
key
tabs
not
reverse
encrypted
or
unencrypted?
You
can't
determine
a
password
based
on
a
key
tab.
B
B
The
next
thing
that
comes
up
is
validating
persistent
claim
so
because
these
persistent
claims
are
stiff
space
and
they
need
to
be
accessed
as
the
user,
we
need
to
make
sure
that
we
could
figure
out
which
persistent
volume
is
associated
with
which
user
and
so
we're
doing
that
via
annotation.
So
when
the
user
gets
access
to
the
cluster
they're
able
to
request
key
tab
access
and
then
open,
unison,
workflow
engine
will
generate
persistent
volumes
for
that
user
for
the
sifts
drives,
and
so
when
we
do
that,
I've
got
highlighted
here.
B
We
actually
mark
the
persistent
volume
as
user.
Only
so
this
means
that
only
the
user
who
is
associated
with
this
particular
persistent
volume
is
able
to
have
access
to
it
and
we're
actually
using
a
flex
volume
for
this
deployment
to
be
able
to
do
sips
because
sips
just
isn't
a
first
class
citizen
in
kubernetes.
At
this
point,
so
we
have
this
flex
volume
and
a
flex
volume
is
really
just
a
shell
script.
B
That
knows
how
to
mount
drives
and
it
goes
ahead,
and
it
knows
where
it's
my
own
thing,
and
then
this
is
the
UID
number
that
comes
out
of
IP
a
and
the
users
account.
So
that
tells
us
everything
we
need
to
know
to
authorize
it.
So
if
anybody,
besides
OC
Commons
one
wants
AXA,
wants
to
claim
this
persistent
volume
he'll
fail
and
it
fails
because
we
wrote
into
OPA
how
to
authorize
that
now.
B
Without
the
without
the
volume
being
in
place,
we
can't
actually
ball
validate
the
claim
when
it
gets
submitted.
So
we
actually
had
to
add
a
rule
to
Opa
that
says
if
you
submit
a
persistent
volume
claim
that
matches
a
persistent
volume
that
doesn't
exist,
yet
we're
going
to
reject
it,
because
we
have
no
way
of
saying
whether
or
not
that
claim
should
work
yet
or
after
okay
and
so
here's
the
thought
process
we
went
through
with
our
deployment
of
Opa.
B
Opa
basically
has
two
parts:
it
has
a
policy
evaluation
engine,
often
called
rego
or
not
off,
call
rego.
The
language
that
you
write.
Policies
in
is
called
rego,
and
then
it's
got
an
internal
database.
Now
this
internal
database
is
ephemeral.
It's
not
you
know
like
a
sequel,
server
database
or
anything
else
like
that.
It's
really
designed
to
be
able
to
help
you
make
easier
policy
decisions,
and
so,
in
the
case
of
kubernetes,
when
you
deploy
open
policy
agent,
it
runs
with
a
sidecar,
that's
constantly
pulling
in
update
who
creates
objects.
B
So
we
need
to
be
able
to
authorize
based
on
the
bocal
Divine's
access,
but
as
we
started
testing,
what
we
found
very
quickly
was
that
when
you
deploy
most
folks,
don't
deploy
pods
directly,
you
deploy
a
deployment,
and
then
you
put
them
in
configuration
to
poi
the
pot.
The
the
issue
that
we
run
into
with
that
is
that
the
request
that
gets
submitted
to
OPA
doesn't
reference
me
mark
or
steam
as
being
the
user
to
create
the
pod.
B
It
represents
a
service
account
that
the
deployment
was
built
is
built
using,
and
so
we
don't
actually
know
who
the
requesting
user
is
an
OPA.
So
we
need
to
add
some
logic
that
said:
okay,
well
we're
authorizing
users
based
on
their
name,
space
based
on
their
project,
and
so
users
only
have
access
to
their
own
project.
B
They
don't
have
access
to
anybody
else's
project,
and
so
it's
safe
to
say
that
if
you
are
in
a
project,
you
are
either
the
user
or
you're
authorized
to
to
run
as
that
user,
and
there
are
going
to
be
some
specific
use
cases
down
the
road
where
service
accounts
are
going
to
be
needed.
For
for
specific
reasons,
and
so
we
needed
a
way
to
tell
OPA
not
only
who
the
user
is,
but
also
we
needed
to
figure
out
all
the
different
types
of
tokens
that
were
needed
and
we'll
get
into
the
the
details
of
that.
B
Why,
in
a
moment
and
so
having
okd
talk
directly
to
OPA,
wasn't
going
to
work?
That's
where
we
injected
open
unison,
open
units
and
one
of
the
things,
openness
and
does.
Is
it's
a
reverse
proxy
and
gives
you
the
opportunity
to
manipulate
a
request
as
it
goes
downstream,
and
so
we
injected
open
unison
between
okd
and
OPA,
and
what
that
allowed
us
to
do
was
to
pull
in
information
about
the
user.
B
So
if
the
user
was
submitting
a
deployment,
it
could
actually
pull
the
information
out
of
the
namespace
annotations
as
to
who
the
user
is,
and
it
could
also
pull
additional
group.
A
from
information
out
of
an
attribute
outside
of
free
IPA.
Okay,
doesn't
know
that
much
about
its
users.
It
basically
just
knows
a
user
name
and
a
couple
of
other
bits
of
information
and
then
groups,
and
so
all
the
other
information
that
we
would
need
is
coming
from
free
IPA.
B
You've
got
to
get
a
key
tab,
you
got
to
initialize
it
into
a
key
ring
and
that
key
tab
has
to
get
be
kept
warm
and
so
I'll
have
a
link
in
the
at
the
end,
to
a
great
blog
post
that
was
written
by
a
member
of
the
OpenShift
team
on
how
to
do
these
Kerberos
sidecars.
But
you
need
a
lot
of
information
to
do
that.
B
You
have
to
have
the
Kerberos
configuration
you
have
that
the
user
principle
and
then
you
have
to
create
that
sidecar
itself
and
while
the
site
card
is
not
particularly
hard,
think
about
from
a
developer
standpoint,
the
less
you
asked
your
developers
to
do
the
less
likely
you're
going
to
get
a
support
call.
So
we
wanted
to
do.
Is
we
want
to
add
a
give
users,
the
ability
to
just
add
an
annotation
to
their
side
to
their
odd
or
their
deployment
and
just
inject
a
sidecar?
B
So
if
you're
familiar
with
working
with
it,
Co
very
similar
to
the
same
pattern
that
it
Co
use.
In
fact,
we
ran
into
a
lot
of
the
same
bugs
and
OpenShift,
primarily
3:9,
so
they've
all
been
fixed
that
the
nto
team
ran
into
and
integrating
into
openshift.
So
if
you
see
here
on
the
left-hand
side,
the
pod
that
we're
gonna
run
has
this
annotation
here
called
sidecar.
B
B
The
way
that
we're
doing
this
is
we've
got
a
volume
mount
that
stores
the
local
volume
mount.
That
stores
the
key
tab
and
we're
using
you
know
we're
using
SCC's
to
make
sure
that
the
pod
only
has
access
to
that
and
then,
but
in
order
to
have
accessed
that
SCC
you've
got
to
change
the
service
account
and
then
everything
falls
down
from
that.
The
problem
is:
is
that
the
mutating
and
validating
web
hooks
run
after
the
service
account
injection
web
hooks,
and
so
what
was
happening
was
even
though
we
changed
the
service
account.
B
When
you
submit
this
pod
or
deployment
of
that
pod,
you
get
everything
on
the
right
side
and
there's
actually
like
four
more
pages,
but
I
couldn't
actually
fit
it
all
in
so
I'll
show
it
to
you
once
we
move
through
the
deployment.
It's
a
lot
of
moving
pieces
began
which
here's
the
demo
I'm
gonna
go
ahead
and
pop
out
and
we
are
going
to
start
Windows.
So
can
everybody
see
me
I,
see
a
Windows
desktop.
Yep
looks
good,
though
this
is
our
shared
drive
that
we're
going
to
work
with
our
L
drive.
B
A
B
B
B
U
ID
number
that
if
I
were
to
login
to
the
terminal
and
type
in
ID,
that's
the
number
that
would
come
up
and
so
as
you'll
see,
I
have
access
to
anything.
So
let's
change
that,
so
we're
going
to
request
access,
and
so
this
is
the
self-service
portal
and
the
the
mechanism
that
they,
the
this
customer,
wanted
to
get
access
to
say.
Ok,
when
you
get
access
to
OpenShift,
I'm
going
to
request
access
here,
we're
going
to
generate
a
project
for
you.
Everybody
gets
their
own
project,
though,
or
Commons
I'm
gonna
submit
the
request.
B
So
I'm
now
logged
in
as
an
administrative
user,
so
I
have
access
to
a
lot
more
I
have
access
to
the
console
we
deploy
with
an
active
mq,
integrated
for
high
availability
and
then
to
be
able
to
play
the
key
tabs.
I
have
access
to
a
lot
more
things,
including
the
ability
to
approve
access.
So
here's
the
request
that
just
came
in
for
open
shift,
Commons
3
and
it's
going
to
load
up
the
approval
day
for
demo.
So
when
we
confirm
this
request,
several
things
are
going
to
happen.
B
One
we're
going
to
create
project
we're
going
to
create
a
project
for
RC
Commons
3.
We
are
going
to
create
groups
inside
of
IPA
for
managing
access
to
that
project
or
for
approving
access
to
that
project.
We're
also
going
to
create
all
the
different
artifacts
inside
of
openshift,
so
we're
creating
the
project
itself.
We're
creating
policy
objects,
we're
creating
group
objects.
In
fact,
I'm
over
here
to
the
reports
and
I
go
to
single
user
change.
Log.
B
And
run
a
report
we
can
see
here
there's
a
couple
work
posts.
The
first
one
was
the
just-in-time
provisioning.
That
was
the
creation
of
the
account
overlay
as
well
as
the
u
ID
number
and
IP
a
and
then
here's
everything
that
we
just
created
as
part
of
our
user
and
project
onboarding.
We
create
the
project,
we
create
the
groups,
we
create
the
role
bindings
for
viewers
and
editors,
and
then
we
also
created-
or
we
also
added
authorizations
for
the
user.
B
And
so
now,
you'll
see
I've
got
a
new
badge,
open
ship
console,
so
I
can
login
and
we'll
see
that
I've
got
a
couple
of
permissions
here.
I've
got
inside
of
openshift
I've
got
a
group
called
administrators
Commons
three
project,
that's
part
of
a
the
editor
role
binding
and
then
also
we
have
the
free
IPA
group
applications
openshift.
So
that's
how
open
unison
knows
to
authorize
my
access
into
open
chef
and
then,
if
I
go
over
to
open
shift.
B
B
A
B
B
And
my
tester
egg:
it's
not
the
fastest
machine
in
the
world,
so
it's
submitting
now
all
right!
So
I'm
gonna
come
back
here
to
my
console
and
you'll,
see:
storage
I've
got
these
two
new
persistent
volume
claims.
These
claims
that
so
what
that
workflow
did
was
it
enabled
my
access
for
key
tab.
So
it
authorized
me
by
adding
me
to
a
group
inside
of
IPA,
but
it
also
created
four
new
objects.
B
Inside
of
open
chef,
you
create
persistent
volumes
to
our
L&R
drive
that
are
associated
with
me
and
then
it
created
persistent
volume
claims
inside
of
my
project
so
now
I'm
able
to
access
that
data
from
pods
inside
of
my
project,
but
before
I
can
do
that.
I
need
to
deploy
my
key
tab.
Let's
go
ahead
and
log
out
and
log
back
in.
B
Now
we're
gonna
see
that
I've
got
a
couple
of
extra
things
on
my
capabilities.
I've
got
this
deployed
key
tap
badge,
and
then
here
you
can
see
I'm
using
free,
IPA
I
can
track
who
has
access
to
key
tabs.
So
this
is
giving
us
the
ability
to
store
group
Rick
is
giving
us
the
ability
to
store
group
information
for
Active
Directory
users
inside
of
IPA,
so
we're
not
plugging
the
Active
Directory
admins
for
a
know.
You
or
some
kind
of
administrative
credential,
I'm
gonna
go
ahead
and
deploy
my
key
tab.
B
B
B
B
So
I'm
back
at
our
console
and
we're
going
to
show
off
a
couple
of
things
here.
We're
gonna
show
off
a
pod
that
uses
the
sips
the
sips
volume
mount
we're
going
to
fire
up
a
version
of
unison,
unison
as
one
of
our
commercial
products
that
we
just
said.
Okay,
we're
going
to
use
the
system
while
I'm
out
four
five
for
storing
files,
and
then
we
are
going
to
show
off
our
ability
to
run
a
key
tab
inside
of
a
container.
So
real,
quick
first
show
you
there's
nothing
up
my
sleeves.
B
B
I
know
that
I
need
to
add
a
couple
of
bits
of
information
in
order
for
the
persistent
volume
claim
to
work
and
then
here's
our
persistent
volume
claim
all
up
at
the
Commons
3,
because
this
is
dry
run
3,
and
so
the
second
piece
that
will
happen
is
the
claim
against
persistent
volume
claims
through
the
L
Drive
against
the
the
percent
of
volume.
Claim
that
we're
naming
here
is
linked
to
a
persistent
volume,
we're
going
to
make
sure
that
we
have
access.
B
B
So
let's
go
ahead
and
add
to
project
important
Hamel,
now
I'm
doing
this
as
a
pod.
If
we
did
this
as
a
deployment,
the
big
difference
would
be
that,
instead
of
getting
instead
of
getting
a
request,
as
the
user
could
come
in
as
a
service
account
and
so
open
unison
would
then
say.
Ok,
here's
the
user
who's
actually
requesting
it
get
created
based
on
the
name
space,
and
so
that
little
delay
is
because
okay
Dee
is
talking
to
open
unison,
open
unison,
talking
to
open
chef.
B
A
A
B
B
So
here
was
our
annotation
that
told
OPA
go
ahead
and
inject
sips,
and
so
in
order
to
do
that,
we
actually
have
to
run
as
the
user,
because
if
the
users
don't
line
up
the
the
pod
has
to
run
as
the
user.
So
it's
running
as
OC
Commons
3,
which
means
we
had
to
create
a
custom
SCC,
and
we
had
to
inject
that
into
the
pod.
B
B
The
next
pod
we're
going
to
do
is
the
key
tab
injection
pod.
So
this
is
a
pod
that
is
actually
not
going
to
do
anything,
but
let
us
show
that
we
have
a
running
key
tab.
So
again
we
took
the
the
great
article
that
was
written
about
injecting
Kerberos
into
a
pod.
Is
that
okay,
let's
make
sure
that
we
make
it
foolproof,
so
no
adding
of
sidecars
by
user?
So
here's
our
pod
been
important
and
then
this
is
really.
B
The
key
here
is
the
sanitation
we're
going
to
see
that
this
annotations
there
and
go
ahead
and
do
the
injection,
let's
see
there's
only
one
container
in
the
pot
and
I
do
the
create
and
it's
creating,
but
you'll
see
here
we
have
two
pods
running
containers
running
in
our
pod:
that's
because
we
have
a
motorcycle
and
a
sidecar.
The
sidecar
is
where
all
of
the
works
being
done
of
initializing
the
key
tab
of
the
keyring
and
then
sharing
it
with
the
key
tab
via
shared
with
the
motorcycle
via
shared
memory.
B
So
our
stuff
runs
in
this
motorcycle
Kerberos
is
managed
and
maintained
in
the
sidecar
I
come
over
here
in
my
terminal,
I've
got
my
sidecar
and
I've
got
my
motorcycle.
If
I
do
with
Kahless,
then
my
motorcycle
there's
my
key
tab.
I
am
logged
in
as
IC
Commons
3
so
as
that
tab
needs
to
get
Risha
line
or
the
keyring
needs
to
get
reinitialized.
My
motorcycle,
where
all
the
works
being
done
or
my
sidecar,
where
all
the
works
being
done.
B
It
is
doing
that
so,
ok,
good
we've
got
some
time
for
questions.
I
see
that
saw
them
keep
popping
up.
You
know
kind
of.
Where
do
we
go
from
you
know?
The
first
question
you
might
ask
is:
is
this
all
open
source
most
of
it?
So
we
wrote
a
bunch
of
code
that
was
specific
for
the
customer
around
creating
key
tabs,
we're
going
to
work
with
them
to
see
if
they're
open
to
us.
B
Besides
that
everything
is
available,
so
all
of
the
code
that
we
wrote
or
interacting
with
OPA
and
injecting
additional
information
I,
don't
have
links
to
that
here.
That's
all
open
source,
open
unison,
is
open
source
and
obviously,
ok,
D
and
OPA
is
all
open
source
windows,
obviously
not
open
source,
yet
not
sure
if
anybody
from
Microsoft's
on
the
line
give
her
that
codes
one
day
so
yeah.
So
that's
that's
everything
from
the
demo
standpoint
at
this
point,
while
we
open
it
up
for
questions,
Hey.
A
B
A
B
That's
a
great
question,
so
we
have
two
models:
we're
an
open
source
companies,
so
so
all
of
our
products
are
open
source.
We
have
a
commercial
version
which
has
a
nice
management
UI.
That
makes
it
a
lot
easier
to
build
a
lot
of
these
policies.
It
really
cuts
down
the
amount
of
time
to
do
the
implementation,
and
then
we
have
open
unison,
which
has
all
the
same
features
and
functionality
you
just
gotta,
configure
it
by
hand
and
so
we're
using
both
on
this
particular
deployment,
which
is
really
cool.
B
And
we
do
an
export
of
the
code
into
a
git
repository
now
we're
using
our
sty
builder
that
we
built
to
create
a
hardened
undertow
image
based
on
that
config.
So
we're
we're
using
the
the
get
ops
style
that
folks
really
like
with
openshift,
and
we
have
the
management
UI
for
managing
really
certificates,
key
stores
and
tickets,
key
stores
and
networking
config.
A
B
B
But
we
do
also
commercially
support
it.
So
we've
got
customers,
they
will
run
the
commercial
version
paid
and
the
open-source
version
paid,
and
then
we
also
have
a
right
now.
It's
called
the
open,
unison
QuickStart,
but
we're
actually
moving
that
into
a
new
github
repository,
so
that
portal
that
you
saw
of
being
able
to
request
access
to
OpenShift
resource
and
stuff.
Like
that,
we
have
a
big
line.
That
is
just
works
out
of
the
box.
It
doesn't
give
you
everything
you.
B
You
know
you
that
you
saw
around
Kerberos
or
whatnot,
but
that
baseline
functionality
is
there,
and
then
we
also,
we
got
a
lot
of
requests
at
coop
con
talking
to
folks
or
a
sam'l
version
of
that
that
just
only
did
sam'l
authentication
for
open
chef.
So
that's
going
to
end
up
in
this
open,
unison
repository
soon
as
well.
B
B
B
And
there's
some
resources
on
documenting
this.
You
know
open
Unison
has
a
lot.
Every
feature
is
documented.
How
they
all
fit
together,
isn't
always
document
as
well
as
I'd
like
it
to
be,
but
every
switch
is
there
free,
IPA
the
open
policy
agent,
and
you
know
what,
if
you're
working
with
open
policy
agent
join
the
slack
channel,
it's
got
a
great
community
that
love
to
help
out
I
would
not
have
been
able
to
do
this
without
the
great
help
of
the
folks
on
that
channel.
A
A
Add
you
to
the
slack
channel
itself
and
you
can
always
reach
him
at
terminal
security
and,
as
I
said
earlier,
I
will
post
this
and
his
slides
shortly
this
afternoon,
and
hopefully
maybe
what
we
can
collaborate
on
is
some
more
documentation
as
a
lot
of
this
is
all
open
source
project
stuff.
So
if
you
have
feedback
and
there's
documentation
missing,
that's
always
an
opportunity
to
help
out
building
out
that
documentation.
So
I
look
forward
to
hearing
more
from
you
in
the
new
year
and
more
case
studies
and
thanks
a
lot
mark.
Yeah.
B
A
We
are
on
January
30th,
we'll
all
be
in
London
at
the
Savoy
place
for
a
day
of
open
shift,
commoners
talks
and
lots
of
more
case
studies,
as
well
as
a
number
of
updates
on
open
chef,
4.0
so
also
go
to
common,
said,
open,
shot,
org,
and
you
can
find
all
the
details
there
on
the
upcoming
gatherings.
But
thanks
again
and
Mark
email
me,
your
slides
and
we'll
get
it
all
up
today,
all
right,
fantastic
thanks.