Access Token Management

[mnuttall]

The 'first pass' at panelling for webhook management allows for access tokens to be created and deleted. We need a separate 'access token management' page where existing tokens can be presented in tabular form, as well as created and deleted. (Edit is not required.)

Consider whether users creating webhooks can be linked to and from a unified access token management dialog when creating one in the process of creating a webhook.

[kimholmes]

Is this a duplicate of #53 ?

[mii-w]

What I have so far: (first pass)

In process of finding a way to link webhooks and secrets

[mii-w]

right hand side multi-select seems to be more intuitive

[mii-w]

My mistake! I thought Secrets were Access Tokens..

Here is a quick update on Access Token panel:

[ncskier]

It was discussed offline that since Access Tokens are used by Tekton Pull Request Resources, we can integrate Access Tokens into the core Dashboard's Secrets page, instead of making Access Tokens a separate Extensions page. 👍

This raises a few design questions about how to create paneling for Secret with different types on one page. A big question I have is about which Secrets we will display. Right now we filter to only show Secrets of type corev1.SecretTypeBasicAuth (code here), but Access Tokens don't necessarily have a specific type. So how should we filter the Secrets page to only show BasicAuth and AccessToken Secrets? Would it be ok/better to show all types of secrets?

Also, would this be a good time to think about introducing SSHAuth Secrets to the Dashboard? (They're supported by Tekton's authentication). So maybe we should include them in the mockups even if the implementation work isn't given a high priority at the moment. (@mnuttall do you have any input on this?)

[kimholmes]

/assign mi-wang

[mii-w]

Latest Update:
Invision Link:
https://ibm.invisionapp.com/share/UBNZ3TAXAY2

[mii-w]

Updated Invision link:
https://ibm.invisionapp.com/share/X8NZ5IMQM4B

Please let me know if any links are broken and if you have any feedback/comment would be greatly appreciated :)

[kimholmes]

Comments on Invision prototype:
For the first screen you come to, it would better to start at the top of the detail window, and then show the screen where it has scrolled down:

• Once in the detail of a particular secret, do we need an "Edit" button? Should it not just be editable automatically?

• So, we took the bulk of the form out of the "create" dialog and put it in the detail of each Secret, correct? ex: annotations and service account dropdown?

Should the details section with the "edit" button and the "Create" dialog be separate?

[kimholmes]

User Experience flow is as follows:
For access tokens, when the user creates a Secret, they have a choice between two types of Secrets, one with Username/Password or one with Access Token.

Username/Password:

Access Token:

[ncskier]

It seems like there are a number of secrets & options that we can configure in the Dashboard, but at the moment we would like to keep things as minimal as possible. So, I did some research to try and clarify what we want to show in the Secrets view:

Tekton supported Secret types are:

• kubernetes.io/basic-auth
• kubernetes.io/ssh-auth
• Access Tokens (Opaque) (https://github.com/tektoncd/pipeline/blob/master/docs/resources.md#pull-request-resource)

And they also sort-of support:

• kubernetes.io/dockercfg
• kubernetes.io/dockerconfigjson

---

At the moment, it looks like we can cover all of our use cases by allowing users to manage the following secret types:

• kubernetes.io/basic-auth
• kubernetes.io/ssh-auth
• Opaque

These secrets will have the option of being patched to ServiceAccounts as regular secrets (not as ImagePullSecrets). For example, this script to prepare secrets for the pipeline-hotel Pipeline.

We must be able to add Annotations to the basic-auth & ssh-auth secrets, but not to the Opaque secrets.

Since we don't want the Tekton Dashboard to become a Kubernetes Dashboard, I think that we should keep our Secret management limited to this for now.

@mnuttall and/or @dibbles can you please validate that the scenario I've proposed above will cover all of our current use-cases with the webhook extension & tekton dashboard?

[dibbles]

technically correct i think..... but given the use cases and the fact it "sort of supports" the other secret type we might want to think about allowing creation of said docker secrets and patching .... maybe this could be separated as a follow on to reduce the scope of the task at hand.

I could see an argument for permitting the creation and patching of these if we think deploying an app is going to be something lots of people want to do. I'd defer to @mnuttall

[ncskier]

I clarified with Mark, that we are not concerned with kubernetes.io/ssh-auth secrets for Access Token Management.

[mii-w]

[mii-w]

wireframe mock-

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.