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

1. K8s Authentication

We know that apiserver has the following authentication methods:

X509 Client CertsStatic Token FileBootstrap TokensStatic Password FileService Account TokensOpenID Connect TokensWebhook Token AuthenticationAuthenticating Proxy

Generally speaking, we use binary self-built K8s cluster or cluster created by kubeadm. The cluster manager, that is, the user object in K8s, uses the X509 certificate for verification. If it is signed by the same CA, the user is recognized.

In order to reduce the complexity of user management, enterprises need to figure out how to integrate IAM users into the EKS cluster, so that we do not need to delay creating users for EKS and reduce a set of user maintenance work. How is this integrated? it passed the Webhook Token Authentication of K8s, and the authentication process architecture diagram is as follows:

We can see that there is more Authentication in the figure. Through aws-iam-authenticator, we can know that this is a set of DaemonSet Pod running in EKS Control Plane to receive authentication requests from apiserver.

2. Dissect EKS2.1 and create EKS

We use the command eksctl to create an EKS cluster. By default, eksctl calls awscli's config, so we need to configure awscli first, and the relevant user or role has the permission to create an eks cluster:

Eksctl create cluster-name eks-- region us-east-1\-- node-type=t2.small-- nodes 1-- ssh-public-key .ssh / id_rsa.pub\-- managed-- zones us-east-1f,us-east-1c-- vpc-nat-mode Disable

After the cluster is created, the configuration files needed by kubeclt will be automatically configured for us, and the creator of the cluster will automatically obtain the role of cluster cluster-admin with the highest permissions.

2.2. introduce aws-iam-authenticator

We can first check the startup parameters of kube-apiserver through CloudWatch Logs. We can see that there is a set of startup parameters:

-- authentication-token-webhook-config-file= "/ etc/kubernetes/authenticator/apiserver-webhook-kubeconfig.yaml"

It indicates that we have started the authentication in webhook mode. What is in the yaml file after the parameter? as we can see from the github document of aws-iam-authenticator, we use the following command to generate:

Wangzan:~/k8s $aws-iam-authenticator init-I `openssl rand 16-hex`info [2020-01-07T07:50:54Z] generated a new private key and certificate certBytes=804 keyBytes=1192INFO [2020-01-07T07:50:54Z] saving new key and certificate certPath=cert.pem keyPath=key.pemINFO [2020-01-07T07:50:54Z] loaded existing keypair certPath=cert.pem keyPath=key.pemINFO [2020-01-07T07:50:54Z] writing webhook kubeconfig file KubeconfigPath=aws-iam-authenticator.kubeconfigINFO [2020-01-07T07:50:54Z] copy cert.pem to / var/aws-iam-authenticator/cert.pem on kubernetes master node (s) INFO [2020-01-07T07:50:54Z] copy key.pem to / var/aws-iam-authenticator/key.pem on kubernetes master node (s) INFO [2020-01-07T07:50:54Z] copy aws-iam-authenticator.kubeconfig to / etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml on kubernetes master node ( S) INFO [2020-01-07T07:50:54Z] configure your apiserver with `--authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/ Kubeconfig.yaml` to enable authentication with aws-iam-authenticator

View the generated configuration file aws-iam-authenticator.kubeconfig

