CODEWITHSUNDEEP
windowsamazon-s3amazon-ec2amazon-ecs
watdo
watdo

Reputation: 739

AWS ECS Windows Scheduled Task running as System - AWS Credentials not found

looking for some pointers,

I am trying to get a windows scheduled task running on a Windows Container on AWS ECS, so far I have:

I have a powershell script I have written to interact with an S3 bucket which runs perfectly fine when I execute it from the AWS Session manager and exec into the running container. The aws configure list command shows the credentials it's using (container-role) and everything works ok interaction wise.

The issue is I need this to be a timed operation, so I created a Scheduled Task to run the powershell command and that's where the issue starts:

  1. Running scheduled task not as System means it won't run like a daemon / without login / non-interactively - however, when I try to execute the same script, the aws cli commands fail because they cannot find the AWS credentials, aws configure list returns empty and the s3 command returns a No credentials found message.
  2. Running the scheduled task as the container-admin user (which is what the AWS Session shell logs me in as) refuses to execute the task - though it shows as ready it never runs, I believe because that is the same user which also sets up the scheduled task it is implicitly set to run only when the user is logged on - unless I used the /NP switch, which wants me to enter the password interactively (no good).

Is there any reason why a Scheduled task running as the SYSTEM user would not be able to use the same AWS CLI commands as the ContainerAdmin user which I get logged in as via the AWS Session manager? Have I missed an option on the Scheduled Task command somewhere?

Thanks in advance

Upvotes: 1

Views: 453

Answers (1)

watdo
watdo

Reputation: 739

It seems this may be an uncommon thing to do judging by the lack of activity, but I did manage to resolve this in the end!

The AWS Task Role identity is accessible over a well-known address when executing in the context of the running container, this contains the short-lived access token, access key and secret.

I ended up creating the scheduled task script to take this URI (with the unique task role guid as part of it) as a start-up parameter so that the URI can be utilised to fetch these details, and create a transient AWS CLI configuration for the background task on a per-run basis. This then allows the task to run as a background process, whilst being able to access AWS as the identity the Container would be able to do so with.

Not sure if it's a particular oddity with Windows containers, or how ECS propogates that identity to the container runtime, but this was the only way I could get it to run non-interactively using the built-in AWS IAM Task identity.

Upvotes: 0

Related Questions