New federated credentials for preapproved-prod github environment

[mirkoSekulic]

Description

We currently manage multiple services in our repository and deploy them using Flux. Our prod environment in altinn-studio repo on GitHub requires approval from a team member due to the protection settings for required reviewers.

However, we now have a different scenario. For one specific API, we want to bypass the review step. To achieve this, we need to create a new environment in GitHub that doesn’t have the required reviewers defined. We’re considering adding a preapproved-prod environment. This would allow us to deploy our API to production continuously, while maintaining the review step for other services.

[mirkoSekulic]

Hi, No branch other than main can use our prod environment. That's the protection policy that we defined in our environment in github. We're actively using a "prod" environment for all our services. But now we want to achieve continuous delivery. We can achieve that using the existing "prod" environment with just disabling reviewers settings in github. But that will affect our other services from repo which we don't want to deploy continuously, so we don't want to do that. Due to that, we need an additional environment. We'll configure our "preapproved-prod" environment that is only available from the main branch like we configured our prod environment. PR itself can't access the prod environment even if it's a PR inside our repo since it's a non-main branch.

…

On Sun, 8 Sept 2024 at 14:26, Andreas Isnes Nilsen ***@***.***> wrote: I'm probably not the right person that makes demands for a preapproved-prod environment in GitHub. Anyhow 😄 A design choice we made when creating the federated credentials project was to define a specific set of environments that should be used accross all teams. tt02 and prod are among one of these github environements where federation works. tt02 and prod must have reviewers due to: - Any branch can deploy to production without any reviewers. - We have a group in GitHub that contains all developers++ in Altinn (you probably familier with that group), the intetention behind this group is that any developer in altinn can create a PR in any repositories. Thus, having a preapproved-prod allows all developers in Altinn to actually release from the repository. - Not entirely sure of this, but forks of repos can also creates PR, but unsure if they can release or use environments etc. — Reply to this email directly, view it on GitHub <#905 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFSG6D7EYXHCM6CSQ72JTCTZVQ7BFAVCNFSM6AAAAABNTV3GMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZWGY3DOMRWGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[andreasisnes]

yes, I wrote the comment before checking environment configuration and protection branch, Thus I deleted the comment

[tjololo]

We are currently having another look at the products automation #914 PR#916
The need for team/product specific envs for federated credentials is something we probably should take into account.
For now I will create a new federation rule that satisfies the needs

[tjololo]

@mirkoSekulic is preapproved the correct name or is noapproval or continuous more describing? preapproved might be the correct one, just want to make sure you have had a talk about the env name in your team
Scratch that, I have created the azure side of the preapproved-prod federated identity for the prod user

[sduranc]

I think if this helps the team to go faster just go for it @mirkoSekulic. I understand that this will happen eventually with monorepos. Since we use GH environments this is inevitable and can't really see another way that adding a new env either. That being said, I don't think this really belongs to a golden path way of doing things.
Nevertheless, we shoud consider this scenario as a requirement/feature of the platform.

[tjololo]

I have manually created a federated credential for your prod user. It has a federated credential allowing you to get credentials when using environment: preapproved-prod.
Everything should be done from the platform side so the rest is up to you.