3 ms·

Regarding 1, my own cli runs aws-vault set-up such that I need to enter a totp code to assume a privileged role. It sounds like really basic security - my save

Regarding 1, my own cli runs aws-vault set-up such that I need to enter a totp code to assume a privileged role. It sounds like really basic security - my saved credential can't go delete servers. Absolutely everyone, from aws certified people to apparently renowned developers have gotten stuck into me over this, with complaints from "I'd quit anywhere that did that" to "bad setup, proper iam never requires mfa". I'm sure there's going to be some form of blow up where long term saved credentials eventually come out as problematic, and it will blow people's minds.

sylens 4y ago
aws-vault is an amazing tool that really simplifies working with lots of aws accounts in a secure fashion
jffry 4y ago
Do you get such pushback over the need for MFA, or more generally for the use of roles, or something else? MFA seems like an essential defense-in-depth measure to ensure that a compromise of the locally held IAM key is not enough on its own to compromise your AWS account.
- technion 4y ago
  It's just the workflow. Mfa is fine with passwords and console, but everyone has been educated to understand once they have a iam key saved on a disk its no longer correct to have.
  - jffry 4y ago
    Maybe that's because AWS' own aws-cli setup encourages you to store these credentials on disk in plaintext in a standard-named file in your home directory, and their best story for temporary roles is to invoke `aws sts get-session-token` and copy paste values from the JSON output to env vars. It's really disappointed that aws-cli doesn't easily support this type of workflow, when using MFA and setting up multiple AWS accounts with cross-account roles are two things recommended as security best practices by AWS themselves. Don't get me started on how you can only have a single U2F key attached to your root user.
    - technion 4y ago
      I agree with that being a major part of the problem. Regarding root, I always create an account with a console login that can remove the root user mfa or reset a password, it becomes the recovery account and I can put its own key on it, and ideally never gets used once tested.
    - layble 4y ago
      Fought with getting a nice workflow with the cli that supports MFA. I got it working and wrote it up here. https://www.nicks.io/simplifying-using-the-aws-cli-with-mfa/ https://www.nicks.io/simplifying-using-the-aws-cli-with-mfa/
AtlasBarfed 4y ago
MFA gets in the way of automation, and large scale adhoc actions. Say I want to load a huge amount of data, or do a ton of s3 uploads. My role assumption via MFA / TOTP lasts 4 hours. Now say you are doing lots of different "big data" flows, how do you assume privileges when you need them? I understand what MFA / TOTP brings to security, but security people pretend like my job is about logging into a box once-in-a-while for a couple minutes, and that is the ONLY USE CASE. Least privilege is another thing that sounds great to a security guy but is a nightmare for development. So whenever you do anything off the beaten path (diagnose new systems deployed, try new database backends, do some data moves or loads, backup/restore), uhoh, you spend a ton of time diagnosing shortfalls and decoding error messages. The security guy DOES NOT CARE. S3 is a perfect example. S3 should be simple. It is a nightmare of permissions on the user side, permissions on the bucket, and even worse across accounts. Tiresome. Magic numbers/dates for the "version" field policy, what is with THAT? ACLs/Policies stomping over each other. The funny thing is, ask a security person to first enable cloudwatch and dig through the data to find issues and vulnerabilities, or ask security people to actually produce well-tuned IAM roles for what you need. Guess what? They don't want to do it. They want to sit around making checklists and sending memos.

sylens 4y ago

aws-vault is an amazing tool that really simplifies working with lots of aws accounts in a secure fashion

jffry 4y ago

Do you get such pushback over the need for MFA, or more generally for the use of roles, or something else? MFA seems like an essential defense-in-depth measure to ensure that a compromise of the locally held IAM key is not enough on its own to compromise your AWS account.

technion 4y ago
It's just the workflow. Mfa is fine with passwords and console, but everyone has been educated to understand once they have a iam key saved on a disk its no longer correct to have.
- jffry 4y ago
  Maybe that's because AWS' own aws-cli setup encourages you to store these credentials on disk in plaintext in a standard-named file in your home directory, and their best story for temporary roles is to invoke `aws sts get-session-token` and copy paste values from the JSON output to env vars. It's really disappointed that aws-cli doesn't easily support this type of workflow, when using MFA and setting up multiple AWS accounts with cross-account roles are two things recommended as security best practices by AWS themselves. Don't get me started on how you can only have a single U2F key attached to your root user.
  - technion 4y ago
    I agree with that being a major part of the problem. Regarding root, I always create an account with a console login that can remove the root user mfa or reset a password, it becomes the recovery account and I can put its own key on it, and ideally never gets used once tested.
  - layble 4y ago
    Fought with getting a nice workflow with the cli that supports MFA. I got it working and wrote it up here. https://www.nicks.io/simplifying-using-the-aws-cli-with-mfa/ https://www.nicks.io/simplifying-using-the-aws-cli-with-mfa/

AtlasBarfed 4y ago

MFA gets in the way of automation, and large scale adhoc actions. Say I want to load a huge amount of data, or do a ton of s3 uploads. My role assumption via MFA / TOTP lasts 4 hours. Now say you are doing lots of different "big data" flows, how do you assume privileges when you need them? I understand what MFA / TOTP brings to security, but security people pretend like my job is about logging into a box once-in-a-while for a couple minutes, and that is the ONLY USE CASE. Least privilege is another thing that sounds great to a security guy but is a nightmare for development. So whenever you do anything off the beaten path (diagnose new systems deployed, try new database backends, do some data moves or loads, backup/restore), uhoh, you spend a ton of time diagnosing shortfalls and decoding error messages. The security guy DOES NOT CARE. S3 is a perfect example. S3 should be simple. It is a nightmare of permissions on the user side, permissions on the bucket, and even worse across accounts. Tiresome. Magic numbers/dates for the "version" field policy, what is with THAT? ACLs/Policies stomping over each other. The funny thing is, ask a security person to first enable cloudwatch and dig through the data to find issues and vulnerabilities, or ask security people to actually produce well-tuned IAM roles for what you need. Guess what? They don't want to do it. They want to sit around making checklists and sending memos.