terraform-provider-datadog
terraform-provider-datadog copied to clipboard
DataDog
[datadog_application_key] Manage application key scopes
Continuing the issue from #1711 by @jorhett here due to repository permissions
Continuing the issue from https://github.com/DataDog/terraform-provider-datadog/pull/1711 by @jorhett here due to repository permissions
You work for datadog, why couldn't you push to this PR? 🤔
Thank you.
As enterprise customer, the feature is necessary for us. We look forward to getting this feature as soon as possible
DD support pointed out this PR. I think it's pretty close to what we're needing. Basically, the datadog agent cookbook needs an application key, but at the moment we can't generate these keys in TF with limited scope/permissions since they automatically get the owner (ie the terraform user) permission.
The cookbook appears to use this key to mute Windows alerts during the agent install. However, any application key generated by TF (because of the inheritance) has far more permissions than this very narrow need.
Would be great to get this functionality merged. I agree with everything @jorhett has said in this PR and #1711.
I'd love to have this.
workaround
- create custom role with the scope
- create service user with that role
- create service user application key (which inherits the owner's role)
Any updates on this PR @nkzou? It's been in the Open state since March. I don't think the code should be too different, considering the functionalities of application key scopes have not changed, so after resolving conflicts can we merge this?
Unfortunately this PR is blocked due to an unwanted interaction with the backend API. Permissions will often get split on the backend to allow for more granular auth control, but this causes drift with the Terraform configuration and results in unintentional revoking of permissions.
The team is aware of this issue but we don’t have any updates to share for when this may be resolved. Please contact Datadog Support to submit a feature request if this functionality is important for you.
The team is aware of this issue but we don’t have any updates to share for when this may be resolved. Please contact Datadog Support to submit a feature request if this functionality is important for you.
We did that back in May. Support pointed us specifically in the direction of this PR. I'll re-open that old ticket if it can get this going again. I don't mind that support provided this PR number. On the contrary, I appreciate it because a more in depth technical discussion with a broader group of interested parties can have a discussion.
Not super keen on what's starting to feel a little like a run-around -- support ticket -> PR -> nah, go back to support. We're here - following, discussing, asking for updates on this PR specifically because the functionality is important to us.
Hi @nkzou, what is the status on this PR? Are we going to need to escalate this to Datadog Support?
Hi @nkzou, what is the status on this PR? Are we going to need to escalate this to Datadog Support?
It's been about a year since the first ticket, but that's a good suggestion @aidanmelen. I've opened now a third support ticket for this issue. I don't think it's the fault of @nkzou or anyone working on the provider. I don't mean to be disrespectful if any of them read this, but the DD API folks seem to have a tendency to do their own thing. The API gets changed (usually for the better) but that doesn't get communicated to folks managing the TF provider, breaking provider in subtle ways that have cost energy wasted troubleshooting thinking we've done something wrong with our TF code.
We're asking for a reasonable security improvement to be allowed to narrow the scope of the API keys, which needs the support of the API but getting run around.
The point is that from the outside of DD it looks like the two groups within Datadog, API developers and API consumers - like the Terraform provider, - are disconnected from each other.
I was shocked to learn that this functionality is not implemented. Even more shocked that it's been 1.5 years open. I submitted Datadog Support request #1723952 in the hopes of doing my part to expedite this. In my opinion this functionality should be added to both datadog_application_key and datadog_service_account_application_key. I know this pull request has only implemented datadog_application_key but I don't want to forget about datadog_service_account_application_key.
Hello,
This is a feature request to allow creating scopes on an application key using Terraform/Pulumi.
The Datadog API already supports this functionality as documented here: https://docs.datadoghq.com/api/latest/service-accounts/#create-an-application-key-for-this-service-account
There's a GitHub pull request adding support for this that's been open for 1.5 years: https://github.com/DataDog/terraform-provider-datadog/pull/1723
Without this functionality operators cannot successfully manage their application keys via standardized tooling, further fragmenting the already complex Datadog authentication and authorization system. Operators must instead manually manage application keys which can lead to human error and security vulnerabilities or fork the Terraform/Pulumi provider which can lead to configuration drift.
Please let us know if there's anything we can do to expedite this feature request as it's a relatively small lift that, respectfully, should not take 1.5 years to implement. Thank you!
