Brigade: brig enhancement: allow user to specify their own shared secret

[krancour]

brig project create doesn't allow users to provide their own shared secret in the way that the brigade-project Helm chart does. Users are forced to settle for an auto-generated value.

Why this matters...

Presumably, if one is using the Github GW, they will only wish to go through the pain of configuring a Github app once and then install that app into multiple repos within their org, but with shared secrets being auto-generated at the project-level, each Brigade project has its own, unique shared secret, yet the Github app can only use _one_.

To illustrate:

1. brig project create and walk through the interactive steps to create a new project. In the course of completing this, a shared secret will be auto-generated.
2. Follow the steps from the documentation to create a new Github app. Use the shared secret from no. 1.
3. Things should work!
4. brig project create and walk through the interactive steps to create _another_ new project. In the course of completing this, _another_ shared secret will be auto-generated.
5. This second project won't work!
6. "Fix" the Github app by using the project secret from no. 4.
7. The second project work now. 😄
8. The first project is now broken. 😢

The only way I have found to work around this is after creating a new project, manually edit its Secret to impose a shared secret of my choice-- i.e. the secret _already_ in use by other projects and by the Github app. This doesn't seem to be something we'd want to expect users to do.

I'd like to propose adding an option to the interactive steps of brig project create to allow users to bring their own shared secret. A shared secret can still be auto-generated if that is what the user prefers.

[radu-matei]

Yeah, I also struggled with this in the past - #816 has some major changes to the project creation workflow, you might want to take a look at that.

[krancour]

@radu-matei, I took a look at #892 (the PR for #816) and I don't see that this is addressed, so I'm going to work on this.

[eyjohn]

Just ran into the same issue, but even after I found that defaultSharedSecret works, I still found it an inconvenience that brig create project creates a new sharedSecret for me automatically, which causes the new project not to work until I manually unset the project specific sharedSecret (using kubectl edit in my case), +1 to have this as a prompt during the project creation step.

[krancour]

What I propose is a new multiple choice option during project creation:

1. Let the CLI generate a new shared secret for the project.

2. Specify a shared secret yourself-- a follow-up question prompts for the secret.

3. Use the gh gateway's default shared secret (if defined). __Note:__ We actually have no practical way of knowing whether that has or hasn't been defined. This is accomplished by using an empty string for the shared secret. Ever since https://github.com/brigadecore/brigade-github-app/pull/54, the gateway knows how to fall back from the empty string to the default. The caveat here is that if this option is selected and no default shared secret is defined on the gateway, there will obviously be issues with Github delivering events to the gateway. Since the gateway by, default, _does not have_ a default shared secret, we can count this as a more advanced option. This is why I am proposing this be the _last_ of the three options... although, it's frankly, the most useful option.

All of the above is less than ideal, but it addresses the issue with no breaking changes. Ideally, longer term (if and when we can accommodate breaking changes), it might be nice to remove this field from the project level entirely and _require_ a default shared secret be set on the gateway.

[radu-matei]

Not being able to specify the shared secret actually makes most projects unusable without manually editing the project secret, and we should prioritize allowing users to set it in brig.

[krancour]

The shared secret is managed separately from all the other secrets though. They're separate fields in the project.

[radu-matei]

Sure, but some gateways primarily use the shared secret to authenticate (the GitHub app, for example), meaning that after you create a project with brig, you have to manually edit the project secret before using it.

[krancour]

@radu-matei my apologies... I mentally crossed two separate threads here. Please disregard my previous comment.

Not being able to specify the shared secret actually makes most projects unusable without manually editing the project secret, and we should prioritize allowing users to set it in brig.

Yes. Yes. Yes.

[eyjohn]

thank you :)