111–120 of 124 posts
Earlier quoted context omitted.
It seems to me this cannot possibly be a hard limit. If it’s a hard limit it’s only because AWS wants to milk you dry.
I suspect it’s a hard limit to prevent disgruntled (former) admin blast radius.
Earlier quoted context omitted.
No, Batch's interaction with IAM roles and permission is super weird and not at all documented. It is easy to screw it up.
Aws batch is a terrible product
Namespaces could solve all of that. Why AWS haven't added that yet? I understand that they rarely change the service, but c'mon, we're in 2022.
so i have this weird monthly charge I cannot for the love of god find out what is causing it. I cancelled my credit card and now my credit score has taken a hit. All because some unknown AWS service that is in some zone that I cannot find at all and neither can AWS support.
99% of our AWS resources are terraformed, but developers constantly push back / want to use the console to create stuff to test or play around with. So we setup a separate "hack" AWS account and give them admin access in there, and have an automated job using AWS Nuke to delete everything in there once a quarter.
We give each one of our developers their very own aws account managed through AWS organizations service. They are full administrators and responsible for resources and cost. So far we haven’t had any issues or bad surprises, although we have setup some aws billing alerts just in case. Feel free to make them responsible for cost and resources and you’ll be surprised how well they can manage their own account.
Giving people responsibility and autonomy also comes with some responsibilities by the providers in a shared responsibility model is all I’m saying and every policy works out fine until it doesn’t.
Earlier quoted context omitted.
> 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?
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…
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.
Earlier quoted context omitted.
Oh that would be glorious. Not sure how it'd be possible though.
I've hitherto assumed it didn't because it wasn't, short of calling every single `*:Describe*` API anyway. But the existence of aws-nuke makes me think (I haven't looked into what it's doing yet) there must be a better way of discovering used services/resources. Through billing perhaps?
Link to the repo in my HN profile.
Earlier quoted context omitted.
That's one of my big complaints with terraform, and it's state-based system. It doesn't inform you if there are resources you don't know about.
It is a feature and a good one (with a caveat though). terraform is best used on a per solution basis: one solution, one dedicated terraform project that will manage its state and its own state only. Multiple projects and people work carry out work in the same cloud account in parallel, and their terraform projects are not meant to interfere with each other. It works best for solutions that make use of fully managed…
> Then there are also platform or connectivity level cloud resources (e.g. Transit Gateway and subnets that are mapped into the internal organisational network address space in AWS) that a random terraform project ought not to manage.
Not a 'random' one sure, personally I'd still want it somewhere. I suppose the hypothetical command might want an optional whitelist of non-tf-managed stuff to ignore though. (But then, you could whitelist it just by writing the terraform and importing it?)
> Lastly, if there is an actual need, a resource that terraform does not know about can be manually imported
The hard/annoying part that I'd like this command for is discovering these resources. i.e. it's not just that terraform does not know about them, it's that I probably don't. Or at least I don't realise they're not captured in terraform.
A very easy one to overlook is security group rules: unless you define them inline in terraform (i.e. ingress/egress blocks on a security group resource) then adding additional rules outside of terraform does not cause a diff. So you might be testing them out by manually poking around, and then you forget to terraform them/remove them, and they're left there forever with terraform blissfully unaware, and if you ever happen to notice it might not be obvious whether they're needed or not.
Essentially, it'd be useful for enforcing that terraform's used for everything; maintaining 'IaaC' hygiene.
Project sponsored by Azure ?
Feel free to ask any questions.