3 ms·

> 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

> 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.

jimbobimbo 5mo ago
>I kinda just expect it to be all “AWS” trust. 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.
- NewJazz 5mo ago
  I agree. Adding a service principal always raises an eyebrow for me, just a blanket "hey we're aws trust me bro" is a little bonkers.
  - paulddraper 5mo ago
    How does this work in Azure and Google Cloud?
Aperocky 5mo 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.
- regularfry 5mo ago
  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.
- paulddraper 5mo ago
  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.
  - Aperocky 5mo ago
    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.

jimbobimbo 5mo ago

>I kinda just expect it to be all “AWS” trust. 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.

NewJazz 5mo ago
I agree. Adding a service principal always raises an eyebrow for me, just a blanket "hey we're aws trust me bro" is a little bonkers.
- paulddraper 5mo ago
  How does this work in Azure and Google Cloud?

Aperocky 5mo 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.

regularfry 5mo ago
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.
paulddraper 5mo ago
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.
- Aperocky 5mo ago
  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.