Provide Easier Support for multiple dev-hub-auth-url credentials

[CloudPremiseDev]

Feature Type

I'm interested in functionality that solves a current problem or limitation in how CumulusCI works.

Does your feature request solve a current problem?

The issue that I have run into while using CumulusCI and Github Actions to manage my AppExchange application is that I have found a potential vulnerability to the way that Salesforce has designed the devhub. A single dev-hub-auth-url gives access to spawn scratch orgs, create packages, and publish packages. I believe that this creates a security vulnerability unless customers understand the potential implications of a single dev-hub-auth-url.

As it currently stands, if I have write access to anyone's CumulusCI project that is configured with a single dev-hub-auth-url secret, I would be able to create a managed package and publish it without any need for a Pull Request or administrative review. This is due to the fact that the .github/workflow files will execute immediately upon a push or pull request, and operate in the context of the pull request branch. Therefore the code in the pull request branch could easily be uploaded to a managed package and even published. If a customer has setup automation workflows beyond a package publish (such as distributing the app to customers) those workflows would also be executed causing unreviewed code to be pushed into a customer environment. Given the nature of the security landscape in 2024 I believe that we must build rigid security and the principle of least privilege into every part of the system, whether it is the software or the process and documentation that use the software. Each engineer must apply best practices to ensure security in maintained throughout the entire application lifecycle.

Describe the solution you'd like

CumulusCI is an innovative product that is very powerful and can be setup by following the documentation without any help. That is one of the things that makes this product so good. Therefore I think that this project should set the precedence that operational security is just as important as security within the code itself, and so therefore I think that the concept of separating production and non-production environments should be added directly into CumulusCI.

I would propose that CumulusCI software and documentation be updated to create a separation between production and non-production that can be implemented into Github or wherever CumulusCI is running from. The production devhub-auth-url would be restricted to production forks or Github environments, and therefore there would be a strategy and approach to keep bad code from being injected into the managed package (or from any other security concern that is created by giving developers direct access to the devhub-auth-url in their unapproved pull requests).

This would also help anyone using the application to understand that it is their responsibility to protect the production devhub-auth-url from code injection security attack vectors.

Describe alternatives you've considered

The only work around I currently know to do would be to create 2 completely separate repositories (forks may work) to manage production and non-production environments. This also requires two completely separate devhubs to be created, and I do not know how customers can easily do that (without setting up a trial devhub that expires after 30 days).

Regardless of the solution, whether code is changed or not for this, I believe at least the documentation and process should call this out as a best practices so that customers can understand and determine how best to manage the risk of a single dev-hub-auth-url.

Additional context

No response

[Julian88Tex]

While it is mentioned here in the documentation, this appears to be in a 1GP context. It should be clear that 2GP environment variables should be used to separate users with packaging privileges from those with access to a DevHub.

Also, here and here there are comments in a code block examples which mention a change for 2GP. Instead, there should probably be a separate 2GP example that shows how to set environment variables with a given DevHub URL secret.

More details in our conversation here: https://trailhead.salesforce.com/trailblazer-community/feed/0D54V00007cmPkb

@CloudPremiseDev, you mentioned a potential code solution. Is there a reason that GitHub environment secrets aren't the solution?

[jstvz]

@CloudPremiseDev The documentation linked by @Julian88Tex covers both the 1GP and 2GP use cases for this scenario, so I’m closing this issue. If I misunderstood your request for an enhancement, please reopen with more details.

[Julian88Tex]

@jstvz While it technically does mention it, I think the examples are a bit misleading since they don't specify that you should use a DevHub user that specifically has access to packaging privileges and is specifically an environment secret with branch protections.

[CloudPremiseDev]

Yes that makes sense, if you had two users in the same devhub and only 1 had packaging permissions - if this prevented the non-packaging user from being able to generate packages in the namespace then that removes the security concern. It would not allow the other devhhub user to create beta packages for testing purposes however, which has been a nice feature to enable for developers. I'd rather take that away completely, however, than have to setup a completely second devhub. Either way I think the best practice for how to do this in a production environment is still not entirely clear. If cci would not be updated to support a different configuration (I'm honestly not sure what that would even be) then at least more emphasis, examples, and even more stern warning in the documentation would be appropriate due to the self-serve nature of this app and community.

On Wed, Jul 24, 2024 at 2:44 PM Julian Joseph @.***> wrote:

@jstvz https://github.com/jstvz While it technically does mention it, I think the examples are a bit misleading since they don't specify that you should use a DevHub user that specifically has access to packaging privileges and is specifically an environment secret with branch protections.

— Reply to this email directly, view it on GitHub https://github.com/SFDO-Tooling/CumulusCI/issues/3812#issuecomment-2248865963, or unsubscribe https://github.com/notifications/unsubscribe-auth/BG3I4W474VSDU5LUAER7M3TZOAG2FAVCNFSM6AAAAABLI6EXEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBYHA3DKOJWGM . You are receiving this because you were mentioned.Message ID: @.***>

-- Greg Cook @.*** 615.521.1117

[Julian88Tex]

@CloudPremiseDev sounds like there is a very valid Salesforce feature request in there. A permission that specific allows for creation of beta packages vs. production packages. I'm not sure CumulusCI "should" be the one to handle this feature. In theory CumulusCI would somehow have to limit permissions of a given DevHub user whereas there's a strong argument that, that is the Platforms responsibility and it would be an anti-pattern to have CumlusCI do it. I really think this would be a good question to pose to the 2GP PM team. How can you allow developers to get the benefits of testing with 2GP package builds without the risk of being able to create a production package? If you take CumulusCI out of the picture this issue would still be happening if the team was only using the Salesforce CLI.

Hm, also thinking through if this issue is more tied to the setup of GitHub Actions. In a sense we want to mimic actions that can do release-like things but without the risk of developers actually releasing things. Feels like certain GitHub Actions should be able to be created by GitHub admins and run on lower branches without the ability of developers to interfere with them due to security concerns. This may be possible in some way but I can't think of what setup would work.

Going back to Environment Protection Rules, while this isn't the most ideal workaround I think you could set them up in a way that a particular job to create beta packages would run if an admin approves a PR. In this way, you could ensure only admin-viewed code would ever be used to generate a package but the package could still be a beta on any branch. The downside is that this would require admins to be more involved in the PR process and/or beta packages not being generated until a PR is ready for approval.