[feature] support kubelogin grant-type=authcode-keyboard in omni

[nberlee]

Problem Description

Our team utilizes an SSH stepping stone or bastion host to access our Kubernetes clusters. This approach ensures segmented access and enhanced security as it eliminates the possibility to store manifests with potential secrets on employee laptops. However, our SSH stepping stone doesn’t support Xorg/Wayland, hence making it impossible to login into Keycloak using browsers, also textbrowsers like lynx lack JavaScript support.

We came across a potential solution in the kubelogin docs that outlines the use of grant-type=authcode-keyboard. This feature facilitates an authorization code flow login utilizing a keyboard, bypassing the need for a graphical interface on the same host as the terminal.

$ kubectl get nodes
Please visit the following URL in your browser: https://<interal-url-to-omni>/oidc/authorize?access_type=offline&client_id=native&code_challenge=<redacted>&code_challenge_method=S256&nonce=<redacted>&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_type=code&scope=cluster%3<cluster>+openid&state=<redacted>
Enter code:

However, upon attempting this method, we encountered an error indicating that the requested redirect_uri is not configured in the client settings. The error message: The requested redirect_uri is missing in the client configuration. If you have any questions, you may contact the administrator of the application. Our initial assumption was that this issue originated from Keycloak, but further investigation suggested that Omni might be the source of this message. We did attempt to add urn:ietf:wg:oauth:2.0:oob to the redirect_uri within Keycloak for the Omni client, but the issue persisted.

Solution

Support authcode-keyboard mode of kubectl oidc-login (kubelogin)

Alternative Solutions

Any way to login with only a terminal (authorization code flow login utilizing a keyboard, bypassing the need for a graphical interface)

Notes

No response

[rothgar]

@nberlee can you review this configuration in my PR and see if that works for you? https://github.com/siderolabs/omni-docs/pull/77/files

[nberlee]

Yes, this aligns with the script I've developed to address this issue. However, it's important to indicate that each user must have a separate port to avoid complications. If not, there's a risk of using someone else's credentials by mistake.

This happens because the first user to try will claim the port, while the second user will encounter an error, even though the port-forwarding may succeed. Therefore, if the second user inputs their credentials more quickly, they could inadvertently authenticate for the first user.

#!/bin/sh
set -xe
# Generate a random port for SSH tunneling
randomport=$(shuf -i 1025-65534 -n 1)

# Create the SSH tunnel
ssh jumphost -L $randomport:localhost:$randomport -- kubectl oidc-login get-token --oidc-issuer-url=https://omni.on2it.net/oidc --oidc-client-id=native --oidc-extra-scope=cluster:$1 --skip-open-browser --listen-address 127.0.0.1:$randomport &

# Try to fetch the 301 redirect up to 3 times
for i in {1..3}; do
    # Fetch the 301 redirect location
    location=$(curl -s -X GET -I -m 1 http://localhost:$randomport | grep Location | awk '{print $2}')

    if [ ! -z "$location" ]; then
        vivaldi-stable $location
        exit 0
    fi

    sleep 1
done

echo "Failed to get the 301 redirect after 3 attempts"
exit 1

[rothgar]

I thought about port conflicts for shared/jump hosts. Thanks for sharing your script on working around that issue. It looks like you run the tunnel in the background, do you ever clean it up when someone disconnects?

I'm assuming support for authcode-keyboard would still be preferred for your environment.

[nberlee]

The tunnel does indeed operate in the background and will continue to do so until the kubectl oidc-login process terminates. This termination could result from a successful login or it could be due to a timeout, which is set to occur after 3 minutes by default in kubelogin. In either case, the termination of the kubectl process automatically closes the tunnel.

While this approach serves as an effective solution for us, it's still just that—a workaround. We recognize that a more straightforward solution like the authcode-keyboard would be preferable over a workaround.

[nberlee]

@Unix4ever You made our day! We tested it in 0.38, this is great!