4 ms·

Sure, in an abstract sense maybe, but in a cross-service context it’s got nothing to do with their “cloud scale databases”. In fact, being able to delete a rol

by orf 4y ago

Sure, in an abstract sense maybe, but in a cross-service context it’s got nothing to do with their “cloud scale databases”. In fact, being able to delete a role without removing any associated resources is a feature, not a bug. And how would you even ensure referential integrity in this case - you would achieve the same effect by modifying the assume role policy but keeping the role around. You could craft a policy that only allows Batch to assume the role on a Tuesday for example.

XorNot 4y ago
Wedging a cloud resource so you can't delete it is always a bug.
- orf 4y ago
  Yes, in the service that provides the AWS resource. Because it didn’t handle the fact that the role it’s using might be deleted or otherwise rendered un-assumable for a variety of different reasons at any point in time. Which is a feature. Not a bug.
  - TedDoesntTalk 4y ago
    I’m curious how you see this as a feature when it can get you into a very expensive and unresolvable situation; a AWS resource can’t be deleted and is running up costs. You’re at the mercy of AWS support.
    - bergenty 4y ago
      It’s not a feature but how do you solve this? You can’t block role deletion because it has a resource associated with it, that would be a functional nightmare.
      - speedgoose 4y ago
        A very classic way of doing would be to prevent deleting a role that are resource tightly associated to it by default. If someone really wants to delete the role anyway, you can provide a feature to do that and delete associated ressources in cascade.
        TedDoesntTalk 4y ago
        "Cascading deletes"
        bergenty 4y ago
        It’s like you didn’t even read what I wrote. That way sucks, especially if you have hundreds of allocated resources. Cascade delete is not a realistic option here either. Imagine someone leaves the company without notice. All their resources need to be deleted?
        speedgoose 4y ago
        When someone leaves a company you look at their resources and assigned new people to them or delete them. But you should prefer teams and projects over individuals anyway.
    - speedgoose 4y ago
      It can also be a security vulnerability if the resource that cannot be deleted is compromised and can access or contain critical data for example.
    - orf 4y ago
      Can it? The only case I know of involving roles specially is Batch, and the resources it’s trying (and failing) to clean up are ones with absolutely no cost. It’s a feature because there are plenty of cases, such as a role being compromised, where you don’t want to cascade-delete every single associated resource without any need. If you want this then you can opt into it by using cloudformation.
- bergenty 4y ago
  Maybe. But the GP above has a point. What does a role have to do with this particular resource. You can’t block role deletion because they are associated with resource, that would be a functional nightmare. You also can’t just cascade delete all resources associated to a role. The only real thing that can be done is assign the resource to some super user with all the rights so they can delete it instead.
  - XorNot 4y ago
    > You can’t block role deletion because they are associated with resource, that would be a functional nightmare. Asserting this doesn't actually make your argument for you. Why would this be a problem?
    - orf 4y ago
      It doesn’t make any sense. Forgive me for saying this, but if you don’t really know how all this works then it’s a convenient throwaway thing to suggest. So I think it’s up to you to explain how this would work when there is no difference between a role being deleted and a role being inaccessible. What exactly would you do if I block instance with the ID “xyz” from assuming the role I have assigned it? How would you detect that I’ve done this in every single case?
      - XorNot 4y ago
        That's an inline policy which is attached to the role. And notably AWS roles require all policies to be removed before they're deleted (which I know because I spent a bunch of time recently fixing ordering issues with CloudFormation deletes). Again you keep just asserting this isn't possible: why? AWS are aware you need the role to exist to delete the instance (as noted up in the OP), why apparently is it completely inconceivable that the IAM system would check for this condition before executing an action - which again - irreversibly wedges a delete operation for a resource? Unless you have some deep knowledge of how AWS IAM is implemented which makes this literally impossible, then you're asserting fluff.

by orf 4y ago

XorNot 4y ago

Wedging a cloud resource so you can't delete it is always a bug.

orf 4y ago
Yes, in the service that provides the AWS resource. Because it didn’t handle the fact that the role it’s using might be deleted or otherwise rendered un-assumable for a variety of different reasons at any point in time. Which is a feature. Not a bug.
- TedDoesntTalk 4y ago
  I’m curious how you see this as a feature when it can get you into a very expensive and unresolvable situation; a AWS resource can’t be deleted and is running up costs. You’re at the mercy of AWS support.
  - bergenty 4y ago
    It’s not a feature but how do you solve this? You can’t block role deletion because it has a resource associated with it, that would be a functional nightmare.
    - speedgoose 4y ago
      A very classic way of doing would be to prevent deleting a role that are resource tightly associated to it by default. If someone really wants to delete the role anyway, you can provide a feature to do that and delete associated ressources in cascade.
      - TedDoesntTalk 4y ago
        "Cascading deletes"
      - bergenty 4y ago
        It’s like you didn’t even read what I wrote. That way sucks, especially if you have hundreds of allocated resources. Cascade delete is not a realistic option here either. Imagine someone leaves the company without notice. All their resources need to be deleted?
        speedgoose 4y ago
        When someone leaves a company you look at their resources and assigned new people to them or delete them. But you should prefer teams and projects over individuals anyway.
  - speedgoose 4y ago
    It can also be a security vulnerability if the resource that cannot be deleted is compromised and can access or contain critical data for example.
  - orf 4y ago
    Can it? The only case I know of involving roles specially is Batch, and the resources it’s trying (and failing) to clean up are ones with absolutely no cost. It’s a feature because there are plenty of cases, such as a role being compromised, where you don’t want to cascade-delete every single associated resource without any need. If you want this then you can opt into it by using cloudformation.
bergenty 4y ago
Maybe. But the GP above has a point. What does a role have to do with this particular resource. You can’t block role deletion because they are associated with resource, that would be a functional nightmare. You also can’t just cascade delete all resources associated to a role. The only real thing that can be done is assign the resource to some super user with all the rights so they can delete it instead.
- XorNot 4y ago
  > You can’t block role deletion because they are associated with resource, that would be a functional nightmare. Asserting this doesn't actually make your argument for you. Why would this be a problem?
  - orf 4y ago
    It doesn’t make any sense. Forgive me for saying this, but if you don’t really know how all this works then it’s a convenient throwaway thing to suggest. So I think it’s up to you to explain how this would work when there is no difference between a role being deleted and a role being inaccessible. What exactly would you do if I block instance with the ID “xyz” from assuming the role I have assigned it? How would you detect that I’ve done this in every single case?
    - XorNot 4y ago
      That's an inline policy which is attached to the role. And notably AWS roles require all policies to be removed before they're deleted (which I know because I spent a bunch of time recently fixing ordering issues with CloudFormation deletes). Again you keep just asserting this isn't possible: why? AWS are aware you need the role to exist to delete the instance (as noted up in the OP), why apparently is it completely inconceivable that the IAM system would check for this condition before executing an action - which again - irreversibly wedges a delete operation for a resource? Unless you have some deep knowledge of how AWS IAM is implemented which makes this literally impossible, then you're asserting fluff.