[talk-cockpit-auth-anywhere.git] / cockpit-auth-anywhere.md

---
title: Authenticate to Cockpit from anywhere
subtitle:
author: Martin Pitt <<mpitt@redhat.com>>
email: mpitt@redhat.com
date: DevConv.CZ 2020
theme: Singapore
header-includes:
 - \setbeameroption{show notes}
 - \newcommand{\fullsizeimg}[1]{\makebox[\linewidth]{\includegraphics[width=\paperwidth]{#1}}}
...

# Cockpit what?

- Interactive Server admin web interface
- Easy setup and troubleshooting for one or a few machines
- Included in all major distros

:::notes
- Conceptually: Linux session running in a web browser; technically very similar to ssh/VT/GNOME login
- Aimed at admins who are new to Linux, e. g. coming from the Windows world and familiar with the concepts, but not Linux terminology
- but also to experienced ones for infrequent tasks; not just setup, but also investigating “what is wrong with this machine”
:::


# Extending LVM

```sh
pvcreate /dev/sdb2
vgextend vg0 /dev/sdb2
lvresize --extents '+100%FREE' vg0/data1
resize2fs /dev/vg0/data1
```

:::notes
- for example, adding a new PV to an LV and resizing the file system you can spend some time coming up with these commands
- lots of possibilities for screwing up
- you can do it simply and safely with Cockpit like this → go to local browser
- Storage page, vg0 in Devices (top right), + in Physical Volumes, add sdb2
- expand data1 table line, click grow
:::

# Accessible from any browser

 - Windows/Edge
 - Mobile devices
 - Simple install
 - Zero configuration

:::notes
- Switch to Windows virt-viewer, open Edge, show Cockpit
- Quit virt-viewer
- Move to local browser, enable mobile mode (Ctrl+Shift+M)
- Zero configuration so far, other than possibly installing cockpit pkg and enabling cockpit.socket
- In larger environments it's impractical to install cockpit server on hundreds
  of machines and using the login web page
- Glimpse of how to customize how cockpit runs and how to authenticate to it
:::

# Anatomy: cockpit-ws

![ws-session](ws-session.pdf)\ 

- TCP http+WebSocket $\leftrightarrow$ JSON pipe
- collect credentials

:::notes
- for configuring, extending, and embedding Cockpit you need to coarsely understand the components of it
- this: simplest structure, what I just showed you and what you will most probably see the first time you try it
- browser only speaks HTTP and WebSocket, so you always need a web server, cockpit-ws
- all components in cockpit communicate to each other via a JSON protocol on standard pipes, usually stdio
- this provides a lot of flexibility and extensibility, as we'll see shortly
- ws roles: communicate with the browser for getting credentials: login page, krb negotiation, client cert
- ws: deliver HTML/js content, connects JSON protocol on the WebSocket to pipes to the other components; runs as unprivileged system user
:::

# Anatomy: cockpit-session

![ws-session](ws-session.pdf)\ 

- ws credentials → PAM session
- forward JSON pipe to session leader

:::notes
- need some root helper to actually start session: use creds from ws to start PAM login session, connect pipe to it
- standard is cockpit-session: very small, auditable
- but doesn't have to be, that's the flexible part
:::

# Anatomy: cockpit-bridge

![ws-session](ws-session.pdf)\ 

- session leader, cockpit's "bash"
- JSON on stdio $\leftrightarrow$ system APIs

:::notes
- bridge: session leader, moral equivalent of what bash is in ssh session
- JSON protocol on stdio to system APIs: exec programs, call D-Bus, work with files or sockets
- runs as target user in login session; complex, but no special privileges
:::

# SSH sessions

![ssh-session](ssh-session.pdf)\ 

nothing Cockpit specific running outside of the user session

:::notes
- ws and the login session don't need to run on the same machine
- cockpit-session is meant to be customizable for your purposes
- most obvious replacement is to let ssh start a session; that already does the
  PAM bits and forward its initial stdio to the session lead; it would just
  launch cockpit-bridge instead of bash
- browser: go to Dashboard, add cockpit.dev:2201
- interesting property: nothing Cockpit specific running in the system, no ws,
  no extra open port; only bit is bridge, but that's uninteresting from security POV
:::

# Bastion host

![bastion-host](bastion-host.pdf)\ 

Enforce using ssh in cockpit.conf(5):
```ini
[WebService]
RequireHost=true
```

:::notes
- further illustrated by a mode that we call "bastion host"
- disable cockpit-session and local logins, only use ssh
- can run in container
- no ws on critical machines, don't trust cockpit-session
- switch to browser; log out, use "connect to" for cockpit.dev:2201
:::

# Other authentication setups

- SSO/Kerberos in Identity Management domains
- smart card/client certificate authentication
- OAuth (Kubernetes)
- Foreman: included cockpit-ws with dynamic configuration

TODO: foreman screenshot

:::notes
- Cockpit supports common authentication systems out of the box
- IdM is very common; if you have a krb ticket, you get a session immediately
  without the login page
- browsers can ask for TLS client certificates, commonly with smart cards, and
  present them to the web server; latest Cockpit versions supports that
- Foreman has a "Web Console" button; already has ssh to all maintained
  machines
- runs a single cockpit-ws process on its server, and dynamically configures it
  for selected target machine, seamless transition between Foreman and Cockpit
- not enough time to demo and explain all of this; just keep in mind that it's
  possible
:::

# Custom authentication example

TODO

# Q & A

Contact:

- `#cockpit` on Freenode
- https://cockpit-project.org

Useful links:

 * [Authentication configuration](https://cockpit-project.org/guide/latest/authentication.html)
 * [Authentication protocol](https://github.com/cockpit-project/cockpit/blob/master/doc/authentication.md)

:::notes
- Home page leads to mailing lists, documentation
- thanks for your attention; Q+A
:::