Wangzan:~/k8s $cat aws-iam-authenticator.kubeconfig # clusters refers to the remote service.clusters:-name: aws-iam-authenticator cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURJRENDQWdpZ0F3SUJBZ0lRVDRmUllwRy9uSlE0UURmSHUwb2M3ekFOQmdrcWhraUc5dzBCQVFzRkFEQWcKTVI0d0hBWURWUVFERXhWaGQzTXRhV0Z0TFdGMWRHaGxiblJwWTJGMGIzSXdJQmNOTWpBd01UQTNNRGMxTURVMApXaGdQTWpFeE9URXlNVFF3TnpVd05UUmFNQ0F4SGpBY0JnTlZCQU1URldGM2N5MXBZVzB0WVhWMGFHVnVkR2xqCllYUnZjakNDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFLRkhTU3ZjWGZFNVZrN3UKejBRNjFGVE1LQS9PeE5HaVlOa05iS0ZzSW9pdW5VejBLdUI4aFBReitEOGxpNnpYZUozWDdNNVNyaG1hYjRBMgowWXJNZEVlcSthYVR5aVhFV2QrREFlUU9HcFFRQm0ya2hvdEgzS2Vrd2dlTjlwbzFUUjBHQVgrbFBQWWloOHNBCml6ZWxBRENLZUMrUS8yWnVZYkttaUFiSm1MNDdqc09nd0pXYldQV0JOdm54VDkrL0wwTHphN1c3MVdieCszaWsKQUdUT2xDWm5tZjY0b0sxQWw4eDNxUktnSXp0bnFBMWRFeEMwS2ZzR1dRRy9Xb00rbnRXZW40QmJEOW1XakF4Zgo0Yk9CaXBOcDMrMlFJOU5LL1pUOTYyaDFZbE8yUWdiYVMrSTZtR2o5WXhwamFXdXgyWGNUd2N0MTFjODFMNWcxCmNaVjZJZ2tDQXdFQUFhTlVNRkl3RGdZRFZSMFBBUUgvQkFRREFnS2tNQk1HQTFVZEpRUU1NQW9HQ0NzR0FRVUYKQndNQk1BOEdBMVVkRXdFQi93UUZNQU1CQWY4d0dnWURWUjBSQkJNd0VZSUpiRzlqWVd4b2IzTjBod1IvQUFBQgpNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUIyaE1wYm5kTDhVa3VRNVVuZzNkWTh6Y0RQZ2JvbU9Mb0t5dUlzCnVoNkljMUtaMUFiNmVoVDg2bzN2bzJzbnVoNkhibU13NjhvNE9SSllLdTB4RXB3RDR0YUlSVEN1bk9KVHFUeHoKZDZsN2xqdGtBMWZnUktpUHF1SjlyUmxqYXVTMGMxU05lWTVmR2hhUEh4UFBBMHoxN3orMWdiVzNiUjFEckxHQwp6WHVCNStFM0xSVHJCck53aHlZOUtIcVB4Vy9PL1M2V2FZbUR4R3Y4bklNNUUrTzltRFBPWGZpWFJDRFFkb2R5ClRadnU1VDR5ZVhQaEQwRmJKdjg4OSsxZnR4TGlSaUdTQ29lRTNEMUdiYSswZXFMT0hidExUY29VZ25WTGVlMTAKclZDOWRiOU05ckxDZnU1aUEvcGdORm80VTF1ejAvbFUyV0RnYSthUWNNeC9iaHZJCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K server: https://localhost:21362/authenticate# users refers to the API Server's webhook configuration# (we don't need to authenticate the API server). Users:-name: apiserver# kubeconfig files require a context. Provide one for the API Server.current-context: webhookcontexts:- name: webhookcontext: cluster: aws-iam-authenticator user: apiserver2.3, the whole IAM authentication process

First, let's take a look at the profile information for kubectl:

ApiVersion: v1clusterscluster: certificate-authority-data: DATA+OMITTED server: https://93BEE997ED0F1C1BA3BD6C8395BE0756.sk1.us-east-1.eks.amazonaws.com name: eks.us-east-1.eksctl.iocontexts:- context: cluster: eks.us-east-1.eksctl.io user: wangzan@eks.us-east-1.eksctl.io name: wangzan@eks.us-east-1.eksctl.iocurrent-context: wangzan@eks.us-east-1.eksctl.iokind: Configpreferences: {} users:- name: wangzan@eks.us-east-1.eksctl.io user: exec: apiVersion: client.authentication.k8s.io/v1alpha1 args:-token-- I-eks command: aws-iam-authenticator env: null

We can see the user field, where the certificate is not used for authentication, but the aws-iam-authenticator client is used, with the following command:

