aws的各种坑-丁

翻了翻之前的case，想起原来遇到的一个问题，估计短期内也不会解决。个人觉得这种问题属于“不重要且不紧急”。

大概意思是，自己创建的eks集群，希望授权另外的IAM用户访问，默认情况下是按照这个link进行处理：管理集群的用户或 IAM 角色 – Amazon EKS

这个链接从头到尾没有特意指出跨区域（region）的注意事项，因此个人理解，这里面的用法是适用于所有区域的，比如类似 username: system:node: 这种写法

直到我新建了一个iam role并attach到一个 爱尔兰的实例 ，而被操作的eks在香港的时候，问题就来了：配置好k8s中 kube-system那个ns里的configmap：aws-auth之后，kubectl访问失败，幸亏开了apiserver的日志，点进去根据时间点搜auth，一大堆反向解析相关的报错

msg=”access denied” arn=”arn:aws:iam::502076666666:role/jenkins-eks-operator” client=”127.0.0.1:39214″ error=”failed mapping username: failed querying private DNS from EC2 API for node i-0fedcba0987654321: InvalidInstanceID.NotFound: The instance ID ‘i-0fedcba0987654321’ does not exist\n\tstatus code: 400, request id: ffffffff-aaaa-cccc-eeee-000000000000 ” method=POST path=/authenticate sts=sts.ap-east-1.amazonaws.com

所以开了这个case问了下，答曰：

一般来说，这个问题通常与 AWS IAM Authenticator 有关。

根据您的设置，帮助您进行验证时，IAM Authenticator 无法透过相应的 API 呼叫以找到您于香港区域存在该实例 (i-0fedcba0987654321)，以满足验证工作。

与此同时，您于 Kuberernetes RBAC 验证设置 (aws-auth ConfigMap) 中，配置了以下内容：

– groups: – system:masters rolearn: arn:aws:iam::502076666666:role/jenkins-eks-operator username: system:node:

然而，由于您定义了 “” 变量以作为 RBAC 用户的识别名称，通常，这种设置会由 AWS IAM Authenticator 主动反解析私有 DNS 信息，并互叫 EC2 相应 API 帮助您查找有关 EC2 实例，以获取相应的信息已进行缓存。我可以注意到现阶段 AWS IAM Authenticator 以支持与 EKS 集群所在的单一区域进行验证 [1] 進行存取身份识别。这很可能是您最终于爱尔兰 区域 (eu-west-1) 进行 kubectl 操作时，发生无法存取的原因。

因此，就我的理解，您可以修正您的相应 aws-auth 设置，以静态名称绑定您相应的 IAM Role，例如：

admin – groups: – system:masters rolearn: arn:aws:iam::502076666666:role/jenkins-eks-operator username: admin

[1] Add support for multiple regions #184 – https://github.com/kubernetes-sigs/aws-iam-authenticator/pull/184

然后看了看附上的那个PR，大意是因为无法判断执行aws-iam-authenticator的实例在哪个region，甚至是不是aws的ec2实例。源头是无法跨region反向解析类似EC2PrivateDNSName这样的变量名。

个人觉得，判断是否是ec2实例，如果配置了允许访问元数据服务的话，可以通过访问元数据服务来解决（169.254.169.254），但也不排除通过仿冒元数据服务器以伪造凭据引发安全风险。至于前者就是aws-iam-authenticator的问题了，具体可以参考那个PR的这个回复

再者，一个k8s集群内的username而已，从效率角度来说，每次访问集群的时候都反向解析一下实例的名称，似乎也意义不大。反正aws的ec2实例名默认跟内网IP（准确的说所谓内网也就是VPC）强相关，拿到IP跟拿到实例名……其实没啥区别。更何况log里记录了更具有唯一性的实例ID。如果说想做事后审计什么的，实例ID显然更可靠。