That’s absolutely true. Too many app owners is a security risk. A single app owner is a security risk. I believe that’s why creating an explicit Owner role that can be restricted to two (sometimes three) users is a good practice. And then all other elevated users can be non-owner admins.
But I understand you’re taking a different path (company app ownership) to achieve that result, which is fine.
Though I’m not sure I understand how one solution precludes the other. Is there any harm in creating an additional role to represent ‘ownership’, even if the members are not true owners from the perspective of your internal data model? It wouldn’t need to be called “Owners”. As long as it provided the ability to have a restricted role that ensured no single user account is immune from deactivation by the company/team.
I Agree with the proposed Maintainer role and less permissive Developer role (without access to logs and without access to deploy to production). Admin role privileges are too much and risky for CI/CD. The maintainer role is suitable for CI/CD or trusted developers. The Developer role (without access to logs and without access to deploy to production) will be suitable for newcomers.
Will it be possible to be a contributor on multiple accounts? What I mean if person A wants to add me as a contributor to their app, will I be able to be a contributor on person B’s app?
Hello there! I agree with having custom roles where we can define them with their own permissions or at least having the third Maintainer role to be in charge of the CI/CD process.
In our particular case, if we should have a company account to be the owner some of the people that may access it may not be the ones ruling the CI/CD process, so it could be risky they can do some operations.
On the other hand, I’m curious about how are contributors going to be able to interact with environments. Before contributors, the owner is the one that can install by the Forge CLI to any instance from any environment. A link can be created to delegate app installation to others, but only to the production environment.
So, how can a contributor install from any environment to any instance? An example a use case here may be a CR of something it is deployed in the development / custom development environment and I want to test before approving it.
We are really exciting to be able to have contributors in Forge apps. By the moment, only the creator is the one who is accessing the app and the developer console and we want some of our Forge apps to be contributed by more people in different ways. So, for us, this feature is so important, thanks for making it possible!
Hi everyone ! I am trying to find out more about the Maintainer role suggested.
If the account with maintainer role is used in CI/CD pipelines, will its credentials be shared among your team members? If yes, how do you view it as a security threat given it will have additional permissions?
Do you think a role with only deployment permissions (prod/non-prod) is appropriate enough for CI/CD?
For CI/CD we’d also need to be able to upload the artifact.
We maintain our own artifact store and assume that the artifact needs to be re-uploaded at each deployment. Even if we didn’t we would need to upload it at least once.
Our CI/CD has it’s own set of credentials and it’s not shared with developers.
Not only for newcomers. I would love to restrict a development account to just one (or n) environments, with the ability to only deploy/install/see logs there - and I would use it myself as a safe guard when developing. The ability that I can easily deploy to production as developper scares me quite a bit!
We are grateful to each and every one of you who shared your valuable feedback with us. Your input has helped us come up with a better solution that addresses most of the use cases discussed in the RFC. Thank you for being a part of our journey towards improving Multi-User App Ownership.
What did we hear?
We empathize with the fact that many organizations must adhere to strict security compliances, which often require demonstrating control over production deployments and access to production logs. It is important to consider the principle of least privilege (PoLP) in these situations.
We understand that it is crucial for partners to avoid a single point of failure of app ownership.
What did we change?
We are pleased to inform you that we have added two new roles: Viewer and Deployer. Furthermore, we have made some modifications to the Developer role by revoking permission for production log access. Additionally, we are providing access to production logs as advanced permission that Admins can choose to add on top of the default role provided to users.
We are currently working on implementing these roles and user experience for Multi-User App Ownership. If anyone has any further suggestions, please don’t hesitate to reach out to us.
Hope this helps !
Design