From de39e759eae43a9fe346d886ffd9163915a85290 Mon Sep 17 00:00:00 2001 From: Martin Pitt Date: Tue, 7 Jan 2020 17:57:13 +0100 Subject: [PATCH] More presentation --- cleanup.sh | 2 +- cockpit-auth-anywhere.md | 157 ++++++++++++++++++++++++++++++++++++--- prep.sh | 1 + 3 files changed, 147 insertions(+), 13 deletions(-) diff --git a/cleanup.sh b/cleanup.sh index 450fbe7..e329830 100755 --- a/cleanup.sh +++ b/cleanup.sh @@ -1,4 +1,4 @@ #!/bin/sh -x sudo vgremove -f vg0 sudo rmmod scsi_debug -sudo rm -f /etc/cockpit.cockpit.conf +sudo rm -f /etc/cockpit.cockpit.conf /etc/cockpit/machines.d/* /etc/ssh/ssh_known_hosts diff --git a/cockpit-auth-anywhere.md b/cockpit-auth-anywhere.md index fbc8f46..e633e2b 100644 --- a/cockpit-auth-anywhere.md +++ b/cockpit-auth-anywhere.md @@ -6,7 +6,7 @@ email: mpitt@redhat.com date: DevConv.CZ 2020 theme: Singapore header-includes: - - \usepackage{wasysym}\usepackage{pgfpages}\setbeameroption{show notes} + - \setbeameroption{show notes} - \newcommand{\fullsizeimg}[1]{\makebox[\linewidth]{\includegraphics[width=\paperwidth]{#1}}} ... @@ -16,9 +16,11 @@ header-includes: - Easy setup and troubleshooting for one or a few machines - Included in all major distros -\note[item]{Conceptually: Linux session running in a web browser; technically very similar to ssh/VT/GNOME login} -\note[item]{Aimed at admins who are new to Linux, e. g. coming from the Windows world and familiar with the concepts, but not Linux terminology} -\note[item]{but also to experienced ones for infrequent tasks; not just setup, but also investigating “what is wrong with this machine”} +:::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 @@ -30,16 +32,147 @@ lvresize --extents '+100%FREE' vg0/data1 resize2fs /dev/vg0/data1 ``` -\note[item]{for example, adding a new PV to an LV and resizing the file system you can spend some time coming up with these commands} -\note[item]{lots of possibilities for screwing up} -\note[item]{you can do it simply and safely with Cockpit like this → go to local browser} -\note[item]{Storage page, vg0 in Devices (top right), + in Physical Volumes, add sdb2} -\note[item]{expand data1 table line, click grow} +:::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 +::: -# Contact +# Accessible from any browser + + - Windows/Edge + - Mobile devices + - Simple install + - Zero configuration + +:::notes +- TODO: check out bots in "make deps", add ./vm-run windows-10 to prep.sh +- Switch to Windows virt-viewer, open Edge, show Cockpit +- Quit virt-viewer +- 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, translate WebSocket to JSON protocol; 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 +- TODO: start rhel7 VM in prep.sh, set hostname +- 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 + +:::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 all of this +::: + +# Custom authentication example + +TODO + +# Q & A + +Contact: - `#cockpit` on Freenode - https://cockpit-project.org -\note[item]{Home page leads to mailing lists, documentation} -\note[item]{thanks for your attention; Q+A} +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 +::: diff --git a/prep.sh b/prep.sh index fa38270..7874fc3 100755 --- a/prep.sh +++ b/prep.sh @@ -28,4 +28,5 @@ cat <