16 ms·

IAM Is The Real Cloud Lock-In

PaulHoule 8y ago
Alternately, IAM brings AWS customers a lot of value. Do you think the average enterprise could develop a unified system for access control to cloud resources that would have a prayer of being secure? Would the average enterprise be able to develop such a system (secure or not) that wouldn't bring work to halt?
- sl1ck731 8y ago
  The author says as much. The title is clickbait, but the article basically says you're locked into AWS no matter what, and arguing over stuff like Lambda lock-in is pointless considering the other avenues AWS already has you on (like IAM).
- wmf 8y ago
  The average enterprise would buy something like SailPoint which claims to provide IAM for tons of things including AWS.
based2 8y ago
like MS/Azure Active Directory.
- idbehold 8y ago
  Did you even read the article?
  - nothrabannosir 8y ago
    Please don't ask that. It's in the HN guidelines: > Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that." – https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    - plorkyeran 8y ago
      That comparison isn't something the article mentions; it is the article.
mentat 8y ago
Might be nice if the author understood the difference between the CEO and CTO before he went off insulting their positioning.
xrd 8y ago
It's a back and forth. You get excited about building lambda functions and are surprised at how easy they are, and how much autonomy you have as a developer. Then, you try to deploy them, and realize you have to file 14 tickets to get the correct IAM settings setup for your production function. No one knows all the permissions you need, and the only way to understand is to try one, see if it works, and what other services you need access to. And, it'll kill all sense of autonomy you had a few hours prior.
- snypox 8y ago
  I wish people would speak about this problem more. I can’t tell you how many times I need reiterate certain things with our DevOps team to get the proper permissions because I can’t seem to get it right the first time.
  - scarface74 8y ago
    So you didn’t test it in a dev account first?
    - xrd 8y ago
      If the dev account role has different permissions, it doesn't matter. Of course (s)he tested it first in a dev account. The point is the context around roles matters much more than the code that runs inside it, a critical flaw of AWS. Fairly, this problem is definitely not just limited to AWS but I find their implementation particularly poor.
      - scarface74 8y ago
        That’s still the issue. You should have a custom role for each set of lambdas that make up a service. Your role and your lambdas should be in the same CF template that can be deployed together. Security best practices is for the role to have the least amount of privileges the lambda needs. Not just one generic “lambda role”. Whoever is responsible for production deployment could audit the role’s permissions and the definitions would be in source control.
kodablah 8y ago
> I'm referring, of course, to AWS IAM, which absolutely is the worst form of cloud lock-in that currently exists, at least relative to the zero people who seem to be talking about it. I assume people don't talk about it because it's not trivially solvable. While we can have many abstractions out there, abstracting IAM across providers is very difficult because while you could get roles and users/members/policies abstracted, you couldn't get resources and permissions abstracted. They are too bespoke. The best you could hope for is a common API, but you'll still be provider-specific in everything you pass.
013a 8y ago
The only people worried about vendor lock-in are people who have practically nothing of value to be locked-in. "Lambda is horrible for lock-in, once you're hitting billions of invocations a month you're going to wish you could cost optimize by shopping around with other providers! I've got my personal website hosted there, it gets a dozen hits a month, sure glad I'm inside the free tier." I've heard CTOs/CIOs of large companies express concern over it, but at the end of the day they'll sign that $100M contract with Amazon or Azure. It doesn't actually matter. Its a concern, but its not going to stop the sale or development. Today, if you're not locked in, you're leaving business value on the table. I hope that changes in the future, and maybe Kube will be the standard platform we've needed to push it forward (for example, I wish I could tell kube "give me a queue with FIFO and exactly once delivery", it knows what cloud provider you're on, if you're on AWS it provisions an SQS queue, if you're on GCloud it errors because they don't have one of those yet, and in either case I communicate with it from the app using a standard Kube API, not the aws-sdk). But for now, lean in. Don't fight the lock-in; every minute you spend fighting it is a minute that you should be spending fighting your competition.
- cosmodisk 8y ago
  Vendor lock-in isn't something anyone, especially at C-level should be ignoring. Yes, there are things to be gained and money to be made,but one should always have some sort of alternative,just in case. I happen to be in a business,which 100% relies on one vendor,which keeps hiking up prices every year way above inflation.
  - HillRat 8y ago
    The flip side of vendor lock-in — at the megacorp level, anyway — is the “one throat to choke” principle; sure, it might be hard to migrate off AWS/Azure/IBM, but (a) your technology investments have a timespan measured in decade-long iterations; and (b) what you really want is to ensure reliable operations for your enterprise. Sure, you may be stuck with cloud vendor x for the next ten years, but at least you know who to scream at if the infra goes south — preferably someone who can mobilize enough engineers to get you back up and running right now. Having said that, if you’re a small company where cloud budgets are a significant portion of your overall spend, or a tech company that has a defensive need to be able to migrate providers, YM will definitely V.
bradknowles 8y ago
I'm not worried about AWS IAM. I'd love for my problem to be that small. I'd like to get off Azure SSO.

