Create ACL bindings for kafka

[jackdelahunt]

This pr adds the functionality of creating ACL bindings for any kafka instance, it adds more options within the kafka resource to achieve this. It also adds a acl resource to use with the need for the kafka resource to be created at the same time.

Verify

Terraform config (main.tf)

terraform {
  required_providers {
    rhoas = {
      source  = "registry.terraform.io/redhat-developer/rhoas"
      version = "0.1.0"
    }
  }
}

provider "rhoas" {
    offline_token = "..."
}
resource "rhoas_service_account" "srvcaccnt" {
  name = "service_account"
}

resource "rhoas_kafka" "instance" {
  name = "instance"
  acl = [
    {
      principal = rhoas_service_account.srvcaccnt.client_id,
      resource_type = "TOPIC",
      resource_name = "topic-1",
      pattern_type = "LITERAL",
      operation_type = "ALL",
      permission_type = "ALLOW",
    },
  ]
}

resource "rhoas_topic" "topic-1" {
  kafka_id = rhoas_kafka.instance.id
  name = "topic-1"
  partitions = 1
}

resource "rhoas_topic" "topic-2" {
  kafka_id = rhoas_kafka.instance.id
  name = "topic-2"
  partitions = 1
}

resource "rhoas_acl" "acl" {
  kafka_id = rhoas_kafka.instance.id
  principal = rhoas_service_account.srvcaccnt.client_id
  resource_type = "TOPIC"
  resource_name = "topic-2"
  pattern_type = "LITERAL"
  operation_type = "ALL"
  permission_type = "ALLOW"
}

Commands

• make install
• terraform init
• terraform apply

Expected Results

• New kafka created named "instance"
• Kafka has 2 topics named "topic-1" and "topic-2"
• New service account created called "service_account" (description in UI)
• Service account has access to all actions for these to topics in the kafka

[dimakis]

Looks good, I just have a couple of comments / questions

[dimakis]

is there any validation to check if the user passes the principal in as User:blah or user:blah or user: blah, you get my point, in the TF script?
in those cases wouldn't the principal come out as User:User:blah ?

[jackdelahunt]

I think we just need to set a standard for these inputs and consider anything outside of that not valid. If we define that the user must enter the client_id or user id in the principal field then starting it with User: is automatically not supported.

[dimakis]

my preference here would be to have a little validation around the prepending of User: here but that is just my own opinion

[jackdelahunt]

I would normally agree but... then doing what I am in this pr not impossible but a mess, I am using a service account client id as the principle but I would need to prepend it with User:, this afaik is possible but a pain in terraform

[jackdelahunt]

now i have realized doing this changing of values can cause issues with terraform syncing after create, i avoided it in this pr in a hacky way but something to think about for the future.

[dimakis]

great changes

[dimakis]

LGTM,
Great work @jackdelahunt

[wtrocki]

Looks good. Sorry for late review