feat: use sso account to configure sandbox in one click

[dgolovin]

This is my experiment in response to 78dd780. It is not complete fix, but test.

Screen.Recording.2024-06-27.at.12.14.12.PM.mov

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 16.66667% with 20 lines in your changes missing coverage. Please review.

Project coverage is 43.62%. Comparing base (da60441) to head (ae581b2).
Report is 509 commits behind head on main.

Files with missing lines	Patch %	Lines
src/openshift/cluster.ts	19.04%	17 Missing ⚠️
src/webview/cluster/clusterViewLoader.ts	0.00%	3 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #4232       +/-   ##
===========================================
+ Coverage   32.37%   43.62%   +11.25%     
===========================================
  Files          85       95       +10     
  Lines        6505     7718     +1213     
  Branches     1349     1647      +298     
===========================================
+ Hits         2106     3367     +1261     
+ Misses       4399     4351       -48     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dgolovin]

Anyone care to comment?
It works. If it stopped to work at some point, there should be conversation with sandbox team.

[vrubezhny]

Anyone care to comment? It works. If it stopped to work at some point, there should be conversation with sandbox team.

We have already tried using a pipeline service token to login - it stopped working like a few days before we published a release containing it.
We do not expect to have it really working for users... unless they do not have some privileged-like access to the sandbox.

Is using the service account pipeline token an officially documented and supported thing?

Anyway, I'm going to try it.

[dgolovin]

https://docs.openshift.com/container-platform/4.8/authentication/understanding-and-creating-service-accounts.html

if you don't like pipeline SA, you can create tool specific SA and grant it edit role and it is going to be much cleaner approach. The only caveat is if you are using 'oc whoiam' it is returning SA account name.

[vrubezhny]

In general, the PR works for me if I'm logging in from Welcome -> Add OpenShift Cluster view. The only problem is that a wrong project was set in the App. Explorer tree as current (probably because the user's namespace wasn't set for the resulting current context, or maybe because of the code that sets the current project after a timeout was commented out).

The account created this way looks like the following:

My "custom" Sandbox context saved in Kube config (created previously) already has namespace property set to <my-username>-dev so it's still possible to use it to log in and the project is correctly selected once logged in. But in this case we aren't switched to using the pipeline token (in previous try we were switching to it automatically instead of using a provided user token value)

[dgolovin]

Latest commits to the main definitely have some issues. If I re-base this branch on top of origin/main nothing works. If I use it as it is, everything works.

[datho7561]

I also tried this branch and it's working for me. I noticed I was able to list the service accounts again; I think this was the root of the failure when we removed the feature. I'm going to try rebasing and retrying to see if I can reproduce those errors you mentioned.

[dgolovin]

The namespace is a problem, because in case of using SA it is going to be {sa-fullname}-dev and that is not going to work. Namespace should be pulled out of token (have decode and parse json to pull kubernetes.io/serviceaccount/namespace claim out of it. 💯 to @vrubezhny for catching it.

[dgolovin]

There is also another caveat, but it needs to be confirmed with freshly provisioned sandbox.

Considering the namespace problem is fixed and here is all required info to push image to internal registry:

1. Image tagged properly
2. user token is correct
3. registry public url is correct

It is still not going to work for very first time until first dummy image stream is created.

[vrubezhny]

@dgolovin After some months the pipeline-token secret has disappeared and cannot be obtained anymore. Or is it only for my account?

F.i. my secrets consist of the following items:

• builder-dockercfg-ztqmw
• default-dockercfg-stxjj
• deployer-dockercfg-n4fgh
• model-serving-proxy-tls
• pipeline-dockercfg-mpct2

... and none of them have *.data.token property set. So, again, we can't use this login method for accessing the DevSandbox.

[vrubezhny]

It looks like we actually can create a token that can be used to authenticate in DevSandbox...
If a pipeline-token doesn't exist we can do the following to create a new one:

            if (!pipelineTokenSecret) {
                const tokenRequest = new AuthenticationV1TokenRequest();
                tokenRequest.spec = {
                    audiences: ['https://kubernetes.default.svc'],
                    expirationSeconds: 600
                } as V1TokenRequestSpec;

                const pipelineTokenSecretResponse = await k8sApi.createNamespacedServiceAccountToken('pipeline', `${username}-dev`, tokenRequest);
                if (pipelineTokenSecretResponse?.body?.status?.token) {
                    return pipelineTokenSecretResponse.body.status.token;
                }
                return;
            }

... and the token resulting in pipelineTokenSecretResponse.body.status.token (if exists) can be successfully used in oc login --token="${pipelineTokenSecretResponse.body.status.token}"

However it doesn't look like the token created this way is stored in any service account or can be obtained from the namespace secrets, so it looks like a single-use and time-limited token. Not sure whether we can reuse it more than once and how many of such tokens can be created for a user.
Also I haven't checked yet what happens if such a token expires (10 minutes is the minimum expiration time for a token) and what can be the maximum expiration time.

UPD: The generated token really expires in expiration time specified at creation time. After the token is expired the cluster operations cannot be satisfied anymore and when the App. Explorer tree is refreshed, it shows the login button again.

[vrubezhny]

@dgolovin @datho7561 Using this PR as a source, I have created the PR #4439 - in that PR I try creating a token for the Pipeline Service Account (if it doesn't exist yet) and if successfully created it can be used to login without a need to copy a valid token into the Clipboard. The token doesn't have expiration time, so, in theory, it should die only together with the Service Account associated.
If the pipeline token cannot be created for any reason, the "Clipboard"-method will be presented as the only choice to login to DevSandbox on "Add Openshift Cluster" view.

[vrubezhny]

@dgolovin Am I correct saying that your this PR also incorporates the Use proxyURL to log into sandbox using Red Hat auth token #2743?

[dgolovin]

@vrubezhny That is correct, it is getting SSO Token and then use it with sandbox-proxy to pull permanent token for pipleine service account. Service account token doesn't expire and thus can be used directly to talk to sandbox API, no sand-box proxy is required anymore. Tada!

[vrubezhny]

Superseded by #4439.