Discussions related to GitHub Actions
Has anyone encounter issues with github-actions with “Error: Resource is not in the state servicesStable” while deploying ECS ?
(please see sample below)
• this has been re-occuring multiple times, even attempts on different branch/environments as well.. anyone have a solution?
I’ve been writing some workflows for our team to build and deploy to AWS Fargate, I stored the AWS credentials as secrets and use them on the workflow, however I’ve noticed that any of the team members (which have access to the repos) could potentially create a branch and modify the workflow (or create a new one) and basically do whatever they want on AWS using the credentials in the secrets. I’d like to know if anyone has managed to solve this since it looks like a huge security risk,
you can control if forks can use actions from the main repo settings - if access is shared on the main repo you can select the default branch and protect it from merges
but what about feature branches in dev? the idea would be to be able to deploy any branch on dev
GitHub Actions: Limit which branches can deploy to an environment
might not fit your use case as it’s specifically for
Environments not just pipeline
look, the documentation is pretty clear on what the features are - branch protection rules enable that for custom branches as well so you just have to experiment with it a bit.
if I understand correctly you want X user workflow run on feature/* branches to not be merged on dev, which can not be merged if you protect them - leads to self-explanatory solution for me. if you let users freely push to dev and essentially don’t trust your devs you need to separate the orchestrator from the compromised system, that’s just common sense
You can create a branch protection rule to enforce certain workflows for one or more branches, such as requiring an approving review or passing status checks for all pull requests merged into the protected branch.
hey, thanks for the response man
well, not quite, as an example: if I create a workflow to deploy to production, (using production credentials in github secrets) everybody in the team will have access to those credentials basically
I was wondering how is that situation is being regularly handled, if at all
we’re a small team so most of the team has write access to the repos
team access, branch protection or even separate repository
however the flow you are using right now should define those limitations - when you know in step X exactly what user Y should do, you can figure out multiple strategies to limit that action from happening
I still don’t understand your problem very well but I would create a “secrets” repository outside developer access specific for production just to get it out of the way in like 15 minutes
and like change nothing for devs
The problem is preventing everyone in the team to change the workflows (or create a new ones) and deploy anything to any environment bypassing the approval process
as mentioned here
Enhancement: Provide role separation around who can edit contents of .github/workflows/ Reasoning: In an organization setting you have a lot of people who have write access to repositories. Add git…
no feature will be able to complement lack of security AND an orchestrator - regardless of what app you are building you can make it modular or container, etc, at which point you can call the resulting artefact in a different separate repository where there are no trust issues anymore. I am trying to think of helpful solutions but asking on e ops server how not to ops I feel will lead you into a rabbit hole that is deeper than actually figuring out your current problem - with that in mind it could be more productive to outlay your current limitations in a mock manner like: “I have environments X and Y in this flow running on these 2 example branches. workflow Z is leaking secrets - how to fix that ?” - not too intrusive but some other people might have solved the manner in a similar way or have public code they can show you
just reading that conversation on #458 is a head ache compared to stripping your current repo of secrets and workflows and running them from a bash script on another private repo where only trusted maintainers have access. don’t mean to sound harsh but it is a historical problem unrelated to github, rbac doesn’t really solve the problem if you cannot trust your team, preventing their ability to exploit is far better than adding more rules, code and verifications in a thin layer that has multiple system complexity
also, that pull_request_target issue was exploited multiple times and atm “solved”
they have a fair point for it, historically judging but IMO it’s philosophy not solveable by a 3rd party that will add even more complexity - just separate concerns and tackle them individually
mmm I get your point, thanks for bearing with me , I’ll work on your idea and see how it goes
Hey guys, I’ve just finished an npm tool and GitHub action that generates the readme content from the action.yml
I would like to know if the instructions to use it are clear enough. Input appreciated
the instructions are clear however there are still a couple of questions, I believe those answers could complement the front of your readme file - who is this targeted to ? as a gha user I missing the ability to manage badges and running them (problem solved by meercode) but as a gha developer , I would have to maintain the docs and releases more
skeptic or niche users could use some simplified example walkthrough / repo just to make it more predictable (but this could be overloaded by the other question)
My team has dependabot set up on our repos and it’s pretty useful for security updates. I wonder if we can configure it to also scan for non-security related updates for select dependencies. We want to keep a few things at their latest versions and doing it manually is annoying. Has anybody done something like this? Also is there a better place to ask about this?
not sure about dependabot but it sounds like what you are looking for is something like
npm-check-updates based script - you could use
ncu -f /regex/ -u to autoupdate in a script/github action/pr checker/etc
I use the renovatebot GitHub action which works well for pretty much all version updates.