CD Prevent Access to overwrite Production Data

I’m probably trying to tackle this the wrong way. Deploying Azure resources using ARM Templates and then deploying code.

I’ve noticed that workflows can be written and edited by Writers (as it states here: https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization )

Which means that there’s a chance for people to clone the workflow file, update it incorrectly and then push it to their branch. Actions will then execute and potentially wipe out production.

Is there anyway to ensure that SECRETS are branch specific? Doing so would ensure that only the main branch has access to Production, whilst all of the others get access to Development.

I’ve already tested the Branch deploying if configured properly however user error makes me wonder on the what-if side. There’s potential to cause issues due to how open Github Actions are really.

Cheers,
JD

@jdelforno,

You can try to set the Branch protection rule for all the branches in your repository.

If so, the collaborators can’t directly push new commits to any protected branches in the repository. The collaborators must push the new commits to a fork repository and create a pull request to merge the commits from the fork repository into the main repository.

Only the repository owner and administrators can bypass these restrictions from the rules.

When the workflow is triggered by the pull requests from fork repository, it can’t access the secrets set in the main repository by default.

1 Like

@brightran,

Thanks for confirming that. We’ve looked at creating forked repo’s for each product however doing so would create a lot of overhead.

We can see the use case for Forking on a publicly accessible repo however on an internal one, we don’t believe it should be necessary.

Cheers,
JD

@jdelforno,

Currently, the access of secrets only have restrictions for workflow from fork repositories. For the branches in the main repository, we have no built-in methods to set restrictions. And we also do not have any available workarounds to do this.

@brightran

That’s unfortuante. In terms of performing a Dev / Test / Stage / Production pipeline then, is there a best practice that I’m missing to prevent deployment creep?

I’ve come from an Azure Pipelines background and finding out the Actions isn’t quite able to do this yet without creating a Fork is somewhat alarming.

Cheers,
JD

@jdelforno,

I’ve come from an Azure Pipelines background and finding out the Actions isn’t quite able to do this yet without creating a Fork is somewhat alarming.

Yeah, unlike Azure Pipelines, GitHub Actions does not integrate so many features, and it looks like a lightweight CI/CD services.

Of course, if you really need the similar features on GitHub Actions, I recommend that you can directly share your feature requests here. That will allow you to directly interact with the appropriate engineering team, and make it more convenient for the engineering team to collect and categorize your suggestions.

In addition, you also can follow the “GitHub public roadmap” repository where you can learn about what new features the appropriate engineering teams are working on, what stage these features are in, and when the teams expect to bring the features to you.