eksctl-io
[Feature] Option to restore IAM serviceaccount
What feature/behavior/change do you want?
An option to restore damaged/removed IAM serviceaccounts without having to delete the whole stack.
Reading several issues here, create failing silently if anything already exists seems to be conscious design decision for eksctl, so it won't "repair" partially missing IRSA on subsequent calls.
Why do you want this feature?
But once in a while, another tool (flux,helm,...), or a user with fast fingers might overwrite or delete an IAM serviceaccount, thus removing the IAM annotation.
Apparently, create iamserviceaccount -f config.yaml just checks if the CloudFormation stack is there, and won't do anything then. The option --override-existing-serviceaccounts also has no effect.
Please add a restore iamserviceaccount -f config.yaml or similar action, which just creates/restores all IRSA specified in the configuration file.
Hello # :wave: Thank you for opening an issue in eksctl project. The team will review the issue and aim to respond within 1-3 business days. Meanwhile, please read about the Contribution and Code of Conduct guidelines here. You can find out more information about eksctl on our website
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Hi.
There have now been a number of issues regarding this, please take a look and see if any of them answer your question. :)
Start from here: https://github.com/weaveworks/eksctl/issues/4981 :)
Hi @Skarlso!
Indeed #4981 was the first issue I found, but it apparently deals more with damaged CloudFormation stacks, and the conclusion was to keep the imperative nature there. On my experience, CloudFormation is indeed notoroiously bad to "repair", one can easily get into a dead-end state where only deleting and recreating the stack is viable, so a more declarative approach might indeed be hard with CF.
In contrast, my issue is more about the case where the CloudFormation stack is healthy, but the Kubernetes ServiceAccount ressource somehow is missing completely, or is missing the annotation or secret. So that recover function would rely on the CF stack being already there, and from there doing the same things as create iamserviceaccount does.
The attached PR would have done something like that. Detect if there is already something there or not. But it was abandoned and we don't have the bandwidth to finish it. :)
Ah, I see. In that case, indeed better focus on #2774 ff., I am also in favour of a declarative approach, and doing it right from the ground up is surely better that a lot of "repair" features. If needed, I might get away with a script deleting and recreating all IRSA if needed...
Not to be pessimistic, but I don't believe 2774 will get anywhere any time soon. Maybe in the future (distant future)... but we can't prioritise it with so many things being more in focus and the massive change it would have to bring with it. We just don't have enough staff to do this. :)
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
/remove-label stale
I don't know if you noticed, but this doesn't work. :D It's not a k8s bot. :)
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This issue was closed because it has been stalled for 5 days with no activity.