Looking for help with setting up external authentication for cockpit

[deryni]

I've been tasked with setting up external authentication for some of our cockpit systems. Unfortunately, this isn't an authentication scheme that works via pam natively nor can it be handled via a Bearer token of some sort (though even if it could use a Bearer token that would leave me with the same question I have currently as far as I understand things).

I seem to recall reading, at some point, that it would/should be possible to launch a cockpit session/bridge externally (i.e. after the external auth process) and then use that as the session for the UI but I can't find any reference to that currently and given what I've read and understand about how cockpit works I'm not sure I see how that would be done.

Do I misremember what I read? Am I missing any current documentation? Is this actually an approach that could work? If so, is there any guidance on what I would need to do to make this work?

Launching cockpit-bridge seems simple enough but I don't see how cockpit-ws, etc. would know about it at that point and I assume some-to-all of what cockpit-session does before launching the bridge is functionality and security critical but I'm not comfortable enough in this space to assess what those details are myself.

Any help would be greatly appreciated. Thank you.

[martinpitt]

You can do all the authentication and session starting as the target user externally, and then start cockpit-ws directly with --local-session=cockpit-bridge as the target user. This is what e.g. cockpit-desktop does. However, you need to isolate the port 9090 then (cockpit-desktop does that with namespacing) as there is zero authentication on that port, you get a cockpit session as the target user right away.

You can also keep cockpit-ws as-is and create a custom authentication script similar to cockpit-session or cockpit-ssh -- the goal is that this script does the authentication, runs cockpit-bridge as the target user, and connect its stdout/in to itself, so that cockpit-ws has a two-way pipe to cockpit-bridge (with whatever in between). However, this is difficult -- this isn't configuration, this is real development. That's why it's rare, and there are no examples to point to. 😢

[moutasem1989]

I am trying this approach based on the information provided here.

My goal is to use NginX to send authentication headers and bypass login screen. Then use reverse proxy authentication with NginX and Authentik. Technically each “Cockpit user” will have their own domain and access policies are controlled via Authentik. Hopefully no changes are needed for Cockpit Configurations.

Edit:

this is the working custom configuration of NPM with Authentik reverse proxy authentication

# Increase buffer size for large headers
# This is needed only if you get 'upstream sent too big header while reading response
# header from upstream' error when trying to access an application protected by goauthentik
proxy_buffers 8 16k;
proxy_buffer_size 32k;

# Make sure not to redirect traffic to a port 4443
port_in_redirect off;

location / {
    # Put your proxy_pass to your application here
    # proxy_pass          $forward_scheme://$server:$port;
    # Set any other headers your application might need
    # proxy_set_header Host $host;
    # proxy_set_header ...
    proxy_set_header        Host $host;
    proxy_set_header Authorization "Basic abcxyz==";  #base64 of user:password 
    proxy_pass_header Authorization;
    proxy_pass  $forward_scheme://$server:$port;

    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Scheme $scheme;
    proxy_set_header X-Forwarded-Proto  $scheme;
    proxy_set_header X-Forwarded-For    $remote_addr;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;

    ##############################
    # authentik-specific config
    ##############################
    auth_request     /outpost.goauthentik.io/auth/nginx;
    error_page       401 = @goauthentik_proxy_signin;
    auth_request_set $auth_cookie $upstream_http_set_cookie;
    add_header       Set-Cookie $auth_cookie;

    # translate headers from the outposts back to the actual upstream
    auth_request_set $authentik_username $upstream_http_x_authentik_username;
    auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
    auth_request_set $authentik_email $upstream_http_x_authentik_email;
    auth_request_set $authentik_name $upstream_http_x_authentik_name;
    auth_request_set $authentik_uid $upstream_http_x_authentik_uid;

    proxy_set_header X-authentik-username $authentik_username;
    proxy_set_header X-authentik-groups $authentik_groups;
    proxy_set_header X-authentik-email $authentik_email;
    proxy_set_header X-authentik-name $authentik_name;
    proxy_set_header X-authentik-uid $authentik_uid;
    #add_header X-calibre-web-user "CloudAdmin" always;
}

# all requests to /outpost.goauthentik.io must be accessible without authentication
location /outpost.goauthentik.io {
    proxy_pass              https://authentik-server:9443/outpost.goauthentik.io;
    # ensure the host of this vserver matches your external URL you've configured
    # in authentik
    proxy_set_header        Host $host;
    proxy_set_header        X-Original-URL $scheme://$http_host$request_uri;
    add_header              Set-Cookie $auth_cookie;
    auth_request_set        $auth_cookie $upstream_http_set_cookie;
    proxy_pass_request_body off;
    proxy_set_header        Content-Length "";
}

# Special location for when the /auth endpoint returns a 401,
# redirect to the /start URL which initiates SSO
location @goauthentik_proxy_signin {
    internal;
    add_header Set-Cookie $auth_cookie;
    return 302 /outpost.goauthentik.io/start?rd=$request_uri;
    # For domain level, use the below error_page to redirect to your authentik server with the full redirect path
    # return 302 https://authentik.company/outpost.goauthentik.io/start?rd=$scheme://$http_host$request_uri;
}