5 ms·
Starting today, this will be known as "Shanghai'd credentials" and be reason #1 why we use ephemeral credentials (e.g. AWS STS/SSO) rather than static credentia
by throwaway787544 4y ago
Starting today, this will be known as "Shanghai'd credentials" and be reason #1 why we use ephemeral credentials (e.g. AWS STS/SSO) rather than static credentials (e.g. IAM Users)
- throwaway2037 4y agoI never heard about "ephemeral credentials" before your post. I have some Googling to do!
- krageon 4y agoIt's essentially an access token with a very short expiry time.
- toomuchtodo 4y agoThe other term of art is “dynamic secrets.” https://www.vaultproject.io/use-cases/dynamic-secrets https://www.vaultproject.io/use-cases/dynamic-secrets
- 0des 4y agoGood lookin out, thanks for the link
- compumike 4y agoDoesn't the client still need to know a long-lived secret (or a long-lived refresh token) in order to generate the ephemeral credentials?
- toomuchtodo 4y agoIt can either use a secret injected into an env var to bootstrap rotating ephemeral/refresh tokens or use a role provided by the environment (which can also provide short lived tokens), depending on your runtime environment and use case (on prem, cloud, k8s, etc). Static, long lived secrets with limited governance that have no conditional access guards are weapons of mass self destruction.
- robonerd 4y agoKeeping secrets in environmental variables has always seemed dodgy to me. Unless specifically cleared, they get inherited by all child processes. Maybe there are never any child processes in your application, or that could be desired behavior in some circumstances, but generally it seems like asking for trouble.
- toomuchtodo 4y agoIts safety is proportional to your isolation model. Never use env vars for secrets when you’re executing arbitrary code, for example.
- RajT88 4y agoThere's also the reverse issue - if they change after your process is started. Refreshing an environment variable that has changed is (for me) a line I won't cross. Time to write the app a different way, once that becomes a concern.
- steelaz 4y agoWe got rid of all IAM users used by applications and moved to role-based access. Nowhere in the application do you need to enter AWS credentials. AWS SDK will attempt to discover short-lived credentials for you and will assume the role specified at the infrastructure layer, e.g. in a task definition.
- LilBytes 4y agosame here, but we still have IAM Users for service accounts. E.g. some customers have on premise infra that needs to talk to our services of infrastructure. Do you know a way where RBAC can be used for the above? For us, we're using long lived credentials in this space using IAM Users but with very tightly controlled authorisations.
- steelaz 4y ago"IAM Roles Anywhere" was announced just a couple of weeks ago. It might be applicable to your case. https://aws.amazon.com/about-aws/whats-new/2022/07/aws-identity-access-management-iam-roles-anywhere-workloads-outside-aws/ https://aws.amazon.com/about-aws/whats-new/2022/07/aws-ident...
- kbenson 4y agoOne of the major benefits of ephemeral tokens is that they become less attractive to put into the code, and more attractive to put in a config file/vault that's easier to update and keep secret. This in itself is useful because it makes it less likely that it will be in some source file someone shows, or pushed to some remote repo that at some point has permissions allowed so people can see it.
- thedougd 4y agoYou may also setup federated (trusted) relationships. For example, a GitHub Workflow can be trusted to assume an IAM role. In that scenario, there's no long lived secret in scope. The oidc subject includes the GitHub org, repo, branch, and environment for the IAM assume role policy to match or filter.
- jffry 4y agoFor my dev machine's interactions with AWS, I use https://github.com/99designs/aws-vault https://github.com/99designs/aws-vault You add the long lived IAM user API key/secret to it and it stores it in a password protected storage (MacOS keychain or similar). Then you invoke aws-vault with an IAM role and command, and it will handle obtaining short-lived credentials scoped to that role (including TOTP 2-factor code auth), and then run the command with those temporary credentials as env vars. With the right AWS permissions on your user, it can also automatically rotate the IAM user API keys for you.
- rad_gruchalski 4y agoI like your approach. So far I used profiles extensively. AWS_PROFILE is your friend. No idea why AWS doesn't heavily promote this everywhere they can.
- arjvik 4y ago> No idea why AWS doesn't heavily promote this everywhere they can. Not Invented Here
- moduspol 4y agoAWS SSO solves it better, and for any number of AWS accounts. I still use aws-vault, though, when I'm not in a position to set up AWS SSO.
- flyt 4y agoAWS best practices is to use AWS SSO, which accomplishes this same effect but without any long-lived local credentials. It works really well.
- LilBytes 4y agoDepending on your IdP there's a few tools in addition to AWS CLI v2 that works well in this space. aws-vault is one of them, though out of support now, aws-okta [1] is another. [1] https://github.com/segmentio/aws-okta https://github.com/segmentio/aws-okta
- FujiApple 4y agoYes, but credentials should either be long lived with (very) limited scope _or_ short lived with required scope. For example, for AWS you can create long lived credentials for users which are scoped to only allow one operation, namely obtaining a short lived token (with the aid of a hardware token such as a Yubikey) with scope to perform other operations. AWS guide here: https://aws.amazon.com/blogs/security/enhance-programmatic-access-for-iam-users-using-yubikey-for-multi-factor-authentication/ https://aws.amazon.com/blogs/security/enhance-programmatic-a...
- stefan_ 4y agoThis is not at all the takeaway from this. It's "this shitty developer should not have had access to this data in the first place". With a nuance of "this database probably shouldn't exist in this form in one place to begin with".
- babelfish 4y agoLet's not. After the whole "China Virus" shit propagated by the right, I'd prefer if we tried not to associate vulnerabilities with specific people.
- bequanna 4y ago
- xfitm3 4y agoI don't believe this comment is made in good faith, there is nothing wrong with the "right" and it's senselessly adding fuel to our political division.
- malcolmgreaves 4y agoThere is something deeply wrong with the authoritarian politics of the right and its casual use of racism to further political control. > it's senselessly adding fuel to our political division. This comment, whether you realize it or not, is coming from a place of extreme social privilege. Remember that for the majority of people, politics is not a game. It is serious. People lose their rights to live the life they want all the time. Sometimes those politics turn violent and people lose everything.
- markdown 4y agoIt's not a new word. https://dictionary.cambridge.org/dictionary/english/shanghaied https://dictionary.cambridge.org/dictionary/english/shanghai... https://www.urbandictionary.com/define.php?term=Shanghaied https://www.urbandictionary.com/define.php?term=Shanghaied
- malcolmgreaves 4y agoThat's not an argument for continuing to use a word.
- markdown 4y ago
- brianpan 4y agoSpeaking as an Asian American, no, let's not do that.
- throwaway787544 4y agoOk; could you suggest an alternate? Would be handy to have a shorthand to refer to the incident
- shirleyquirk 4y agonot their job. How about you come up with something catchy?
- brianpan 4y agoHow you come up with a name is up to you and how you use it. Personally I would go with "July 2022 Shanghai National Police database leak" because I'm not having any conversation where a cute codename would be less confusing. At work we codename security issues we are working on for Slack channels, etc. We use unrelated names that you could get from a name generator.
- xwolfi 4y agoWhy ?
- snovv_crash 4y agoShanghai'd is already a phrase that means something else, anyways.