3 ms·

> I feel like a better approach would be to specify what services you actually want to run and that requires a separate secret key that you will never use for o

by zokier 5y ago

> I feel like a better approach would be to specify what services you actually want to run and that requires a separate secret key that you will never use for other development tasks, You can get pretty far along by never using the root user, and having very limited iam policy for your day-to-day user. That is also what AWS documents as best-practice: > We strongly recommend that you do not use the root user for your everyday tasks, even the administrative ones. https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practi... You can not set quotas that way, but you can at least limit which services are accessible. Furthermore e.g. ec2 has fairly rich set of conditions you can use in policies to lock down the access even more: https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-policy-keys https://docs.aws.amazon.com/service-authorization/latest/ref...

caymanjim 5y ago
This is the right solution. Secure your root account, don't share the credentials, use 2FA, etc. Make role-based accounts with limited permissions and never put anything in the root account. AWS recommends it, and their UI encourages it, but doesn't require it. Third-party auditing services like Vanta are great for identifying issues like this that should be addressed. That said, AWS should make it easier or even require it. AWS is full of footguns and weak security defaults and small players (like the person who tweeted about the bill) lack the knowledge and experience to adequately defend themselves.
scrose 5y ago
I know not to use the root user and am aware of many of the advanced policy conditions you can use to help control usage, but that doesn’t address the ability for service usage to quickly spiral out of control from either simple mistakes or a compromised user. People make mistakes. People’s accounts get compromised. I’m sure AWS has plenty of data on what services are most likely to be abused and could come up with a UX that minimizes or prevents that abuse in a simpler way than just providing hundreds of configuration options and calling it a day.

by zokier 5y ago

caymanjim 5y ago

This is the right solution. Secure your root account, don't share the credentials, use 2FA, etc. Make role-based accounts with limited permissions and never put anything in the root account. AWS recommends it, and their UI encourages it, but doesn't require it. Third-party auditing services like Vanta are great for identifying issues like this that should be addressed. That said, AWS should make it easier or even require it. AWS is full of footguns and weak security defaults and small players (like the person who tweeted about the bill) lack the knowledge and experience to adequately defend themselves.

scrose 5y ago

I know not to use the root user and am aware of many of the advanced policy conditions you can use to help control usage, but that doesn’t address the ability for service usage to quickly spiral out of control from either simple mistakes or a compromised user. People make mistakes. People’s accounts get compromised. I’m sure AWS has plenty of data on what services are most likely to be abused and could come up with a UX that minimizes or prevents that abuse in a simpler way than just providing hundreds of configuration options and calling it a day.