Upgrade aws-sdk to support EKS IAM Roles for Service Accounts

[zarrarrana]

Update aws-sdk to 2.521.0 or higher to support EKS IAM Roles for Service Accounts.

Zarrar

[derrickburns]

I was wondering why this wasn't working!!!

[marcincuber]

Definitely waiting for this upgrade!

[derrickburns]

Unfortunately, just upgrading the aws-sdk does not appear to be sufficient.

I built the package with

 "aws-sdk": {
      "version": "2.528.0",
      "resolved": "https://registry.npmjs.org/aws-sdk/-/aws-sdk-2.528.0.tgz",
      "integrity": "sha512-WBgavPqKHvYcIhD7LhmLLYOKtG/SUdNY6hMB0N/Jxaolzx4sOa7xegiZ8sdkAUq/vUEs1frnBF9hNmeIszUWCg==",

And deployed it. I get:

{"level":50,"time":1568607465005,"pid":16,"hostname":"external-secrets-59f8c4d964-wn59s","message":"User: arn:aws:sts::118346523422:assumed-role/eksctl-test1-nodegroup-ng-NodeInstanceRole-F9L42IA4PBFA/i-07f29f17597c840c1 is not authorized to perform: secretsmanager:GetSecretValue on resource: arn:aws:secretsmanager:us-west-2:118346523422:secret:test1/qa2/server-KBjbGT"

Note the role is WRONG. It should be the role from the environment:

arn:aws:iam::118346523422:role/eksctl-test1-addon-iamserviceaccount-externa-Role1-NZBWIFHK6XY4

which has:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:aws:secretsmanager:us-west-2:118346523422:secret:test1/*",
            "Effect": "Allow"
        }
    ]
}

[marcincuber]

@derrickburns I did exactly the same and basically temporary credentials are not provisioned for that provided service account. Do you think it might be an issue with aws-sdk for Node?

[derrickburns]

@marcincuber That is my guess.

[derrickburns]

So we have a workaround but we cannot implement it with this helm chart. Can you allow one to set the securityContext in the deployment?

[marcincuber]

@derrickburns are you saying that adding the following solves the issue?

      securityContext:
        fsGroup: 65534

[faarshad]

@derrickburns are you saying that adding the following solves the issue?

      securityContext:
        fsGroup: 65534

It does solve the issue. I have tested it with the 1.3.1 version(+aws-sdk-js update) of kubernetes-external-secrets

[derrickburns]

@marcincuber Yes.

I have external-secrets that uses version 2.521.0 or higher (I can't recall now) of aws-sdk-js with the workaround above. It works.

I have also used the above workaround on several other services and they all work.

[marcincuber]

I shall assume that this issue is solved in two steps:

1. Upgrade aws-sdk
2. Specifying following securityContext:

securityContext:
        fsGroup: 65534

[mycrEEpy]

Shouldn't it be "fsGroup: 1000" as the node process is running as user node with uid/gid 1000?

/app $ ps
PID   USER     TIME  COMMAND
    1 node      0:00 npm
   16 node      0:54 node ./bin/daemon.js
   27 node      0:00 sh
   33 node      0:00 ps

/app $ cat /etc/passwd
root:x:0:0:root:/root:/bin/ash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
news:x:9:13:news:/usr/lib/news:/sbin/nologin
uucp:x:10:14:uucp:/var/spool/uucppublic:/sbin/nologin
operator:x:11:0:operator:/root:/bin/sh
man:x:13:15:man:/usr/man:/sbin/nologin
postmaster:x:14:12:postmaster:/var/spool/mail:/sbin/nologin
cron:x:16:16:cron:/var/spool/cron:/sbin/nologin
ftp:x:21:21::/var/lib/ftp:/sbin/nologin
sshd:x:22:22:sshd:/dev/null:/sbin/nologin
at:x:25:25:at:/var/spool/cron/atjobs:/sbin/nologin
squid:x:31:31:Squid:/var/cache/squid:/sbin/nologin
xfs:x:33:33:X Font Server:/etc/X11/fs:/sbin/nologin
games:x:35:35:games:/usr/games:/sbin/nologin
postgres:x:70:70::/var/lib/postgresql:/bin/sh
cyrus:x:85:12::/usr/cyrus:/sbin/nologin
vpopmail:x:89:89::/var/vpopmail:/sbin/nologin
ntp:x:123:123:NTP:/var/empty:/sbin/nologin
smmsp:x:209:209:smmsp:/var/spool/mqueue:/sbin/nologin
guest:x:405:100:guest:/dev/null:/sbin/nologin
nobody:x:65534:65534:nobody:/:/sbin/nologin
node:x:1000:1000:Linux User,,,:/home/node:/bin/sh

[JeroenRijks]

This issue can be closed now, right?