Containers-roadmap: [EKS] [request]: Hide extension-apiserver-authentication from users

[gappan]

Tell us about your request
To hide the config map resource extension-apiserver-authentication from the users.

Which service(s) is this request for?
EKS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?

We bumped into an issue with our EKS cluster trying to manage configmaps created in the cluster and deleted the cm resource extension-apiserver-authentication . This config map is created by the api server Ref .

I had opened a case with the EKS team and the issue has been pending for over 4 days now and the issue might be resolved with restarting the api-server of the cluster.

However since we dont have access to do that, it would be very helpful to hide the configmap from the users.

[rverma-nikiai]

I have accidentally deleted this cm and want to know what should I do?

[srinivasreddych]

I have accidentally deleted this cm and want to know what should I do?

Was the CM deleted as a file or using kubectl commands? If the CM was deleted using kubectl commands (kubectl delete cm <>), then you cannot recover it as of me. Fix would be is to find who created EKS Cluster (User/Role) and assume those credentials to talk to API Server and create the deleted CM listing the required contents (like mapUsers, mapRoles and other objects).

[rverma-nikiai]

It was deleted using kubectl commands. I did create the cluster so I already have required I am role. I found the cm in other clusters has 2 certificates but can't figure out how to create them. Those should be the apiservers' auto-generated certs. It doesn't have mapUsers etc. fields. Those usually are part of aws-auth configmap.

[gappan]

@rverma-nikiai , you will need to raise a support request in AWS and ask them to restart the apiserver. The config map is created by the api server during the boot time.

[tabern]

@gappan were you able to get this resolved?

[gappan]

@tabern , yes we were able to get it resolved. but the sad part was it took 6 days for my ticket to get resolved. The fix as mentioned was just a restart of the api-server , but since the support team did not have access to do it, they had to involve the eks team for that. It would be good if there is a possibility to hide the resource from the users .

[whereisaaron]

@gappan @tabern perhaps better than trying to protect this ConfigMap or rely on the support team, could EKS users be able to restart their own API server (and/or control plane)?

If user-initiated, AWS could automatically suppress internal monitoring warning. The API could be rate-limited (like once/hour even), and the console button could give the appropriate are-you-sure warnings about the impact.

Less work for the support team and much faster turn around for users.