Shulou(Shulou.com)06/03 Report--

Today, what the editor shares with you is the working mechanism of EKS IRSA. I believe most people don't know much about it. In order to make you understand better, the editor summed up the following content for you. Without saying much, let's move on.

First, the generation of aws-iam-token 1.1 token generation

The AWS we use here fully manages the K8s cluster EKS and creates the iamserviceaccount with the following command.

Eksctl create iamserviceaccount-name alice-namespace default\-cluster eks-attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess\-approve-override-existing-serviceaccounts

An architectural diagram of IRSA is roughly as follows:

After a pod is created by API Server, according to Self-hosted Kubernetes setup, the relevant startup parameters of API Server are obtained through CloudWatch:

-- service-account-key-file= "[/ etc/kubernetes/pki/sa.pub]"-- service-account-signing-key-file= "--service-account-issuer=" https://oidc.eks.us-east-1.amazonaws.com/id/900B62D5EA15DC82EC523AD824232853"

Service-account-key-file is used for verify token

-- service-account-issuer. Yes, iss claim in JWT token.

The service account token is signed by the controller-manager controller, and the relevant private key is in its startup parameters, so let's check its startup parameters as follows:

-- service-account-private-key-file= "/ etc/kubernetes/pki/sa.key"

Sa.key and sa.pub here are a pair of secret key pairs.

After the signing of token, eks-pod-identity-webhook is triggered. Here pod-identity-webhook is the mutating admission webhook of K8s. Eks-pod-identity-webhook assists in writing the relevant Token information into etcd, then mounts the token into Pod in the form of Projected Volume, and injects the role-arn in iam service account and the newly generated token into the environment variable AWS_WEB_IDENTITY_TOKEN_FILE of Pod.

I think you can view the MutatingWebhookConfiguration in the cluster through the command.

Wangzan:~ $kubectl get MutatingWebhookConfiguration pod-identity-webhook-o yamlapiVersion: admissionregistration.k8s.io/v1beta1kind: MutatingWebhookConfigurationmetadata: annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion": "admissionregistration.k8s.io/v1beta1", "kind": "MutatingWebhookConfiguration", "metadata": {"annotations": {}, "name": "pod-identity-webhook"}, "webhooks": [{"clientConfig": {"caBundle": ${CA_BUNDLE} "url": "https://127.0.0.1:23443/mutate"},"name":"iam-for-pods.amazonaws.com","rules":[{"apiGroups":[""],"apiVersions":["v1"],"operations":["CREATE"]," "resources": ["pods"]} creationTimestamp: "2019-12-30T07:53:28Z" generation: 1 name: pod-identity-webhook resourceVersion: "170" selfLink: / apis/admissionregistration.k8s.io/v1beta1/mutatingwebhookconfigurations/pod-identity-webhook uid: 7771f2b5-2ad9-11ea-8820-0a64f353aa45webhookscreationTimestamp-admissionReviewVersions:-v1beta1 clientConfig: caBundle: ${CA_BUNDLE} url: https://127.0.0.1:23443/mutate failurePolicy: Ignore Name: iam-for-pods.amazonaws.com namespaceSelector: {} rules:-apiGroups:-"" apiVersions:-v1 operations:-CREATE resources:-pods scope:'* 'sideEffects: Unknown timeoutSeconds: 30

The ${CA_BUNDLE} above refers to the actual CA bundle retrieved from the k8s API.

When the apiserver receives a request that matches the rules, the apiserver directs the admissionReview request to the webhook according to the clientConfig configuration.

I can view the information about Pod by looking at its yaml file:

Spec: containers:-command:-sh-- c-echo Hello Kubernetes! & & sleep 360000 env:-name: AWS_ROLE_ARN value: arn:aws:iam::921283538843:role/eksctl-eks-addon-iamserviceaccount-default-a-Role1-SSGCB7DDESI5-name: AWS_WEB_IDENTITY_TOKEN_FILE value: / var/run/secrets/eks.amazonaws.com/serviceaccount/token image: amazonlinux:latest imagePullPolicy: Always Name: myapp resources: {} terminationMessagePath: / dev/termination-log terminationMessagePolicy: File volumeMounts:-mountPath: / var/run/secrets/kubernetes.io/serviceaccount name: alice-token-qlsjp readOnly: true-mountPath: / var/run/secrets/eks.amazonaws.com/serviceaccount name: aws-iam-token readOnly: true volumes:-name: aws-iam-token projected: defaultMode: 420 sources: -serviceAccountToken: audience: sts.amazonaws.com expirationSeconds: 86400 path: token- name: alice-token-qlsjp secret: defaultMode: 420 secretName: alice-token-qlsjp

You can see that two token are mounted in the system.

