Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[terraform-ibm-secrets-manager] Scope KMS policy to the exact KMS key #223

Open
ocofaigh opened this issue Nov 1, 2024 · 5 comments
Open
Assignees

Comments

@ocofaigh
Copy link
Member

ocofaigh commented Nov 1, 2024

The policy here and here can be updated to scope it to the exact KMS key. For an example of the syntax, see terraform-ibm-modules/terraform-ibm-cos#764

@arya-girish-k
Copy link
Contributor

cc : @SarikaSinha

@arya-girish-k
Copy link
Contributor

As per the document authorization policy gets created at Instance level.
Currently while scoping KMS policy to the exact KMS key ,policy gets created but provisioning of secret manager instance is failing .As per the discussion scoping authorization policy at key level is not allowed
Hence closing the issue.

@ocofaigh
Copy link
Member Author

I think there is some confusion here. The auth policy has to be created before the instance is created. Therefor the auth policy cannot be scoped the secrets manager instance. However it can be scoped to the KMS key. Re-opening this issue to discuss further

@ocofaigh ocofaigh reopened this Jan 13, 2025
@ocofaigh
Copy link
Member Author

It looks like when scoped to exact key, it fails with:

│ Error: [ERROR] Error when creating resource instance: Please contact the Service Provider for this error. [422, Unprocessable Entity] An IAM service authorization policy is missing between your key management service and Secrets Manager. To provision the service with customer managed encryption, authorization must be granted to all instances of Secrets Manager in your account. After provisioning, you can choose to create a more granular policy. with resp code: {
│   "StatusCode": 422,
│   "Headers": {
│     "Cache-Control": [
│       "max-age=0, no-cache, no-store"

In my opinion this is a bug on the service so I have created an enhancement request with the Secrets Manager service to support this so its consistent with other services.

@ocofaigh
Copy link
Member Author

Secrets Manager made updates to support this, so we should no longer be blocked

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants