> that's because you have a service principle in your IAM trust relationship that allowed us access
That’s why it’s so complicated!!!
I don’t understand how I should evaluate trust for your internal EBS org versus your internal ALB org.
I kinda just expect it to be all “AWS” trust.
And it’s all garbage anyway. There’s no way I can prevent the hypothetically untrustworthy EBS team from surreptitiously adding charges to my account if they want to. Right? This would maybe make some sense if I could top level turn off/on services, but that isn’t how it works.
—
I have no doubt this makes some sense from someone inside the machine, but from the outside it’s not helpful nor useful.
1. It's about trust and auditability, while you may not want or need it, there are a lot of customer that are either interested or legally obligated to know who have accessed certain data.
2. It's about dogfooding - how would you trust an identity and access system when the company does not even use it internally?
3. In general, there are quick buttons and template to do it if you don't want to worry about it, in the LLM age, this gets easier. Personally I prefer this because I intensely dislike "magic". This allow you to control, to the maximum degree possible, what is actually going on, despite not owning any of the physical aspect of the data center.
1. It's about imposing worst-case complexity on the 99% of people who will never benefit.
2. Some of that complexity only arises because of the dogfooding
3. No it doesn't get easier, because you still need to understand what those things actually do to know if they're right for your use case, and besides if you're driving everything from terraform then having a "quick button" is precisely useless.
We had an AWS rep try to sell us on an AI tool to help with predicting the IAM permissions that our infrastructure code needs. My response was, essentially, "why have you built a deterministic system so complicated that it needs an AI to configure correctly?" I have not had an answer.
This would be very unwise from security standpoint. Internal access to customer stuff is granular and made hard for internal staff to gain, to minimize chances of screw up intentional or not.
Sure, but presumably you can engage with the spirit of the analogy?
Let's be pedantic, and say someone gave apples away in exchange for donations, and when everyone only got a few apples and donated, things are fine, but then someone decided they can just take all the apples and sell them elsewhere.
Is it the fault of the first guy for not offering free apples any more, or is the second guy why we can't have nice things?
> but presumably you can engage with the spirit of the analogy?
What you’re calling “the spirit of” the analogy, others are seeing as “the bias embedded in” the analogy and you seem annoyed that people aren’t accepting your proposed analogy as a valid analog to the topic under discussion.
You think they’re changing the subject; others, including me, experience you as the one doing that.
That’s why it’s so complicated!!!
I don’t understand how I should evaluate trust for your internal EBS org versus your internal ALB org.
I kinda just expect it to be all “AWS” trust.
And it’s all garbage anyway. There’s no way I can prevent the hypothetically untrustworthy EBS team from surreptitiously adding charges to my account if they want to. Right? This would maybe make some sense if I could top level turn off/on services, but that isn’t how it works.
—
I have no doubt this makes some sense from someone inside the machine, but from the outside it’s not helpful nor useful.
reply