search

eclipse-che / che

Kubernetes based Cloud Development Environments for Enterprise Teams
http://eclipse.org/che
Eclipse Public License 2.0
6.96k stars 1.19k forks source link

User Preferences-Adding External Accounts #17954

Open parvathyvr opened 3 years ago

parvathyvr commented 3 years ago

Is your enhancement related to a problem? Please describe.

The users should be able to set up the various external accounts they want to link to Che using User Preferences. This currently includes:

Describe the solution you'd like

The user can add various external account types under 'User Preferences'.

Step 1 Could be similar to oc login display token where we expose the cmd for them to copy/paste into a terminal to add a secret. We should also explain how to query for created secrets https://github.com/eclipse/che/issues/20469

Step 2 Would add a YAML editor where a user could add content and apply. A quick way that we could provide additional help/value would be to pre-fill the form with a skeleton secret structure which includes the following:

apiVersion: v1
kind: Secret
metadata:
  generatedName: che-user-secret-
  labels:
    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: workspace-secret

At this stage we should also provide a table(?) of created secrets which the user would be able to view/edit/delete. This should update after a new secret has been added through the above form.

Creation / deletion of secrets should provide feedback inc. timeout error message.

Step 3

would start to add basic validation as described below:

We should check for these labels and show an error message if they are not there (error message should include these so they can be easily added):

    app.kubernetes.io/part-of: che.eclipse.org
    app.kubernetes.io/component: workspace-secret

And we should check if the annotation “che.eclipse.org/mount-as” and we should show an error message if it’s not there and if the value is neither “file” or “env”

che.eclipse.org/mount-as: file | env

If it’s a file then we should also check that the annotation che.eclipse.org/mount-path is there 

che.eclipse.org/mount-path: ...

If it’s an env we should check that at least one annotation with the suffix env-name is there:

che.eclipse.org/*env-name:...

Step 4

Would add the ability to select the type of secret that is being created (i.e. drop down menu of type, or + button then menu. Which asks for specific information they would already know about or know how to retrieve, and automatically create the full secret for them:

Describe alternatives you've considered

Additional context

An exploratory design concept is attached below

Che-User preferences Ext accounts Design concept

l0rd commented 3 years ago

@parvathyvr I would update the table like that:

Type Details Action
Git Credential Store Secret :
Maven Settings Secret :
SSH Key Pair Secret :
Docker Registry Credential Secret :
Generic Secret File Secret :
Generic Secret Env Variable Secret :

and instead of "Add External Account" button I would have "Add Workspaces Secret".

And for a first iteration I would only support Generic Secret File and Generic Secret Env Variable. And I would iterate sprint after sprint with the others types. Every type should come with a different input form (i.e. git credentials is a list of hostname/username/password lines, maven settings is an xml file and a path...).

sympatheticmoose commented 3 years ago

@l0rd I'm wondering about "Add Workspaces Secret". Which whilst accurate, offers little abstraction to the user from the mechanism we're using in kubernetes - which they shouldn't have to understand. It isn't necessarily a clear 'action' they would want to take to achieve (for example) connecting their Github account.

l0rd commented 3 years ago

@sympatheticmoose agreed. I haven't found anything better though. "Add External Account" doesn't work for tools settings that doesn't involve an external service (settings or git settings for example)

che-bot commented 3 years ago

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

themr0c commented 3 years ago

Is it possible to reconsider the priority to P1?

In the documentation currently have several procedures for the end-user containing some steps for "adding {orch-name} Secret containing ". It implies a major context change for the user: switching from the Dashboard, to CLI tools to convert the secret to base64, and to configure Kubernetes/OpenShift. This change of context is a major drawback for the end-user.

For the naming: what about simply: "Secrets".

For reference, the list of all pages containing a mention to provisioning a Secret:

End-user Guide

For all procedures, the user needs to expose secrets in a workspace.

Installation guide

Mostly unavoidable steps during installation, except for the last in the list, related to the actions in the End-user Guide.

Administration guide: