<p>It seems that we cannot make the Snowplow container (snowplow/scala-stream-collector-kinesis) use the service account we provide. It always uses the <code>shared-eks-node-role</code> but not the provided service account. The config is set to <code>default</code> for both the <code>accessKey</code> as the <code>secretKey</code>.</p>
<p>This is the service account part we use:</p>
<pre><code>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
</code></pre>
<p>And when I inspect the pod I can see the account:</p>
<pre><code>AWS_ROLE_ARN:                 arn:aws:iam::123:role/thijs-eks-service-account-role-snowplow
</code></pre>
<p>The error then shows not the right account.</p>
<pre><code>Exception in thread &quot;main&quot; 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)
</code></pre>

<p>The collector itself doesn't do any role swapping. It only cares to receive credentials via one of three methods:</p>
<ul>
<li>the default creds provider chain</li>
<li>a specific IAM role</li>
<li>environment variables.</li>
</ul>
<p>The most popular deployment is on an EC2 instance, in which case the default EC2 role can be used to access other resources in the account.</p>
<p>It looks like when you are deploying it on EKS things are not as straightforward. The collector seems to work with this assumed role: <code>arn:aws:sts::123:assumed-role/shared-eks-node-role/i-123</code> but it is not authorised with Kinesis permissions. Do you know what process creates that role? Perhaps you could add the missing Kinesis policies there?</p>