/ var/run/secrets/kubernetes.io/serviceaccount: created by Service Account Admission Controller, which belongs to the Token configuration file created by Kubernetes by default. / var/run/secrets/eks.amazonaws.com/serviceaccount: the mount is assisted by eks-pod-identity-webhook. During the mount process, parameters such as audience are injected into token, in which the configuration of projected volume is defined. 1.2Information related to OIDC

EKS has helped us to create OIDC, through self-built OIDC, we can learn more about OIDC, here we are the most rudimentary oidc provider service we use, but provide a verification function, which can be compared to our certificate issuing authority CA.

In the EKS OIDC discovery file, it is finally placed in the / .well-known/openid-configuration configuration file to define the following specifications:

{"issuer": "https://oidc.eks.us-east-1.amazonaws.com/id/93BEE997ED0F1C1BA3BD6C8395BE0756"," jwks_uri ":" https://oidc.eks.us-east-1.amazonaws.com/id/93BEE997ED0F1C1BA3BD6C8395BE0756/keys", "authorization_endpoint": "urn:kubernetes:programmatic_authorization", "response_types_supported": ["id_token"], "subject_types_supported": ["public"] "claims_supported": ["sub", "iss"], "id_token_signing_alg_values_supported": ["RS256"]}

And jwks_uri describes the information of signing key, which is used for query verification:

{"keys": [{"kty": "RSA", "e": "AQAB", "use": "sig", "kid": "22b7abf04dc344c44fb83499508a158d789d82d5", "alg": "RS256" "n": "qJj1vYyzD0CpEaU93PlPdroS_Xir23X6GdLptyCMFb5zVNoSvegTo8Bb0_zb-8-z_VYoUj-L-3q8sP6R3Hp03ozkBCKa-cQ3gtITFUuQ6UQr0oIQjeZ3etJCOt1GktXLjeYssGiW58ToiTFzqjoeqGzz2-75WS6nsFnxCyCLg-2xFq4ALFrI4fAnwKwaQKowJQDKuUA50Tqv9P9ctEclHDlVi7K3_3giyiToZtmNUn-4KpQNx-a-4I7avn8d67UybOFOdYFeDnyOe9E8Ajuis22v2CvRr7rHEFjyxVCPoT0NFqiXkQMApd-7A6Rs33kIt7STwVBWhjFT5F--BzgJfQ"}]}

Through the self-built process, we can know that the public key information of oidc comes from the above sa.pub.

Go run. / hack/self-hosted/main.go-key $PKCS_KEY | jq '.keys + = [.keys [0]] | .keys [1] .kid = "" > keys.json II. Pod accesses AWS's resources.

If we find that we can directly use the command aws S3 ls when this Pod visits the aws S3 resources, we can see that awscli has automatically requested assume-role-with-web-identity for us. For information on why awscli automatically requests this interface, please refer to the awscli documentation. Subsequent resource requests call the obtained temporary credentials, which are stored in ~ / .aws / cli/cache.

We can also manually go to the sts service to obtain temporary credentials, with the following command:

Aws sts assume-role-with-web-identity-role-arn $AWS_ROLE_ARN-role-session-name alice-web-identity-token file://$AWS_WEB_IDENTITY_TOKEN_FILE

The content obtained is roughly as follows:

