Concerning injecting secrets into the ECS-launched task, without specifying a separate task definition, are there plans to improve the secrets mounting process? Currently using some less-than-transparent entrypoint shenanigans to get a single secret with many key: value pairs expanded and set to environmental variables. Trying to avoid making CI/CD unnecessarily complex by exclusively using a beefed-up compose file.

What kind of improvements do you have in mind? Right now, our secrets mounting is mostly a pass-through to the AWS recommendation: https://docs.dagster.io/deployment/guides/aws#secrets-management-in-ecs https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data-secrets.html You can specify specific secrets to bind from AWS Secrets Manager or you can specify a tag value and it’ll bind any AWS Secrets Managers secrets with that tag.

Right, and if I’m not mistaken, they only show up as plaintext at

/run/secrets/secret_name

, which then requires a different entrypoint script for each service. I may have just used you as a rubber ducky non-consensually. It hadn’t occurred to me until right now to use both entrypoint and command.

I had a similar question, when I declare a tag “dagster” for any secret name resource it will show up in the form of key=secret_name and value=secret_arn. I.e. I have one secrets called

dagster/slack

and it will show up like this in the

run task

env variables..

{
  "dagster/slack": "arn:aws:secretsmanager:eu-west-1:xxxxxxxxxxx:secret:dagster/slack-ToNAkO"
}

Is there anyway of setting the json-key as the key and the value as its actual value? for example:

{
  "SLACK_TOKEN": "jsikfniwfndw"
}

?

Yeah, that’s what my entrypoints handle. I do see that the newest release

0.14.3

has support for AWS secrets as a resource to access within ops, but that seems very repetitive and onerous for my use-case, at least. I’m not willing to fill up the secrets manager console with a bunch of individual secrets for each of the many many API keys and stuff that I need to access either, so I’m stuck for the time being using an entrypoint script to access the file mounted at

/run/secrets/secret_name

, unpack it, and set them all before anything else happens.

I did setup a resource that would call boto3 secrets resource behind the scenes and would unpack the response object but I had to have this dependency on every other resource which needed this (think of all the db connections etc). But yeah your method makes sense to bring them in at build time

I think what you posted (with a yaml dict) is accurate and our docs (with a yaml list) are inaccurate: I’d expect:

run_launcher:
  module: dagster_aws.ecs
  class: EcsRunLauncher
  config:
    secrets:
      SLACK_TOKEN: arn:aws:secretsmanager:eu-west-1:XXXXXXXXXX:secret:dagster/slack-ToNAkO:SLACK_TOKEN

to map the entire secret at that ARN to

SLACK_TOKEN

. And if you’ve stored many key/values in the same secret as a JSON blob, I’d expect:

run_launcher:
  module: dagster_aws.ecs
  class: EcsRunLauncher
  config:
    secrets:
      SLACK_TOKEN: arn:aws:secretsmanager:eu-west-1:XXXXXXXXXX:secret:dagster/slack-ToNAkO:SLACK_TOKEN/my-key

to map the

my-key

item to

SLACK_TOKEN

. I’ll verify today and update either the docs or the code accordingly before the next release.

thanks @jordan!

Correction - we indeed are expecting a list of secrets which violates this expectation. So we’ll have to think about how to clean that up.

Yeah ideally to follow something of a similar structure to how its defined in the docs. They have their arn broken down as

arn:aws:secretsmanager:region:aws_account_id:secret:secret-name:json-key

So like in most situations it might be one (or two) keys from the returned json of the secret thats needed to be mapped as an env variable (like

SLACK_TOKEN

above). I’ve tested it in a task definition and:

{
  "containerDefinitions": [
    {
      "secrets": [
        {
          "name": "SLACK_TOKEN",
          "valueFrom": "arn:aws:secretsmanager:eu-west-1:XXXXX-XXXXXX-XXXXX:secret:dagster/slack-AbCdEf:SLACK_TOKEN::"
        }
      ]
    }
  ]
}

maps perfectly into the container at runtime i.e.

os.getenv('SLACK_TOKEN')

gives me the desired result. Most of the logic from what I’ve seen on the module is there so should just be a few tweeks.

FYI https://github.com/dagster-io/dagster/pull/6985