 The title of the talk is Controlling EKS Access with AWS IAM. So I'll give you a little background. So this was the scenario. We were running a corp-based cluster for over a year. And the way we gave developers access to the Kubernetes cluster was via Slackbot. And this was a time-based access. So it came with a set of own problems. Basically, there was no single source of fruit for users. So if at any point of time you want to ask who all have access to your cluster, no one could answer that. If someone leaves the organization, there was a procedure to manually delete the access. And this is a small pet peeve, but still a problem that we used to generate access for two months. And if that access, like when that expires, someone had to manually generate it. Not manually. Basically, you had to go to the Slackbot, but it was still a problem. And if you didn't have enough problems, we decided to let's move to EKS. So we got a new set of problems, or maybe a solution. So the thing about EKS is, since it is AWS-based, the access there is managed by AWS IAM Authenticator. It's like a small tool that just works on your AWS credentials. And so the way it works for is there is a config map called AWS Auth in the Qt system. And you need to add your user's IAM roles in that. So what we thought was doing was let's write a small strip, small tool, which basically keeps your IAM in the AWS always in sync with the Qt system config map. So we created, we forked up the tool and then added some of our own features. So what it basically does is it's a simple like Kubernetes deployment. And what it does is you can sync AWS IAM groups with Kubernetes roles. So we currently have a developer role, admin role, or read-only role. And with that, we have given the same access and we map it to the AWS IAM groups, which is like developer. And so we give our QA guys read-only access. We give developers to destroy access as well. And like us DevOps guys, we have direct system, system master access. And we recently migrated to a multi-account setup like different fraud and dev accounts. So it has support where you can choose which account, like it's a good practice to keep all your IAM users in one account and in the other account, you should use the switch role thing. So you can basically give the account ID on the, whose users you want to sync with and the access levels and all you talked about. And that's what it does, you can just deploy it and it does, it works on a polling-based mechanism. That's it actually. I'll give you a small demo on the GitHub. This is just a tool, like if you want, you can use my integral EKS user map first. Like if you guys can come up with a better name, please open an issue. And so to deploy it is basically simple. It's just a simple, cute detail file that you need to deploy. Add the role add in here. And the way it works is you give a, if you zoom in, you just give a mapping of, you can see it's DevOps map to system access devs. The IAM group is mapped to the devs group in Kubernetes. And that's it. So if any of you are using EKS and want to do something similar, you can use this. Any questions? So Cognito is basically a identity provider. And it's a full-fledged, like we use it for our identity provider, we use a different, like we are on a very old LDAP setup that is in the PHP LDAP. So we didn't want to do that because doing that would mean, this is basically containerized to the, wrong word, but yet to the developers only, whereas the LDAP is for the whole organization. So doing that was a bit of a big step. So we are currently looking for identity provider. So we may go with a jump flower or maybe Cognito as well, but we didn't want to directly jump into Cognito. Those were basically an extra set of features that we didn't explore. And see that from here, but I just wanted to ask you, is it a pod-based service that keeps on running? Or is it a Chrome? It's a simple pod that gets launched in the Qt system. And it's a normal deployment and you can set the polling interval. And how do you sort of authenticate this particular thing? Yeah, so you can use, like the way you do your normal AWS authentication using Qt2IM or QIM, you can give it a normal, this is the role that should have an access to get all the IIM users. Okay, so basically you say, give that particular instance of the role. It's like treat it as a normal deployment and give it access to fetch all the IIM groups.