AWS Identity Center Setup

[upodroid]

Top-level problem statement: We need an Identity Provider(IdP) to use with AWS SSO to access all the various AWS accounts of the project.

In a typical company/enterprise, you often use either Google, Okta or Azure AD as your main IdP. When someone joins the company, HR/IT add this new employee to the IdP and they get access to various applications. Then employees are added to various groups that grant access to different systems. Also, when they leave the company, they get offboarded and their access gets revoked.

The Kubernetes project's primary IdP is Github as it has all our contributors(similar to employees) and their group memberships. GitHub isn't really designed as an IdP and apps that support GitHub as an IdP have custom code to process OIDC claims and group mappings.

For AWS Identity Center(previously known as AWS SSO), we need to use an IdP that supports SAML and SCIM to have a fully automated user access/creation for AWS. GitHub doesn't support these protocols/standards so we need a middleware to bridge the gap. We can explore Keycloak or Azure AD to plug this gap.

My personal preference would be to acquire an Azure AD tenant with many P1 licenses and write a small program(terraform works just fine) that creates AAD users and groups based on information in GitHub and we would then configure AWS SSO to use Azure AD as the IdP and create the permissions accordingly.

Keycloak can work but I need to test this. It doesn't support SCIM out of the box but someone wrote an external plugin that can do it.

Reading Material

• https://docs.aws.amazon.com/singlesignon/latest/userguide/provision-automatically.html#auto-provisioning-considerations This is about SCIM and autoprovisioning

Out of scope issues:

• Most guides online for enabling SSO for AWS often describe SAML for a SINGLE account. This is not scalable and will not be in scope.
• Federating GSuite is out of scope. Most of do not have @kubernetes.io Google accounts and the groups won't be useful for SAML.

I would like to hear more about any other IdPs that can be integrated directly with AWS Identity Center. This is the list. https://docs.aws.amazon.com/singlesignon/latest/userguide/supported-idps.html

/cc @jeefy @ameukam

Next steps:

• I'm going to put together a Keycloak demo.
• The Azure AD approach is something I already do for prod at work. More than happy to talk about it.

/priority important-soon
/area infra/aws

[ameukam]

We should evaluate also https://www.auth0.com as an authentication hub. They have a non-profit pricing: https://auth0.com/nonprofits

[ameukam]

cc @mrbobbytables @cblecker @nikhita @palnabarun
(as Github admins)

[sftim]

If we have to build our own identity management system, does it have to use SAML / SCIM / OIDC?

• we could make something you SSH into as your GitHub username, provide MFA (keyboard-interactive in SSH jargon), and get back an AWS STS session.
  • and/or a short-lived federated login URL for the AWS web console (but that's better done by users calling AWS APIs themselves)
• we could create something that builds on AWS IAM for users, and make our own thing that syncs those users based on GitHub group membership
  • this approach needs a way to set initial passwords for users, also a recovery / reset process
  • • a cron job sort of thing could deprovision users who are no longer in our org
• if a GitHub user is in our org and has a signing key known to GitHub, we could accept a commit from them that does some initial provisioning (might contain an enciphered message, might not need to)

these are just some ideas. Overall, I have a feeling that we can make something that is a bit more manual and not suitable for less technical users, but also means we have zero costs at idle and ideally not much to maintain.

[upodroid]

If we have to build our own identity management system, does it have to use SAML / SCIM / OIDC?

Yes. This is a requirement from AWS. AWS Identity Manager is the best way to access more than 1 AWS account and that requires SAML & SCIM. OIDC isn't used by AWS so you need something to bridge the gap.

I tried to get Keycloak to work but I can't seem to get the SAML config to work. It doesn't support SCIM anyway but there are options out there for configuring the users & groups via SCIM(I found a terraform provider).

More details at tonights meeting.

[ameukam]

Ref: #4654

[upodroid]

I have some updates.

I'm going to miss or be very late for today's AWS Infra meeting.

Experiments:

• Keycloak SAML with AWS Identity Center. Didn't work
• Auth0 SAML with AWS Identity Center. Didn't work either, using Google instead of GitHub social logins had fewer problems but still didn't work
• Azure AD SAML with AWS Identity Center. Works very nice.
• Azure AD SCIM User Provisioning works very nicely too.

I'm proposing we go forward with configuring Azure AD, I have a potential approach detailed in the linked PR. We will need Azure AD P1 licenses for to make it work without extra work.

[ameukam]

Keycloak SAML with AWS Identity Center. Didn't work
Auth0 SAML with AWS Identity Center. Didn't work either, using Google instead of GitHub social logins had fewer problems but still didn't work

probably describe technical blockers for this may help gain some assistance on how we can solve this.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ameukam]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[bryantbiggs]

why do we need to layer on AzureAD here - why not just add folks directly into AWS Identity Center?

[jeefy]

I believe the goal here was to unify the way we grant access to the community infrastructure, and AzureAD was one such option.

I also think that we've moved past this, so this issue might be invalid. @upodroid @ameukam ?

[upodroid]

I need to update the issue to say we use Okta instead of Azure AD?

why do we need to layer on AzureAD here - why not just add folks directly into AWS Identity Center?

Because we will be accessing different services and SAML/SCIM helps with onboarding/offboarding.