K8S 上的 Snowplow Collector 不使用服務帳戶

Question

似乎我們無法讓 Snowplow 容器 (snowplow/scala-stream-collector-kinesis) 使用我們提供的服務帳戶。 它始終使用shared-eks-node-role但不使用提供的服務帳戶。 accessKey和secretKey的配置都設置為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 角色
• 環境變量。

最流行的部署是在 EC2 實例上，在這種情況下，默認的 EC2 角色可用於訪問帳戶中的其他資源。

看起來當您在 EKS 上部署它時，事情並不那么簡單。 收集器似乎使用此假定角色： arn:aws:sts::123:assumed-role/shared-eks-node-role/i-123但未獲得 Kinesis 權限授權。 你知道什么過程創造了那個角色嗎？ 也許您可以在那里添加缺少的 Kinesis 策略？

Answer 2

我遇到過同樣的問題。 首先確保您根據https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html正確設置了 IAM 角色。 確保名稱一致並且具有正確的權限。

仔細檢查后，請確保您使用的是最新版本的掃雪機。 舊版本可能沒有正確版本的 AWS SDK。您至少需要 AWS SDK v1.12.128 或 AWS SDK v2, 2.10.11 [鏈接] 。

最后將掃雪機配置文件中的 aws accessKey 和 secretKey 設置為default 。 重新部署並確保 Pod 和服務帳戶已重新創建。 你應該擅長這一點。

參考：

https://github.com/snowplow/stream-collector/issues/186

Answer 3

我有同樣的問題。

它不能將env用於值，因為這些值未設置。 但是，收集器作為容器運行——它應該使用默認的憑證鏈。

從注釋來看，似乎沒有設置env變量，我應該使用iam - 當我這樣做時，它使用 IAM 實例配置文件，它加載底層節點角色 - 而不是 SA 指定的角色。

SDK 支持 IRSA（我已將掃雪機收集器容器映像更新為支持 SDK 大於 1.11.704 的支持版本的 1），從收集器文檔中我可以看到，流配置需要一個aws塊env或iam作為值...但我想在不指定方法的情況下使用默認憑證鏈...

如果我連接到容器，我可以看到信用是根據 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

但是當我運行收集器時，它仍然使用節點 IAM 實例配置文件，並且我沒有看到sp-collector-role下的任何活動。 有沒有辦法使用默認的憑證鏈？ 例如，在同一服務帳戶的容器中使用 aws CLI，我沒有指定任何憑據，但是當我運行aws sts get-caller-identity時，SDK 正確解析了IRSA角色。