Closed sburns closed 5 years ago
Meta point, the feature request template could be improved, it looks an awful lot like the bug report template :)
I think this is interesting. Currently we support kms encrypted secrets, so it might be possible to extend the code we have for that to support secrets from external sources. Just bear in mind it might end up blocking your lambda from finishing until the secret can be retrieved. Alternatively, if you are using our log forwarder function or not using distribution metrics, then the API key isn't required. So that could be a potential workaround.
I've also got x-ray tracing enabled on some lambdas, I'm not entirely sure what further insights incorporating this layer would get me? The docs aren't super clear about this.
I’m also looking for this same functionality as we retrieve/decrypt secrets at runtime. Thanks!
@sburns @piohhmy Thanks for bringing up this use case to our attentions, sorry for the late reply. The API Key can be overridden on the fly, it's now documented in the README.
https://github.com/DataDog/datadog-lambda-layer-python/blob/master/README.md#environment-variables
Same issue. It's worth noting, the override at runtime appears to have to happen outside of your handler. Putting it inside the handler seems to happen way too late for the dd layer/api, but not late enough for users of the lambda vault extension.
(Sorry I wiped the ISSUE_TEMPLATE, this is just an idea and not a bug)
I would like to be able to configure the datadog layer at runtime with an API key that doesn't come from a Lambda environment variable. For example, I'd like to auth with Vault based on the Lambda's IAM role, read the API key and then instantiate the functionality in the lambda.
The pros of this approach include not storing secrets in the configuration of our lambdas, which we feel strongly about. Cons include a vault request per invocation, though in practice and if done at the right place, this will likely only happen on cold starts. However, this isn't really your problem: I just want the capability to provide an API key beyond the Lambda environment.
Perhaps, early in the handler module, we write to
os.environ["DD_API_KEY"]
but it's unclear to me how the environment changes from invocation to invocation, across warm or cold starts.I'd really prefer an explicit way to provide the token to the decorator. Maybe...
What do y'all think?