IRSA with OIDC provider fully-private: impossible?

0

Hi, I have a self-managed, fully private Kubernetes cluster already configured with an OIDC provider, having obviously an internal URL: https://kubernetes.default.svc.cluster.local/ I was thinking to set up IRSA (IAM Roles for Service Accounts) to allow ServiceAccount <--> IAM Role mapping. It's a quite difficult subject but as far as I understand I need to create on OIDC provider in the account but this accept only a public URL. Is there some workaround for this?

2 Answers
0

Hello,

From the description of the issue, I can see that you wish to set up IRSA (IAM Roles for Service Accounts) to allow ServiceAccount - IAM Role mapping such that you can apply fine-grained access controls for your self-managed Kubernetes cluster. Since your self-managed Kubernetes cluster is fully private, so you wish to know how to configure an OIDC provider in the account for IRSA as it accepts only a public URL.

I would like to mention that IAM roles for service accounts provide the ability to manage credentials for your applications, similar to the way that Amazon EC2 instance profiles provide credentials to Amazon EC2 instances. Instead of creating and distributing your AWS credentials to the containers or using the Amazon EC2 instance's role, you associate an IAM role with a Kubernetes service account and configure your pods to use the service account. To use AWS Identity and Access Management (IAM) roles for service accounts, an IAM OIDC provider must exist for your cluster that would be added as an Identity Provider at the IAM side[1].

Now, for self-managed EKS clusters, as of 1.16 Kubernetes does not include an OIDC discovery endpoint itself, so you will need to put your public signing key somewhere that AWS STS can discover it i.e. need to provide a public URL for the issuer. In order to achieve the same, as a workaround, you can put your signing keys as public objects in an S3 bucket. Firstly, as part of the OIDC spec, host an OIDC discovery and a keys JSON document. After you have the "keys.json" and "discovery.json" files, you'll need to place them in your bucket. It is critical these objects are public so, STS can access them. Please refer the Github link[2] for step by step guidance on the same. Once you have done this, you can follow the process in the EKS documentation[3] and substitute the cluster issuer with the S3 bucket issuer URL containing the keys json document("https://$ISSUER_HOSTPATH").

[1]. https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html

[2]. https://github.com/aws/amazon-eks-pod-identity-webhook/blob/master/SELF_HOSTED_SETUP.md#public-issuer

[3]. https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html

AWS
SUPPORT ENGINEER
answered a year ago
0

Hi Nikita, thanks for your response. I know that "as of 1.16 Kubernetes does not include an OIDC discovery endpoint itself" but my Kubernetes distro includes OIDC (and other platform services, like Dex for LDAP auth). I was wondering if I can use existing endpoint but I think no because it is fully private. Creating an S3 bucket as described is not easy because the issuer is already configured on the API Server with the internal OIDC endpoint.

mimmus
answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions