-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature] Option to restore IAM serviceaccount #5368
Comments
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: #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. 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 |
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. |
/remove-label stale |
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 |
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. :) |
Oh I see... |
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. |
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.The text was updated successfully, but these errors were encountered: