Skip to content
This repository has been archived by the owner on May 25, 2022. It is now read-only.

Add resource for resource specific access #63

Closed
VipulZopSmart opened this issue Apr 8, 2022 · 4 comments
Closed

Add resource for resource specific access #63

VipulZopSmart opened this issue Apr 8, 2022 · 4 comments
Labels
new-feature-request a request to add a new feature/resource

Comments

@VipulZopSmart
Copy link

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?

@linouk23
Copy link
Collaborator

linouk23 commented Apr 8, 2022

👋 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 linouk23 added the new-feature-request a request to add a new feature/resource label Apr 8, 2022
@VipulZopSmart
Copy link
Author

@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?

@linouk23
Copy link
Collaborator

@VipulZopSmart created a separate issue for this question and answered it here. Let me know if it helps!

@linouk23
Copy link
Collaborator

linouk23 commented May 4, 2022

@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.

@linouk23 linouk23 closed this as completed May 4, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
new-feature-request a request to add a new feature/resource
Projects
None yet
Development

No branches or pull requests

2 participants