2 title: Authenticate to Cockpit from anywhere
4 author: Martin Pitt <<mpitt@redhat.com>>
5 email: mpitt@redhat.com
9 - \setbeameroption{show notes}
14 - Interactive Server admin web interface
15 - Easy setup and troubleshooting for one or a few machines
16 - Included in all major distros
19 - Conceptually: Linux session running in a web browser; technically very similar to ssh/VT/GNOME login
20 - Tool for experimenting, learning, troubleshooting, and doing infrequent tasks
28 vgextend vg0 /dev/sdb2
29 lvresize --extents '+100%FREE' vg0/data1
30 resize2fs /dev/vg0/data1
34 - for example, adding a new PV to an LVM and resizing the file system you can spend some time coming up with these commands
35 - lots of possibilities for screwing up
36 - you can do it simply and safely with Cockpit like this → go to local browser
37 - Storage page, vg0 in Devices (top right), + in Physical Volumes, add sdb2
38 - expand data1 table line, click grow
41 # Accessible from any browser
49 - being web based makes this server UI available to places that you
50 traditionally don't reach with ssh
51 - Switch to Windows virt-viewer, open Edge, show Cockpit
53 - Move to local browser, enable mobile mode (Ctrl+Shift+M)
54 - Zero configuration so far, other than possibly installing cockpit pkg and enabling cockpit.socket
55 - But wait, you say -- want to admin that server over there, but not allowed to
56 open new port and system service?
57 - In larger environments it's impractical to install cockpit server on hundreds
58 of machines and using the login web page; better solution: piggyback on ssh
59 - Glimpse of how to customize how cockpit runs and how to authenticate to it
64 ![ws-session](ws-session.pdf)\
66 - TCP http+WebSocket $\leftrightarrow$ JSON pipe
70 - for configuring, extending, and embedding Cockpit you need to coarsely understand the components of it
71 - this: simplest structure, what I just showed you and what you will most probably see the first time you try it
72 - all components in cockpit communicate to each other via a JSON protocol on standard pipes, usually stdio
73 - this provides a lot of flexibility and extensibility, as we'll see shortly
74 - browsers and JS only speak HTTP and WebSocket, and can't directly talk to Linux system APIs
75 - so you always need a web server somewhere, cockpit-ws
76 - ws roles: communicate with the browser for getting credentials: login page, krb negotiation, client cert
77 - ws: deliver HTML/js content, connects JSON protocol on the WebSocket to pipes to the other components; runs as unprivileged system user
80 # Anatomy: cockpit-session
82 ![ws-session](ws-session.pdf)\
84 - ws credentials → PAM session
85 - forward JSON pipe to session leader
88 - need some root helper to actually start session: use creds from ws to start PAM login session, connect pipe to it
89 - standard is cockpit-session: very small, auditable
90 - but doesn't have to be, that's the flexible part
93 # Anatomy: cockpit-bridge
95 ![ws-session](ws-session.pdf)\
97 - session leader, cockpit's "bash"
98 - JSON on stdio $\leftrightarrow$ system APIs
101 - bridge: session leader, moral equivalent of what bash is in ssh session
102 - JSON protocol on stdio to system APIs: exec programs, call D-Bus, work with files or sockets
103 - runs as target user in login session; complex, but no special privileges
108 ![ssh-session](ssh-session.pdf)\
110 nothing Cockpit specific running outside of the user session
113 - ws and the login session don't need to run on the same machine
114 - cockpit-session is meant to be customizable for your purposes
115 - most obvious replacement is to let ssh start a session; that already does the
116 PAM bits and forward its initial stdio to the session lead; it would just
117 launch cockpit-bridge instead of bash
118 - browser: go to Dashboard, add cockpit.dev:2201
119 - interesting property: nothing Cockpit specific running in the system, no ws,
120 no extra open port; only bit is bridge, but that's uninteresting from security POV
125 ![bastion-host](bastion-host.pdf)\
127 Enforce using ssh in cockpit.conf(5):
134 - further illustrated by a mode that we call "bastion host"
135 - disable cockpit-session and local logins, only use ssh
136 - can run in container
137 - no ws on critical machines, don't trust cockpit-session
138 - switch to browser; log out, use "connect to" for cockpit.dev:2201
139 - finish the demo script, press Enter
142 # Other authentication setups
144 - SSO/Kerberos in Identity Management domains
145 - smart card/client certificate authentication
146 - OAuth (external embedding)
147 - Foreman: included cockpit-ws with dynamic configuration
150 - Cockpit supports common authentication systems out of the box
151 - IdM is very common; if you have a krb ticket, you get a session immediately
152 without the login page
153 - browsers can ask for TLS client certificates, commonly with smart cards, and
154 present them to the web server; latest Cockpit versions supports that
155 - Foreman has a "Web Console" button; interesting case for seamless transition
156 between Foreman and Cockpit
158 - already has ssh to all maintained machines
159 - runs a single cockpit-ws process on its server, and dynamically configures it
160 for selected target machine
161 - custom cockpit session helper to do OAuth between Foreman session and
162 cockpit-ws, and wrap cockpit-ssh session starter
163 - not enough time to demo and explain all of this; just keep in mind that it's
167 # Embedding into existing session
169 ![local-session-unsafe](local-session-unsafe.pdf){height=60%}\
171 \footnotesize \verb!cockpit-ws -p 9999 --no-tls --local-session=/usr/bin/cockpit-bridge!
173 `firefox http://localhost:9999`
176 - what I do want to show: opposite direction; "replace cockpit-session" can
177 also mean "by nothing"
178 - due to common JSON protocol, we can connect ws directly to a cockpit-bridge
179 - take a step back: if I want to admin this very machine, it's in a running
180 Linux session, it knows who I am
181 - put the whole auth structure inside out and instead run cockpit-ws as my user
183 - open --local-session in shell
184 - open localhost:9999 in firefox
185 - alarm bells: exposes my session to a TCP port without any auth
189 # Embedding into existing session: once more with safety!
191 ![local-session-unsafe](local-session.pdf){height=60%}\
193 \footnotesize \verb! !
195 `/usr/libexec/cockpit-desktop [page]`
198 - need to hide that port; put browser and cockpit-ws into network namespace,
199 then they live in a completely isolated world
200 - do some work to hide browser chrome, use webkit if available
202 - wants to run priv bridge, can accept or decline
204 - can show an individual iframe, "page"
205 - suddenly you end up with a halfway decent desktop app
206 - just the storage page, replacement for gnome-disks
207 - cockpit-desktop podman
208 - cockpit-desktop is small shell script, feel free to inspect and bend to your will
213 - Authentication is very flexible
214 - Works with zero configuration
215 - Can be arbitrarily embedded and customized
218 - Cockpit provides a set of standard auth protocols that are being used in
219 today's modern deployments
220 - Once you know about the structure, you can combine ssh, web servers, reverse
221 proxies, and custom auth helpers to embed Cockpit anywhere you want
229 - `#cockpit` on Freenode
230 - https://cockpit-project.org
234 * [Authentication configuration](https://cockpit-project.org/guide/latest/authentication.html)
235 * [Authentication protocol](https://github.com/cockpit-project/cockpit/blob/master/doc/authentication.md)
238 - Home page leads to mailing lists, documentation
239 - thanks for your attention; Q+A