Wangzan:~ $aws-iam-authenticator token-I eks {"kind": "ExecCredential", "apiVersion": "client.authentication.k8s.io/v1alpha1", "spec": {}, "status": {"expirationTimestamp": "2020-01-07T08:23:23Z", "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMuYW1hem9uYXdzLmNvbS8_QWN0aW9uPUdldENhbGxlcklkZW50aXR5JlZlcnNpb249MjAxMS0wNi0xNSZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUE1TkFHSEY2TllYU01DTEhPJTJGMjAyMDAxMDclMkZ1cy1lYXN0LTElMkZzdHMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDIwMDEwN1QwODA5MjNaJlgtQW16LUV4cGlyZXM9MCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QlM0J4LWs4cy1hd3MtaWQmWC1BbXotU2lnbmF0dXJlPTU2MjA5OTZhY2MzZGE3OWI3OGI0NDVjOTVkMTMyNmU0NjZmNTUyZTMzNDdkN2Y5MmExNGUwMzcwOTJiMzdmMDY"}}

This is actually getting a temporary token from sts to use as identity credentials, which is also equivalent to the following command:

Wangzan:~ $aws eks get-token-cluster-name eks {"status": {"expirationTimestamp": "2020-01-07T08:25:38Z", "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMuYW1hem9uYXdzLmNvbS8_QWN0aW9uPUdldENhbGxlcklkZW50aXR5JlZlcnNpb249MjAxMS0wNi0xNSZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1FeHBpcmVzPTYwJlgtQW16LURhdGU9MjAyMDAxMDdUMDgxMTM4WiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QlM0J4LWs4cy1hd3MtaWQmWC1BbXotU2VjdXJpdHktVG9rZW49JlgtQW16LUNyZWRlbnRpYWw9QUtJQTVOQUdIRjZOWVhTTUNMSE8lMkYyMDIwMDEwNyUyRnVzLWVhc3QtMSUyRnN0cyUyRmF3czRfcmVxdWVzdCZYLUFtei1TaWduYXR1cmU9NDUyYzA5ZTIwMzg2YjFmODU0NTU4YjhjNzBkNDA2MzdkYzM2Y2ExNzA5YWIxODQzNzE3NDdhY2IwYTUyNGIzYw"}, "kind": "ExecCredential", "spec": {}, "apiVersion": "client.authentication.k8s.io/v1alpha1"}

Let's go back to the architecture diagram above. Kubectl will put the acquired token in the request header Authorization of http, send it to apiserver,apiserver, and then go back to request the configured webhook server, that is, daemonset pod (aws-iam-authenticator server). The aws-iam-authenticator server will take the token to request the sts service, and the sts service will verify the validity of its token, and return the ARN (IAM Identity) of the IAM user.

When aws-iam-authenticator server gets the returned ARN, go back and compare it with one of the configmap aws-auth in K8s.

2.4 、 configmap aws-auth

Let's take a look at the information in the configmap aws-auth of the machine we just created:

Wangzan:~ $kubectl get cm aws-auth-nkube-system-oyamlapiVersion: v1data: mapRoles: |-groups:-system:bootstrappers-system:nodes rolearn: arn:aws:iam::921283538843:role/eksctl-eks-nodegroup-ng-5a1b33b9-NodeInstanceRole-1B757SI5DCABJ username: system:node: {{EC2PrivateDNSName}}-groups:-system:bootstrappers-system:nodes-system:node-proxier rolearn: arn:aws:iam :: 921283538843:role/eksctl-eks-cluster-FargatePodExecutionRole-DEAGGBFGQ9YB username: system:node: {{SessionName}} kind: ConfigMapmetadata: creationTimestamp: "2019-12-30T07:57:47Z" name: aws-auth namespace: kube-system resourceVersion: "529891" selfLink: / api/v1/namespaces/kube-system/configmaps/aws-auth uid: 117c0e14-2ada-11ea-8820-0a64f353aa45

The mapping relationship between IAM Identity and user or group in K8s is defined. The default administrator created by the cluster is not included in this. It may be for security reasons, because this file can be edited and modified.

From the above step, we can know that by comparing aws-auth,apiserver, we will get the username or group of the requested user, and then grant the corresponding permission to IAM through its authorization authorization. Our cluster generally uses RBAC.

For more configuration information, you can refer to the official documentation:

Https://github.com/kubernetes-sigs/aws-iam-authenticator

Https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/add-user-role.html

Welcome to scan the code and follow us for more information.

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.