Closed VipulZopSmart closed 2 years ago
👋 thanks for opening an issue @VipulZopSmart! I feel like your question is more about when we'll add a support for api_key
resource that will support Kafka clusters (see #4 for tracking), Schema Registry, and ksqlDB.
giving access to service account for particular operations(ACL) to the specific cluster(or topic)
that's something that role binding resource can help with actually.
To give you a very short example, here's how it will look like when we release confluentcloud_api_key
resource:
resource "confluentcloud_service_account" "app-manager" {
display_name = "app-manager"
description = "Service account to manage 'inventory' Kafka cluster"
}
resource "confluentcloud_role_binding" "app-manager-kafka-cluster-admin" {
principal = "User:${confluentcloud_service_account.app-manager.id}"
role_name = "CloudClusterAdmin"
crn_pattern = confluentcloud_kafka_cluster.dedicated.rbac_crn
}
resource "confluentcloud_api_key" "app-manager-kafka-api-key" {
display_name = "app-manager-kafka-api-key"
description = "Kafka API Key that is owned by 'app-manager' service account"
owner {
id = confluentcloud_service_account.app-manager.id
api_version = confluentcloud_service_account.app-manager.api_version
kind = confluentcloud_service_account.app-manager.kind
}
managed_resource {
id = confluentcloud_kafka_cluster.dedicated.id
api_version = confluentcloud_kafka_cluster.dedicated.api_version
kind = confluentcloud_kafka_cluster.dedicated.kind
environment {
id = confluentcloud_environment.staging.id
}
}
}
or
resource "confluentcloud_kafka_acl" "app-producer-write-to-topic" {
kafka_cluster = confluentcloud_kafka_cluster.dedicated.id
resource_type = "TOPIC"
resource_name = confluentcloud_kafka_topic.orders.topic_name
pattern_type = "LITERAL"
principal = "User:${confluentcloud_service_account.app-producer.id}"
operation = "WRITE"
permission = "ALLOW"
http_endpoint = confluentcloud_kafka_cluster.dedicated.http_endpoint
credentials {
key = confluentcloud_api_key.app-manager-kafka-api-key.id
secret = confluentcloud_api_key.app-manager-kafka-api-key.secret
}
}
resource "confluentcloud_service_account" "app-producer" {
display_name = "app-producer"
description = "Service account to produce to 'orders' topic of 'inventory' Kafka cluster"
}
resource "confluentcloud_api_key" "app-producer-kafka-api-key" {
display_name = "app-producer-kafka-api-key"
description = "Kafka API Key that is owned by 'app-producer' service account"
owner {
id = confluentcloud_service_account.app-producer.id
api_version = confluentcloud_service_account.app-producer.api_version
kind = confluentcloud_service_account.app-producer.kind
}
managed_resource {
id = confluentcloud_kafka_cluster.dedicated.id
api_version = confluentcloud_kafka_cluster.dedicated.api_version
kind = confluentcloud_kafka_cluster.dedicated.kind
environment {
id = confluentcloud_environment.staging.id
}
}
}
for now we'll only support KafkaCluster
as a managed resource but adding ksqlDB / SR is on our roadmap too (it might be a good idea to create separate issues to track these).
Let me know if that makes sense.
@linouk23, i've a query so i've created two keys(for service account having ACLs) to particular topic(say sample-topic), one key for publisher having WRITE operation, one for consumer having READ operation, after that i tried to publish messages from publisher app(it got published) but at the consumer side i'm not able to consume those messages(tried some other operations also like DESCRIBE). What could be the issue?
@VipulZopSmart created a separate issue for this question and answered it here. Let me know if it helps!
@VipulZopSmart we're very excited to let you know we've just published a new version of TF Provider that includes api_key
resource among other very exciting improvements: it enables fully automated provisioning of our key Kafka workflows (see the demo) with no more manual intervention and makes it our biggest and most impactful release.
The only gotcha we've renamed it from confluentinc/confluentcloud
to confluentinc/confluent
but we published a migration guide so it should be fairly straightforward. The existing confluentinc/confluentcloud
will be deprecated soon so we'd recommend switching as soon as possible.
New confluentinc/confluent
provider also includes a lot of sample configurations so you won't need to write them from scratch. You can find them out here, find a full list of changes here.
Hi @linouk23,
For the resource specific keys, i.e giving access to service account for particular operations(ACL) to the specific cluster(or topic), i think that is also not present in the terraform yet. Could you please confirm when can we expect this resource would be coming out in future?