Intentionally Leaking AWS Keys
brokenco.de
brokenco.de
14kb in your bucket and you pay for outgoing traffic. means, while you're sleeping, I can ruin your aws bill.
In any case, committing credentials is always wrong and you cannot justify it.
Depending on your ci tool (e.g. gitlab-runner, drone-ci ... ) there are other and better ways to provide credentials for a git project in CI/CD pipeline.
To be clear, I'm no aws advocate.
Yes, it sucks if someone randomly decides to download files from you all day. You should probably set your budget to alert and attempt to blacklist them when it happens. That’s rare, though, and aside from a few cases of actual malice, the convenience is worth the cost.
“Always”
1. AWS Lambda is "verifiable infrastructure". You can fetch the code and verify that it's the same code as what you've provided elsewhere (as a reproducible build for eg)
2. Use the lambda for trusted-code-execution (say collecting hashes of your contact list, matching them against a bloom filter). The code isn't supposed to log these contacts, or save them in any way.
3. You create a AWS IAM keypair that has permissions to get each revision of the lambda code, validate the corresponding API endpoint.
4. Instead of using a custom-domain API Gateway, you instead use the AWS execute lambda endpoint. The request directly reaches the lambda - verifiably (I think).
5. Publish the keys for the AWS IAM keypair that was created above.
Anyone in the world can then call up the Lambda management API to validate the code at any time with these credentials. If you trust AWS Lambda and IAM, there is a verifiable trust in the code that is running on that lambda and that is processing your contacts.
This might be possible by setting up an IAM Assume Role against the * to allow any AWS user the same permissions, but I'm not sure if that's allowed?
Edit: Documented on my ideas repo https://github.com/captn3m0/ideas#verifiable-code-execution-... , if someone is interested in building this
Route53 is also tricky, because you will need to prove the whole chain from your namesever. It won't even work for domains registered outside AWS, because you could have a second NS listed and that needs special treatment to catch.
Using the Lambda execution endpoints (the ones that look like https://API-ID.execute-api.REGION.amazonaws.com/STAGE) avoids a lot of these concerns.
If good uses were common—and I'm struggling to come up with them—AWS could suppress the alert for IAM users that were already sufficiently locked down. But since that would become dangerous if the permissions were loosened later, AWS would wind up creating two classes of keys, public and non-public, in order to know whether to warn about loosening restrictions. Simpler just to forbid making keys public.
To publish such a key anyway without having to go to the trouble of unwinding an AWS auto-quarantine, breaking it up in code (like "part1" + "part2") might be enough to foil the AWS bot. Can anyone confirm?
But if that's the code path that needs testing then it should probably be isolated to an auth library that can be tested by simply authenticating with the secret key alone and not needing to perform a chargeable action.
I'm not sure why the author thinks this required putting the credentials in the code itself. Heck, I'd argue that this integration test should be setting up the bucket and contents as part of the setup for the test itself, pulling the credentials from some sort of secrets manager.
It seems the test is about the data within the bucket assuming the correct format, not the connection to S3. Perhaps we can trust the author to have considered other ways to test this more properly that either wouldn't work for reasons or weren't nearly as fun.
If security is legitimately not orthogonal to functional testing then that is the interesting part of the problem, but I don't see that laid out in the article. It would be a case for AWS and others to improve or add methods to support the test case in a secure way.
They're self-limiting the effectiveness and thoroughness of their testing because they aren't willing to setup a proper integration test server w/credentials. Where else are they cutting corners?
The integration tests server should have its own credentials to access the resources it needs for testing, then it would support all types of testing beyond the "safe" read-only tests they're talking about in the article.
AWS quickly shut it down and informed me. I came back to find millions of queues created and somebody execute 100 million lambda queries.
AWS refunded me and I have been with them since. This is a very different experience to what happened with Google. They ignored my email and basically I learned that if I did a chargeback, they would shut down my other services too.