kubenav/kubenav

AWS IAM Identity Center single user with multiple accounts/clusters

macmiranda opened this issue ยท 12 comments

Hi @ricoberger,

Just wondering what the effort would be to allow AWS IAM Identity Center (formerly called AWS SSO) users to provide only the Start URL and based on the authentication outcome, fetch the available organization account id's and roles that can be assumed by the authenticated user, and for each of those list all the clusters that could be "imported" into the config.

I can provide more details about the needed API calls and I have a setup where I can test this.

Hi @macmiranda, I'm not that familiar with AWS SSO, but if I get you correct it is possible to get the Account IDs and Roles of an user by an additional API call, when only the start URL is provided, right?

If this is the case it shouldn't be that much effort, when we could create multiple AWS SSO providers (one for each Account ID / Role), so we can reuse the authentication logic.

If you can share the API calls, I can have a detailed look at this.

PS: Because you said AWS SSO was renamed to AWS IAM Identity Center, would it make sense to adjust this also in the app or is the former one still better known?

So, if I'm not mistaken, kubenav already takes care of the OIDC authentication here. (for that you only need the ssoRegion and the startUrl.

You can then call CreateToken to get an access token.

With that access token you can call ListAccounts which will return a list of accounts the user has access to.

Next you can ListAccountRoles for each account of the previous step to get all the roles the user can assume.

Then you can move on to GetRoleCredentials for each role like you're already doing here.

Hope that helps.

P.S.: I think most people still call it AWS SSO although AWS IAM Identity Center has been around for at least half a year. Despite the name change all the APIs retained the old namespaces for backward compatibility (and SSO is much shorter to type ;-).

It may be a good idea to let the user select which roles to use though, since it's common to have multiple roles per account, such as one ReadOnly with broad access and one limited ReadWrite role, for instance. Of course, that depends a lot on how the organization is structured.

Hi @macmiranda, I implemented this in #505, the only thing I do not like is how the region parameter is handled here:

// TODO: Maybe we have to find a better solution to specify the
// region parameter instead of using the sso region.
region: widget.ssoRegion,

The region is used to get the list of clusters and to get the access token. What do you think can this be the same as the SSO region or should this be configureable?

Hi @ricoberger, the way it is now it certainly covers a fairly common use-case where small and medium businesses use the same region for both SSO and their workloads (even though their operations may span multiple different countries).

But to cover every possible use-case, the cluster region should be configurable though that could be a part of a different story. In reality it can get very complex, if you consider all the possibilities: accounts ร— roles ร— regions ร— clusters

A list of regions where EKS is available can be found in this JSON document (though I'm not sure how available or durable that is) :

curl -s https://api.regional-table.region-services.aws.a2z.com/index.json | jq -r '.prices[].attributes|select(."aws:serviceName" == "Amazon Elastic Kubernetes Service (EKS)") | ."aws:region"'

Thanks for all your help @macmiranda ๐Ÿ™‚. I merged the PR and will let you know when a new beta version is available. If you would change/improve sth. in the implemented flow please let me know.

Hi @macmiranda, the new beta version should now be available via Apple Testflight and Google Play. Please let me know if this is an acceptable solution for you.

Hi @ricoberger I tested it briefly yesterday. It mostly works as expected ๐ŸŽ‰ . Thanks.

I do have 2 small related issues that would like to report. Should I open new bug?

Hi @macmiranda if it's related to the changes regarding the AWS SSO provider we can also reopen this issue.

Yes, it is. I can't reopen it myself though. Anyway will post my findings below:

When the list of clusters is too long, it crosses the boundary of the pop-up box and it seems to be non-scrollable, which means, for some people, some clusters may not be displayed at all:

I could successfully add all the clusters shown above except for the last one, which is also the one that didn't fit in the pop-up (coincidence?):

Lastly, it's possible to add the same cluster multiple times (I did it by mistake first and then again to confirm - see last 3 ones):

Hi @macmiranda, it should now be possible to select all added providers. This should also fix the second error, sorry that it took that long.

Clusters can still be added multiple times, because we do not save the cluster id. Also the name of each cluster should be editable so we can not deduplicate on this criteria.

Thanks, @ricoberger.

Verified it's working.