These guys do an insane amount of engineering to speed up builds and everyone follows. Love their blogs.
Zero chance I'd sign up for their competitors knowing how good the product is and that everyone else follows them. I don't know why Docker, JFrog, or GitHub don't just buy them already.
Depot is freaking awesome. Sped up two of our Docker image builds from 11 minutes to 1-1.5 minutes and the drop-in Docker build replacement in GitHub Actions was super easy. Can't imagine our CI/CD system without it.
Yes, you'd have to leverage compromised credentials. That could be obtained via SSRF, RCE on a privileged box, leakage of user access keys, or other means. In the context of a penetration test, it's more of a post-exploitation tool.
for sub in `az account list | jq -r '.[].id'`; do \
for rg in `az group list --subscription $sub | jq -r '.[].name'`; do \
az group delete --name ${rg} --subscription $sub --no-wait --yes; \
done; done;
Author here :) Endgame exploits/abuses features. If it was a bug, I'd work with AWS to solve the problem, but with abusing features - that would result in years of unsatisfied feature requests. This should push the issue along.
>...and it's not even a hacking tool!
It can be used to backdoor resources to rogue accounts, so I'd say it's a hacking tool and can/should be used on penetration tests. I'd certainly use it on a pentest :)
You are so right on the SELinux comparison. Of course, in this case, there are way more developers that are required to write them.
Reiterating what was mentioned in the thread - the best way to avoid this wildcard situation and make it easier for developers is to use Policy Sentry[0]
Thought I’d mention this for those who read the title and the comments instead of clicking on the tools. This will solve most of your problems with writing IAM policies for machine roles.
PMapper is definitely a great tool. It’s best used in Pentests for validating some privilege escalation paths. It has the benefit of analyzing IAM trust policies, resource based policies, viewing escalation paths in a graph based approach. Very underrated indeed.
Cloudsplaining is faster at creating a more comprehensive report. We realize that there is lots of damage that can be done just by being able to modify Infrastructure, even when your privileges fall short of legit privilege escalation.
Not one step exactly, but it is by far the easiest way to write least privilege IAM policies. Otherwise, it becomes impossible to ensure IAM policies are written securely and at scale. This way, all custom IAM policies are written with the exact same methodology.
Zero chance I'd sign up for their competitors knowing how good the product is and that everyone else follows them. I don't know why Docker, JFrog, or GitHub don't just buy them already.