{"Credentials": {"AccessKeyId": "ASIA5NAGHF6NZIPEBVGZ", "SecretAccessKey": "U5GXw/lcz0PTbHUPO+A7Rk4RbMAK9ISzdrYW9BeK", "SessionToken": "IQoJb3JpZ2luX2VjELL/wEaCXVzLWVhc3QtMSJIMEYCIQC7Myfzl1QvG87aAF8ZdrFACbiQbNrtzzuQfLf+QX6j4AIhAJtehbkrVMLuO7HWjzetrwkHBCGxttoGFCn8stAxfs/rKpsECCoQABoMOTIxMjgzNTM4ODQzIgxy22hqmCjadsTNf/0q+AN4hIfLXLrUtwVuysbDCuGKZByp/Ow2N/t4JaeVaN7F7qYFVMRjm2nltxc1UTsfOTlIigR6mdKqdHWX982bVlSzu95oocK4vOLcLOh5TCOTehFTnH8ghe0GMd4Pyydi5yjrSM08JRZ+ACw/7/NgZM+p8e1JWI2aLOWk66K3rTqWnKL0V2EM3d8MkVSpjRcv1Rk3j+DBnlnpD8AulTA8vxa3p2JM8jw+EHgsnFIpBoseWrOpVeY21XHkkxU8bSZCbuqWbVkrRPmNccr0Kc6MXb6jN4tXfB0/L0PjQiHqB1O74nx4f0mQGvrI8nJwAGHCRj++bOwuHG3j7CTZqrXXmzphECUKkGE0nr1zpT5CqjoZsM7e/LhDUxNznAwIpQ9AUAoi6ZMWP4wlpVOFWm/qNNZBFRX9hGb8DTLdFBgPhXB+scch62Kc/n+HYdW5sDj88eh6s9JjwR8Nst25gaVJKam++5hfIqz25PJXOXIQ51mDkY3SpvKVsa4ORXDVFJd6s+IXPpaSoqCkYfbsmXs6PVs1cnH1ZF89z2qmFalzed+QVRydQJv21j+C3wYB4foKZZpL5+qd9oXdtpBc5vHaqTbhEL9fhheCchOurTlgqLzY2PegVdzqzaCyZoL0jnEYSYXNWPGOJlIVz2cnYsW8xexh6rm1hGp7VckwsuS28AU63wF4DQFwtFbyU08QpLgBbVUpmmrG06A4Hb4ouLihGLm61LTX487gMADfoBpfMcOdLmOxKLKja1KAdtas4qHE0sovubGF5s/1ntVA44GPMIAWZlnAEf4N03YG6AbJzWxBdLZ4FZBCluLzQtm0Y2r61o92KdId5hDFF1wm/9NfH3xpi3TNW9IZbIWAan2ccoPorgZOZjqfMGqj9PDnGkVqeWX9jo6RoqFPTNigngf7FAx/kk1Q7l+eoD94P2VIKrfAAhTfGm1WPsA+1mOgzkRPGgKhbw+I+mmbloegJRY9Om8S", "Expiration": "2020-01-02T10:04:50Z"}, "SubjectFromWebIdentityToken": "system:serviceaccount:default:alice" "AssumedRoleUser": {"AssumedRoleId": "AROA5NAGHF6NZWI5VRGOR:alice", "Arn": "arn:aws:sts::921283538843:assumed-role/eksctl-eks-addon-iamserviceaccount-default-a-Role1-SSGCB7DDESI5/alice"}, "Provider": "arn:aws:iam::921283538843:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/93BEE997ED0F1C1BA3BD6C8395BE0756", "Audience": "sts.amazonaws.com"}

So how does STS validate with OIDC Provider and eventually release Secret Key and Access Key.

Because the design of IAM Role also includes other mechanisms for Federation authentication. When you used the iamserviceaccount created by eksctl earlier, you created a resource project for role arn:aws:iam::921283538843:role/eksctl-eks-addon-iamserviceaccount-default-a-Role1-SSGCB7DDESI5, such as:

{"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Principal": {"Federated": "arn:aws:iam::921283538843:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/93BEE997ED0F1C1BA3BD6C8395BE0756"}, "Action": "sts:AssumeRoleWithWebIdentity" "Condition": {"StringEquals": {"oidc.eks.us-east-1.amazonaws.com/id/93BEE997ED0F1C1BA3BD6C8395BE0756:aud": "sts.amazonaws.com", "oidc.eks.us-east-1.amazonaws.com/id/93BEE997ED0F1C1BA3BD6C8395BE0756:sub": "system:serviceaccount:default:alice"}}]}

He trusts the user of this Federation source, as long as it is token, it can also be verified by OIDC and satisfy Condition, because we know that token is signed by controller-manager through-- service-account-private-key-file= "/ etc/kubernetes/pki/sa.key, and the authentication certificate in OIDC's jwks_uri is sa.pub, which is a pair of secret key pairs, so you can also trust token, which is a json web token. We can view the Payload structure information as follows:

{"aud": ["sts.amazonaws.com"], "exp": 1578041687, "iat": 1577955287, "iss": "https://oidc.eks.us-east-1.amazonaws.com/id/93BEE997ED0F1C1BA3BD6C8395BE0756"," kubernetes.io ": {" namespace ":" default "," pod ": {" name ":" myapp "," uid ":" 873e92b0-2d3d-11ea-8820-0a64f353aa45 "} "serviceaccount": {"name": "alice", "uid": "7a58554d-2bb1-11ea-8820-0a64f353aa45"}}, "nbf": 1577955287, "sub": "system:serviceaccount:default:alice"}

Once the Pod initiates the AssumeRoleWithWebIdentity action with the STS server node, the client will bring in the WebIdentityToken information, in which the STS will keys.json the Token through the credential information provided on the OIDC Provider you configured, confirm that your client uses the Service Account Token initiation source to identify the source signed by your OIDC Provider, and authenticate your Trust Relationship policy To allow your client to operate the AssumeRoleWithWebIdentity action, you can obtain the temporary access information of your corresponding IAM Role, and finally return the corresponding AccessKeyID and SecretAccessKey information, so that your client can use the temporary key to access other AWS resources (for example: S3 Bucket) again.

Reference, OAuth 2.0 VS OIDC

OAuth 2.0

OIDC

After reading the above, do you have any further understanding of the working mechanism of EKS IRSA? If you want to know more about it, you are welcome to follow the industry information channel. Thank you for reading.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.