Create a new `twingate_resource_access` resource

[alexmensch]

New functionality

Arguments

• (Required) resource_ids of type list(string)
  • List of resource ids obtained from the twingate_resource or twingate_resources data sources.
• (Optional) group_ids of type list(string)
  • List of resource ids obtained from the twingate_group or twingate_groups data sources.
• (Optional) service_account_ids of type list(string)
  • List of resource ids from service account resources
• (Optional) authoritative of type bool
  • Default: true
    • When true, the assignments in this resource will override all existing assignments.
    • When false, the assignments in this resource will be added between resources.

Behavior

• Although both group_ids and service_account_ids are individually optional, at least one must be specified for the assignment to be valid.

Example usage

# Assigns access to `twingate_resource.internal_resources.id`
#   to both a service account and group. Does not override any existing assignments.
resource "twingate_resource_access" "internal" {
    resource_ids = toset([twingate_resource.internal_resources.id])
    service_account_ids = toset([twingate_service_account.github_actions_prod.id])
        group_ids = toset([data.twingate_groups.devops.id])
        authoritative = false
}

data "twingate_groups" "devops" {
        name = "DevOps"
}

resource "twingate_service_account" "github_actions_prod" {
    name = "Github Actions PROD"
}

resource "twingate_remote_network" "aws" {
        name = "AWS"
}

resource "twingate_resource" "internal_resources" {
        name = "All internal resources"
        address = "*.internal.int"
        remote_network_id = twingate_remote_network.aws.id
        protocols {
          allow_icmp = true
          tcp  {
            policy = "RESTRICTED"
            ports = ["80", "82-83"]
          }
          udp {
            policy = "ALLOW_ALL"
          }
       }
}

[alexmensch]

Notes

• This resource will be extended very soon with an additional policy argument once we implement #62. This will also allow assigning access to a resource with different policies to different groups and/or services.
• In the future (dependent on core product improvements as this is not currently natively supported) we will also be adding individual user assignments to this resource so that users can be individually assigned to Twingate Resources.
• Since this functionality conflicts with the existing group assignment in the twingate_resource resource, we'll be deprecating that functionality as per #242. It will still be available, but any conflicts will generate an error. We encourage moving to this new assignment resource.

[tjstansell]

I'm not sure I understand how the authoritative flag on this will work. Does it enforce at the resource side, the group side, or both? As in, if I have

resource "twingate_resource_access" "one" {
    authoritative = true
    resource_ids = [resource.twingate_resource.a.id, resource.twingate_resource.b.id]
    group_ids = [resource.twingate_group.eng.id, resource.twingate_group.sec.id]
}
resource "twingate_resource_access" "two" {
    authoritative = true
    resource_ids = [resource.twingate_resource.c.id, resource.twingate_resource.d.id]
    group_ids = [resource.twingate_group.hr.id, resource.twingate_group.sec.id]
}

what's expected to happen? i would expect:

• eng would get access to resources a and b
• sec would get access to resources a, b, c, and d
• hr would get access to resources c and d

But would the authoritative flag end up causing the two to fight over which resources the sec group has access to? Would there be a way to specify authoritatively which resources a specific group has access to? or does the authoritative flag only apply to the resources?

Curious here if you're trying to make this flexible enough for folks to choose if they want absolute control at the resource side (who has access to that resource), the group side (which resources that group has access to), or neither (individual permissions managed by terraform, but extras manually done via the UI are also allowed).

[tjstansell]

IMO, I think you could solve this by adding support for access {} blocks in the resource and group resources to maintain exclusive control from that perspective:

resource "twingate_resource" "a" {
  address = ...
  name = ...
  access {
    group_ids = [...]
    policy = ...
  }
  access {
    group_ids = [...]
    policy = ...
  }
}

which would enforce this from the resource perspective. The same thing could be done from the group side. If I'm missing something with how the authoritative flag will work, I'm all ears. I think you had mentioned you were modeling this after a different provider resource that worked this way. Perhaps if I saw that, it would more sense?

Personally, I also think it's much clearer to read the terraform code and understand who has access to a resource if you supported this type of thing (where it's all defined within the twingate_resource itself).

[tjstansell]

I'm used to the aws iam role model so it would work similar to that.

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/iam_role#example-of-exclusive-inline-policies

[alexmensch]

After some more debate on this, we've finalized on a new approach that will make access assignments directly on the twingate_resource resource. For now, we are going to table the approach of having a separate Terraform resource for access assignments until we have additional complexity in the policy engine that will justify this.

You can continue to follow this work in issue #245