More presentation
authorMartin Pitt <martin@piware.de>
Tue, 7 Jan 2020 16:57:13 +0000 (17:57 +0100)
committerMartin Pitt <martin@piware.de>
Tue, 7 Jan 2020 22:13:16 +0000 (23:13 +0100)
cleanup.sh
cockpit-auth-anywhere.md
prep.sh

index 450fbe776c4fe95506dda46faf82d1627fa60816..e32983026e90af07a4686ec2af0200ea7d017d42 100755 (executable)
@@ -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
index fbc8f469b3868ff536f1e48f63b5c84f761774b9..e633e2bb73294353cffc2b532d2b88fc8c62513a 100644 (file)
@@ -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 fa38270fe3dd6a155d04611249c077ffad218a07..7874fc3cc052a7fc71bea2c00e53b75cbba89656 100755 (executable)
--- a/prep.sh
+++ b/prep.sh
@@ -28,4 +28,5 @@ cat <<EOF
 Manual steps:
 =============
  - Log into Cockpit in browser
+ - In Windows VM, open Edge and log into https://10.0.2.2:9090
 EOF