Pipeline pull request promotions security review ADR

[makkes]

Closes weaveworks/weave-gitops-enterprise#2472

[bigkevmcd]

If you're going to store PATs, then you have some other considerations...

1. Make it clear in the frontend when the token is not longer valid "The stored token is no longer valid"
2. Make it clear in the frontend which user the token is from

For 1, we built an endpoint that called this https://docs.github.com/en/rest/users/users?apiVersion=2022-11-28#get-the-authenticated-user in the background, and reported a failure if it was no longer valid.

This needs to be cached, otherwise it uses API counts each time (think several users loading the page).

For 2 we used the response to render the "gravatar_url" in the UI which helped users

"Oh, the token was created by John, he left last week, that's probably why it's failing"

[enekofb]

added https://github.com/weaveworks/weave-gitops-private/pull/110/files#diff-e95866bc4a4c13e6572b56bcad799f2b50bdf15d23331c2e089edc53e74976c3R57

[enekofb]

Suggestions (not in any particular order)

• extend documentation to provide by git provider examples on how to achieve the setup that we consider the most secure
• ensure that pipeline controller has all the checks required to avoid escaping from the right security context - for example opening pull request in a repo that is not the pipeline one, etc ...

[enekofb]

i will come back to the ADR once covered the docs PR weaveworks/weave-gitops#3426

[enekofb]

to pair with @yiannistri and @ahsayde to understand what we could leverage from policy and secrets to enhance pipelines security

[enekofb]

From @bigkevmcd , @MostafaMegahid @yiannistri @enekofb

Scenario A:
As app team that want to leverage pull request creation
automation but having full control
-> i am developer g

• go to wg pipelines
• my pipeline has some configuration for this pull request manual
• there is a new version, so there is deployment happening by flux
• there is promotion pending
• promotion dev to test approved interactively by developer A
  via oauth access token (currently we dont have)
• if there is a promotion going from test to prod we could
  a) cache the token (with short XXX)
  b) request another authn

Scenario B:
As app team i want to leverage pull request creation automation
with maximum security https://fluxcd.io/flux/guides/image-update/

a) assumption we have a token

• create branch no pull request
  -> what is the security here? there is a branch so the user
  a.1) create the secret in an admin protected ns so the admin
  acts a as gatekeeper for approving, etc ...
  for pipeline-system
  • granularity -> assuming that the token can only give access
    to resource for the operation.
  • short-live -> ephimeral token -> generate

b) we dont have a token (expensive to build )
as pipeline controller i am able to generate an ephimeral token
to create a pr for a particular actions
- option a: github apps
- option b: github apps like generic -> vault backend