#github-actions - May 2021

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?
•

Hello everyone,

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,

Thanks

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

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

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

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

https://github.com/bitflight-devops/github-action-readme-generator

I would like to know if the instructions to use it are clear enough. Input appreciated

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?