setting networking options for dedicated clusters

[Marcus-James-Adams]

Can you update the documentation to show how network options eg private endpoint would be set as part of the cluster creation

[linouk23]

Thanks for opening an issue @Marcus-James-Adams!

Could you explain your configuration in a bit more detail?

[sknop]

I have a similar question that might explain @Marcus-James-Adams's request:

When creating a dedicated cluster, we can choose between (depending on the cloud provider) up to 4 options:

• Public Interface
• VPC Peering
• Private Link
• Transit Gateway

The first 3 options can currently be provisioned yourself, but you will need Confluent support at the moment to set up TGW.

As I understand the current version of the Terraform provider, only the public interface is currently supported, since there is no option to define networking or to pass in the required parameters such as the AWS Account Number or the VPC identifier to create the link. Once the cluster is provisioned its networking cannot be changed anymore.

I am sure this is on the road map, but it would be great to give a hint on how and when the additional options will be made available.

[Marcus-James-Adams]

Here is a redacted example of our current setup
We use dedicated confluent cloud clusters that we only connect to via private networking from our azure network - I would therefore need to setup the confluent cloud side of the cluster networking as part or the cluster creation resource:

if the cluster_resource could support something like

resource "confluentcloud_kafka_cluster" "dedicated-cluster-with-networking" {
  display_name = "basic_kafka_cluster"
  availability = "MULTIZONE_ZONE"
  cloud        = "AZURE"
  region       = "uksouth"
  dedicated {
     cku = 2
     #########################################
    # Example of type of config that could be supplied - actual lines would depend on remote supplier and networking type
      networking {
        type= private_link
        remote_supplier = AZURE
        remote_subscription = XXXX-XXX-XXXX-XXXX
      }
      #########################################
   }

  environment {
    id = confluentcloud_environment.test-env.id
  }
}

NB it would also need to then output the required Private Link Service Aliases (or other networking type specific requirements) so that the terraform could create both parts of the private link at the same time.

[linouk23]

@sknop @Marcus-James-Adams unfortunately I can't commit to any specific date but we're actively working on adding Private Link options (and others) in one of our next releases.

[ConfluentSpencer]

Partial duplicate of this request:
#45

[linouk23]

@Marcus-James-Adams, @sknop we're very excited to let you know we've just published a new version of TF Provider that includes network / privatelink / peering resources 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 here, find a full list of changes here.

To be more specific, here's the example of a setup Dedicated Kafka cluster on AWS that is accessible via PrivateLink connections with authorization using RBAC: https://github.com/confluentinc/terraform-provider-confluent/tree/master/examples/configurations/dedicated-privatelink-aws-kafka-rbac