Problem description
When creating RabbitMQ credentials via the STACKIT Portal, it is possible to select a role for the credential, for example monitoring.
However, the Terraform resource stackit_rabbitmq_credential does not currently expose a parameter for configuring the role of the created credential.
It is therefore unclear whether credentials created via Terraform always receive the admin role, or whether there is another way to configure a different role via Terraform.
Could you please clarify whether it is currently possible to create RabbitMQ credentials with a role other than admin using the Terraform provider?
If this is currently not possible, we would like to request support for configuring the RabbitMQ credential role through Terraform.
Proposed solution
Add an optional role attribute to the stackit_rabbitmq_credential resource, equivalent to the role selection available when creating credentials through the STACKIT Portal.
This would allow users to create credentials with appropriate permissions instead of always relying on administrative credentials.
resource "stackit_rabbitmq_credential" "monitoring" {
project_id = var.project_id
region = var.region
instance_id = stackit_rabbitmq_instance.this.instance_id
role = "monitoring"
}Alternatively, if multiple roles are supported for a credential, the interface could be implemented as:
resource "stackit_rabbitmq_credential" "monitoring" {
project_id = var.project_id
region = var.region
instance_id = stackit_rabbitmq_instance.this.instance_id
roles = ["monitoring"]
}The exact schema should ideally reflect the underlying RabbitMQ API and the options currently available in the STACKIT Portal.
Alternative solutions (optional)
If role configuration is already possible through another Terraform resource or parameter, documenting the intended approach in the stackit_rabbitmq_credential resource documentation would solve the issue.
Additional information
The STACKIT Portal already provides a role selection when creating RabbitMQ credentials, including the monitoring role.
The Terraform resource currently exposes no equivalent role or roles parameter. This makes it difficult to provision RabbitMQ credentials consistently through Infrastructure as Code while following the principle of least privilege.
Problem description
When creating RabbitMQ credentials via the STACKIT Portal, it is possible to select a role for the credential, for example
monitoring.However, the Terraform resource
stackit_rabbitmq_credentialdoes not currently expose a parameter for configuring the role of the created credential.It is therefore unclear whether credentials created via Terraform always receive the
adminrole, or whether there is another way to configure a different role via Terraform.Could you please clarify whether it is currently possible to create RabbitMQ credentials with a role other than
adminusing the Terraform provider?If this is currently not possible, we would like to request support for configuring the RabbitMQ credential role through Terraform.
Proposed solution
Add an optional
roleattribute to thestackit_rabbitmq_credentialresource, equivalent to the role selection available when creating credentials through the STACKIT Portal.This would allow users to create credentials with appropriate permissions instead of always relying on administrative credentials.
Alternatively, if multiple roles are supported for a credential, the interface could be implemented as:
The exact schema should ideally reflect the underlying RabbitMQ API and the options currently available in the STACKIT Portal.
Alternative solutions (optional)
If role configuration is already possible through another Terraform resource or parameter, documenting the intended approach in the
stackit_rabbitmq_credentialresource documentation would solve the issue.Additional information
The STACKIT Portal already provides a role selection when creating RabbitMQ credentials, including the
monitoringrole.The Terraform resource currently exposes no equivalent
roleorrolesparameter. This makes it difficult to provision RabbitMQ credentials consistently through Infrastructure as Code while following the principle of least privilege.