Support secrets manager JSON secrets

[agabeev-godaddy]

Is your feature request related to a problem? Please describe. Common way to store secrets in AWS secrets manager is in a JSON format. However, current implementation supports only plain string value when processing ELASTIC_APM_SECRETS_MANAGER_SECRET_TOKEN_ID environment variable: https://github.com/elastic/apm-aws-lambda/blob/main/app/aws.go#L70

It may be useful to support json secrets as well.

Describe the solution you'd like We may consider to introduce second level environment variables, like ELASTIC_APM_SECRETS_MANAGER_SECRET_TOKEN_JSON_FIELD ELASTIC_APM_SECRETS_MANAGER_API_KEY_JSON_FIELD

If these env variables are set, prior to using secret value, we may attempt to parse string secret value into unstructured JSON map and retrieve token/apikey from map based on provided json field, before this lines: https://github.com/elastic/apm-aws-lambda/blob/main/app/aws.go#L41 https://github.com/elastic/apm-aws-lambda/blob/main/app/aws.go#L52

Describe alternatives you've considered

1. flattening and copying secret value as plain text in the secrets manager - unfortunately it does not work well for our use case.

Additional context Existing doc: https://www.elastic.co/guide/en/apm/lambda/current/aws-lambda-secrets-manager.html

[axw]

@agabeev-godaddy thanks for opening the issue. Sounds reasonable to accept JSON, particularly since AWS recommends encoding secrets as JSON in their docs.

We may consider to introduce second level environment variables, like ELASTIC_APM_SECRETS_MANAGER_SECRET_TOKEN_JSON_FIELD ELASTIC_APM_SECRETS_MANAGER_API_KEY_JSON_FIELD

Is this important for your use case? Would it be acceptable if we were to expect well-defined, non-configurable, keys like "secret_token" and "api_key"? As a user, you would specify the secret ID, and its contents would have a well-defined format like:

{
    "secret_token": "<secret token>"
}

This would be similar to how AWS services expect JSON secrets with a specific JSON structure: https://docs.aws.amazon.com/secretsmanager/latest/userguide/reference_secret_json_structure.html

[agabeev-godaddy]

Hi @axw , sorry for late reply,

Can we use well-defined keys as fallback value, like 'secert_token' / 'api_key', but still allow to override? Do you have concern regarding parsing raw map structure? Also if will be nice, if parser is tolerant to additional fields in json.

Thanks, Artyom

[axw]

Can we use well-defined keys as fallback value, like 'secert_token' / 'api_key', but still allow to override?

It's technically possible, but I'd like to understand why this is important. Could you please describe your use case(s) for overriding the keys?

Do you have concern regarding parsing raw map structure?

No - I'd just like to keep things simple, and follow the existing approach used by AWS services.

Also if will be nice, if parser is tolerant to additional fields in json.

Definitely :+1:

[agabeev-godaddy]

@axw , the reason behind is that there is a process which manages different ESSP installations and different keys are already in place. It may be hard to adjust, but I think it is manageable.

However, we can go with approach you are suggested if we support additional fields in json.

Thanks