►
Description
This is the weekly update for the Server Runtime SEG for the week of the 2nd of Nov.
This week I continued to work on the custom control plane and added the following features:
1. Devfile Support
Added the ability to use the Devfile standard to spin up an environment
2. SSH Authn and Authz
CCP now supports the ability to connect to the containers via SSH via a custom SSH Proxy that authenticates via certificates and checks whether the user has access to the IDE
Chapters
0:00 Overview
1:05 Devfile Support Demo
4:32 SSH
8:24 Whats next
A
So
this
week,
I've
worked
more
on
the
custom
control
plane.
The
two
key
features
that
have
been
added
this
week,
so
the
first
is
the
support
for
the
dev
file
standard.
So
Dev
file
is
a
cncf
project
which
standardizes
the
way
Dev
environments
can
be
defined.
It's
still
quite
nascent,
however.
What
we've
done
is
we've
added
additional
support
for
the
dev
file
format.
So
now,
instead
of
just
using
the
experiment,
Channel
file
format
to
describe
your
environment,
you
can
also
describe
your
environment
in
the
dev
file
format.
A
I've
also
added
the
ability
to
use
SSH
to
log
into
your
container.
So
earlier
you
could
only
use
a
browser
to
log
into
the
containers,
but
now
you
can
access
the
containers
via
SSH,
so
we
created
a
custom
proxy
to
do
that,
and
that
has
also
given
us
the
ability
to
do
authentication
and
authorization
for
anything
being
accessed
over
SSH
with
that
I'd
like
to
get
to
the
demo,
all
right
so
I'm
in
a
repository
here
where
we
have
a
single
Dev
file.
So
we
don't
have
any
experiments
yaml
in
this
repository.
A
All
we
have
is
a
def
file,
so
I'm
going
to
go
ahead
and
click
here
to
start
provisioning.
The
environment
I
may
have
created
one
previously,
so
it
prompts
me
whether
I
want
to
create
a
new
one
and
I
do,
and
so
it's
going
to
go
ahead
and
start
provisioning.
Now,
let's
look
at
the
wildlife
provisioning.
A
Let's
just
look
at
the
def
file
or
DML
file
here,
so
we've
got
two
components
in
this
Dev
file
and
this
is
using
the
standard,
Dev,
file.io
format
of
provisioning
environments
and
I've
got
essentially
the
runtime
and
I've
also
got
a
postgres
container
running
here.
So
basically,
let's
have
writing
code
in
node,
where
I
want
to
write
some
sort
of
web
service
and
I
want
to
access
a
database.
A
A
A
As
you
can
see,
it
says
hello
world
and
we're
ready
right.
I
could
go
ahead
and
make
changes
to
my
code.
So
I
can
change
this
to
hello,
gitlab
and
it
restarts
so.
I
can
go
ahead
and
refresh,
and
you
can
see
that
it
says
that
as
well
now,
I
can
go
ahead
and
commit
and
push
my
code,
and
that
should
be
fairly
easy,
so
I
can
get
add,
commit.
A
So,
as
you
can
see,
I've
already
authenticated
into
gitlab,
so
I
can
make
changes
very
easily.
The
next
thing
I
want
to
show
you
is
that,
because
we
had
that
additional
postgres
container
running
I
can
actually
connect
to
a
database
as
well
from
this
container.
So
I
can
I've
got
a
pre-written
script
which
will
go
ahead
and
if
I
run
the
node
grapple
this.
What
the
script
does.
Essentially,
it
creates
a
client
connection
to
my
local
postgres
running
on
localhost
5432.
A
It
creates
a
table
called
test
inserts
a
single
record
into
that
table
and-
and
it
goes
ahead
and
I
can
go
ahead
and
run
a
query
as
well.
So
I
run
a
query
and
get
the
rows
back
right
so
because
I'm
got
that
sidecar
defined
in
my
def
file,
I
can
actually
access
that
database
alongside
my
container
okay.
So
that's
the
def
file
support.
A
What
I
want
to
show
you
next
is
the
support
for
SSH
container,
so
I'm
going
to
go
ahead
and
go
to
another
Repository
I'm
gonna
go
ahead
and
start
provisioning,
an
SSH
based
container
so
again
it
to
create
a
new
environment,
and
here
at
this
time,
when
I'm
selecting
an
IDE
instead
of
selecting
vs
code
or
emacs
I'm
going
to
go
ahead
and
select
the
SSH
option.
So
this
is
going
to
create
a
container
with
SSH
enabled.
A
So,
while
that's
provisioning,
I
want
to
quickly
show
you
what's
happening
behind
the
scenes
here.
So
essentially,
as
a
user
I
request
for
provisioning
of
a
container,
what
the
provisioner
is
now
doing
is
generating
a
private
and
public
key
pair.
The
private
key
is
sent
straight
to
the
IDE,
so
you
can
actually
download
the
private
key
when
you
access
the
UI
and
then
once
that
private,
once
you
have
the
private
key,
the
user
can
then
download
that
private
key
right
so
that
you
can
authenticate.
A
Additionally,
what
we're
also
doing
is
storing
the
public
key
in
our
database,
which
is
postgres
and
then,
as
that,
as
a
user
tries
to
access
the
IDE
via
ssh.
What
we
actually
do
is
fetch
that
public
key
and
validate
the
key,
whether
it
is
correct
or
not
before
we
proxy
the
request.
So
for
this
we
had
to
create
a
custom
SSH
proxy.
A
So
the
environment's
now
ready
I
can
go
ahead
and
sign
into
gitlab
and,
as
you
see
as
I've
signed
in
it's
asking
me,
it's
letting
me
download
a
private
key,
and
this
is
a
new
private
key
that
is
generated
so
go
ahead
and
download
the
key,
and
then
it
also
gives
me
the
SSH
command,
so
that
I
can
actually
SSH
into
this
container
right.
So
I'm
going
to
go
ahead
to
my
terminal
and
I
am
going
to
go
and
first
of
all,
I
need
to
change
permissions
on
the
key
before
I
can
use
it.
A
A
So
I
can,
if
I
open
up
vs
code
here
and
I,
go
ahead
and
create
a
new
SSH
connection,
specify
a
new
host,
provide
my
credentials
here
and
hit
enter
the
same
SSH
command,
and
if
you
see
it's
added,
a
new
host
and
I
can
go
ahead
and
connect
to
that
host.
So
now,
instead
of
actually
connecting
you
know,
accessing
the
IDE
through
the
browser
I
can
actually
access
the
ID
using
my
local
IDE
right.
A
A
So
now
we
have
Again
full
access
to
the
IDE
through
in
headless
mode
and
that's
the
power
of
enabling
SSH.
We
can
enable
other
Ides
using
this
as
well,
so
we
could
use
any
of
the
jetbrains
Ides
also
use
SSH
to
connect
to
it.
So
we
can
enable
those
Ides
as
well
so
for
next
week,
I'm
going
to
be
focused
on
more
git
lab
integration,
try
to
start
the
provisioning
process
so
right
now
the
provisioning
process
starts
with
click
on
the
readme.