Alternately, IAM brings AWS customers a lot of value. Do you think the average enterprise could develop a unified system for access control to cloud resources that would have a prayer of being secure? Would the average enterprise be able to develop such a system (secure or not) that wouldn't bring work to halt?

sl1ck731 8y ago
The author says as much. The title is clickbait, but the article basically says you're locked into AWS no matter what, and arguing over stuff like Lambda lock-in is pointless considering the other avenues AWS already has you on (like IAM).
wmf 8y ago
The average enterprise would buy something like SailPoint which claims to provide IAM for tons of things including AWS.

based2 8y ago

like MS/Azure Active Directory.

idbehold 8y ago
Did you even read the article?
- nothrabannosir 8y ago
  Please don't ask that. It's in the HN guidelines: > Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that." – https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
  - plorkyeran 8y ago
    That comparison isn't something the article mentions; it is the article.

mentat 8y ago

Might be nice if the author understood the difference between the CEO and CTO before he went off insulting their positioning.

xrd 8y ago

It's a back and forth. You get excited about building lambda functions and are surprised at how easy they are, and how much autonomy you have as a developer. Then, you try to deploy them, and realize you have to file 14 tickets to get the correct IAM settings setup for your production function. No one knows all the permissions you need, and the only way to understand is to try one, see if it works, and what other services you need access to. And, it'll kill all sense of autonomy you had a few hours prior.

snypox 8y ago
I wish people would speak about this problem more. I can’t tell you how many times I need reiterate certain things with our DevOps team to get the proper permissions because I can’t seem to get it right the first time.
- scarface74 8y ago
  So you didn’t test it in a dev account first?
  - xrd 8y ago
    If the dev account role has different permissions, it doesn't matter. Of course (s)he tested it first in a dev account. The point is the context around roles matters much more than the code that runs inside it, a critical flaw of AWS. Fairly, this problem is definitely not just limited to AWS but I find their implementation particularly poor.
    - scarface74 8y ago
      That’s still the issue. You should have a custom role for each set of lambdas that make up a service. Your role and your lambdas should be in the same CF template that can be deployed together. Security best practices is for the role to have the least amount of privileges the lambda needs. Not just one generic “lambda role”. Whoever is responsible for production deployment could audit the role’s permissions and the definitions would be in source control.

kodablah 8y ago

> I'm referring, of course, to AWS IAM, which absolutely is the worst form of cloud lock-in that currently exists, at least relative to the zero people who seem to be talking about it. I assume people don't talk about it because it's not trivially solvable. While we can have many abstractions out there, abstracting IAM across providers is very difficult because while you could get roles and users/members/policies abstracted, you couldn't get resources and permissions abstracted. They are too bespoke. The best you could hope for is a common API, but you'll still be provider-specific in everything you pass.

013a 8y ago

The only people worried about vendor lock-in are people who have practically nothing of value to be locked-in. "Lambda is horrible for lock-in, once you're hitting billions of invocations a month you're going to wish you could cost optimize by shopping around with other providers! I've got my personal website hosted there, it gets a dozen hits a month, sure glad I'm inside the free tier." I've heard CTOs/CIOs of large companies express concern over it, but at the end of the day they'll sign that $100M contract with Amazon or Azure. It doesn't actually matter. Its a concern, but its not going to stop the sale or development. Today, if you're not locked in, you're leaving business value on the table. I hope that changes in the future, and maybe Kube will be the standard platform we've needed to push it forward (for example, I wish I could tell kube "give me a queue with FIFO and exactly once delivery", it knows what cloud provider you're on, if you're on AWS it provisions an SQS queue, if you're on GCloud it errors because they don't have one of those yet, and in either case I communicate with it from the app using a standard Kube API, not the aws-sdk). But for now, lean in. Don't fight the lock-in; every minute you spend fighting it is a minute that you should be spending fighting your competition.

cosmodisk 8y ago
Vendor lock-in isn't something anyone, especially at C-level should be ignoring. Yes, there are things to be gained and money to be made,but one should always have some sort of alternative,just in case. I happen to be in a business,which 100% relies on one vendor,which keeps hiking up prices every year way above inflation.
- HillRat 8y ago
  The flip side of vendor lock-in — at the megacorp level, anyway — is the “one throat to choke” principle; sure, it might be hard to migrate off AWS/Azure/IBM, but (a) your technology investments have a timespan measured in decade-long iterations; and (b) what you really want is to ensure reliable operations for your enterprise. Sure, you may be stuck with cloud vendor x for the next ten years, but at least you know who to scream at if the infra goes south — preferably someone who can mobilize enough engineers to get you back up and running right now. Having said that, if you’re a small company where cloud budgets are a significant portion of your overall spend, or a tech company that has a defensive need to be able to migrate providers, YM will definitely V.

bradknowles 8y ago

I'm not worried about AWS IAM. I'd love for my problem to be that small. I'd like to get off Azure SSO.