Access management in Altinn Studio

[GGunnar]

Description

In Altinn Studio all functionality is available for all members of an organisation. As the organisations will be managing more of the process in towards production it is therefore needed to apply some more access management on the organisations.

To get access management in the solution we should utilize as much as possible in the Gitea solution, by creating teams and setting restrictions to what a team member could do in Altinn Studio.
An org admin should have the possibility to edit how teams are set up and perhaps (must be found in the analysis) editing the restrictions in Gitea.

As we are utilizing functionality in Gitea and will not create new pages for access management for the org admin, the need for documentation is evident. The documentation should describe how the access managment is in Studio, so that it is clear what restrictions the users in different org teams could do. The documentation should also describe how an org admin could edit the teams, add members to the teams etc. (Ref #953)

Currently there is a restriction that only lets users in the "owner" team be able to create services, we need to look at if this is possible to bypass so that a member of another team is able to create a repo. This issue is already registered at: go-gitea/gitea#5114 . Possible to do with the use of sudo? (Ref #947)

When we use functionality in Gitea that includes teams, there will be a need to handle which teams have which repos available. If one where to say that a team would be "service developers" the repo needs to be added to this team in order to get the service developers to edit the app/repo. (ref how it previously was thought as a solution #948).

Depending on the solution found, there might be a need to create teams when creating an organisation in Gitea with the appropriate access. (ref: #949)

Once the solution is selected there is a need to be a clean-up of organisations and users in all the given environments in order to get the correct behaviour. This means putting users in the correct teams etc. (ref #950).

Only some users on an org should be able to deploy an Altinn app to production a org owner should be able to change which users are able to do this. (ref #951)
When solution is found it should be set up automatic tests that verifies that the behaviour is working as expected.

As the new access managment is implemented we also need to look at what messages should be given for the app-developers in Altinn Studio if the app-developer reaches some functionality he is not able to reach.

For users who is not a part of an organisation there should not be any specific access managment, meaning a user has access to do everything in his repo. Note that a user will never have the possibility to deploy a service to a test environment, as this will require an agreement with Altinn and that enviroments are set up for the given user.

Note that a previous proposed solution was that as long as a user had the Admin right and access to releases, the user should be able to deploy to production. This means that either the Owner group should be the only ones that have the possibility to deploy to production. If more teams are created it is important that the repos are added to the team that creates the repo, in order to get the rest of the team to have the new repo available.

For MVP the scope is that deploy is restricted to a group of people within the organisation. Other restrictions are at the time beeing out of scope. If something is found during the analysis should also be restricted, PO needs to be involved.

PO Statement:

Altinn or service owner/org need to have full control of who is able to deploy services to production. Further insight into the need of orgs could identify other changes that are also necessary.

Acceptance criteria

• It should be possible for the admin of an org to define which Altinn Studio users has the privilege of deploying to production in his/her organisation by using the functionality in Gitea
• It should be possible to edit a service without having possibility to deploy to production
• As an org owner admin, I should be able to controll who can deploy services to production. Not all developers should be able to trigger deploy of updates or new services.
• As a user on an organisation without deploy rights, I should get feedback from the solution that I have not got this right and how I could proceed in order to move forward.

In scope

• Access management for deploy of service to production
• Test of existing access management is working as expected
• Minimum - org itself have full control of users that could deploy

Constraints

• Gitea functionality should be reused as much as possible

Tasks

• Is this issue labeled with a correct area label?
• QA has been done

[altinnadmin]

I've now tested the functionality in Gitea, and it looks good. I suggest the following solution:

1. We create a set of standard Teams for each org in Gitea.
   
   • The Deploy-<env>-teams gives only read access to repos and membership will be checked by the deploy-page in Designer.
   • The Devs-team will give write access to repos, and have set the new "Create Repositories" setting
     
   • The Owners-team has admin rights and can edit teams etc.
2. We add checks in the deploy page in Designer so that a user must be part of team Deploy-<env> in the current org to be able to deploy to <env>.
   • We also needs to inform the user why access is not given.
   • Use this API in Gitea https://try.gitea.io/api/swagger#/user/userListTeams
3. We create documentation, and inform and help all orgs to use the new structure.

[ghost]

Can we call the teams Operations-Test and Operations-Prod to align with the rest of the rbac?

[altinnadmin]

Can we call the teams Operations-Test and Operations-Prod to align with the rest of the rbac?

That's possible, just a name. The question is if there is a need to give only access to deploy without giving access to "other operations-related stuff" (monitoring, etc?) and if there is value in being able to give access to just a specific test envionment (ATx, YT, a "new AT5" for training, etc.

@lvbachmann, what do you think?