From: Martin Pitt Date: Sun, 19 Jan 2020 11:18:30 +0000 (+0100) Subject: Refinements X-Git-Url: https://piware.de/gitweb/?a=commitdiff_plain;p=talk-cockpit-auth-anywhere.git Refinements --- diff --git a/cockpit-auth-anywhere.md b/cockpit-auth-anywhere.md index 3845cde..68449a0 100644 --- a/cockpit-auth-anywhere.md +++ b/cockpit-auth-anywhere.md @@ -55,7 +55,7 @@ resize2fs /dev/vg0/data1 - But wait, you say -- want to admin that server over there, but not allowed to open new port and system service? - In larger environments it's impractical to install cockpit server on hundreds - of machines and using the login web page; better solution: piggyback on ssh + of machines and using the login web page; explain better solutions - Glimpse of how to customize how cockpit runs and how to authenticate to it ::: @@ -68,12 +68,12 @@ resize2fs /dev/vg0/data1 :::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 +- this: default structure, what I just showed you and what you will most probably see the first time you try it - 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 - browsers and JS only speak HTTP and WebSocket, and can't directly talk to Linux system APIs - so you always need a web server somewhere, cockpit-ws -- ws roles: communicate with the browser for getting credentials: login page, krb negotiation, client cert +- ws purpose: 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 ::: @@ -85,8 +85,8 @@ resize2fs /dev/vg0/data1 - 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 +- need some 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 suid root helper - but doesn't have to be, that's the flexible part ::: @@ -111,9 +111,8 @@ 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 +- most obvious replacement of session helper is ssh; that already starts + sessions, does the PAM bits and forwards 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,