K8S上的扫雪机收集器不使用服务帐户

Question

看起来我们不能让扫雪机容器(scala- that /scala-stream-collector-kinesis)使用我们提供的服务账号。它始终使用shared-eks-node-role，但不使用提供的服务帐户。对于作为secretKey的两个accessKey，配置都设置为default。

这是我们使用的服务帐户部分：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: thijs-service-account
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123:role/thijs-eks-service-account-role-snowplow

当我检查pod时，我可以看到帐户：

AWS_ROLE_ARN:                 arn:aws:iam::123:role/thijs-eks-service-account-role-snowplow

然后，错误显示不是正确的帐户。

Exception in thread "main" com.amazonaws.services.kinesis.model.AmazonKinesisException: User: arn:aws:sts::123:assumed-role/shared-eks-node-role/i-123 is not authorized to perform: kinesis:DescribeStream on resource: arn:aws:kinesis:eu-west-1:123:stream/snowplow-good (Service: AmazonKinesis; Status Code: 400; Error Code: AccessDeniedException; Request ID: 123-123-123; Proxy: null)

Answer 1

收集器本身不做任何角色交换。它只关心通过以下三种方法之一接收凭据：

对于特定的IAM role

• environment变量，
• 默认的creds提供商链
• 。

最常用的部署是在EC2实例上，在这种情况下，可以使用默认的EC2角色来访问帐户中的其他资源。

看起来，当你在EKS上部署它时，事情并不是那么简单。收集器似乎使用这个假定的角色：arn:aws:sts::123:assumed-role/shared-eks-node-role/i-123，但它没有被授权使用Kinesis权限。你知道是什么流程创建了这个角色吗？也许您可以在那里添加缺少的Kinesis策略？

Answer 2

我也有同样的问题。

它不能使用env作为值，因为这些值没有设置。但是，收集器作为容器运行-它应该使用默认凭据链。

从注释中可以看出，在没有设置env变量的情况下，我应该使用iam -当我这样做时，它使用IAM实例配置文件，它加载底层节点角色-而不是SA指定的角色。

SDK支持IRSA (根据supported versions，我已经将雪地搜集器容器镜像更新为1，它支持1.11.704以上的SDK )，从我从收集器文档中可以看到，streams配置需要一个以env或iam作为值的aws块……但是我想使用默认的凭证链，而不指定方法...

如果我连接到容器，我可以看到凭证是按照SA设置的：

$ env | grep -i aws
AWS_REGION=my-region
AWS_DEFAULT_REGION=my-region
AWS_ROLE_ARN=arn:aws:iam::<redacted>:role/sp-collector-role
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token

但是当我运行收集器时，它仍然使用nodes IAM实例配置文件，并且在sp-collector-role下看不到任何活动。有没有办法使用默认的凭证链？例如，在同一服务帐户中的容器上使用aws CLI时，我没有指定任何凭据，但当我运行aws sts get-caller-identity时，SDK会正确地解析IRSA角色。