Hacker News new | ask | show | jobs
by Aperocky 42 days ago
3 things to untangle here.

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.

2 comments

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.

That's all fine and good, but I still don't know how much trust the EBS team versus the ALB team.

And I don't think you do either.

You don't need to trust EBS or ALB team. You just have a contract that says whether ELB/ALB get access to your data/resources or not.

Also the access are not "team", it's software. The control plane would have access to resource if you granted the service principle and then it would go ahead to do what was already written as service logic for those resource. The engineers do not gain access to your resource now - all prod service principles are access gated and we can only see certain non-PII logs as required by operational events. We don't run the service manually.