How to create federated identities via Terraform without a circular dependency?

[chadlwilson]

I use this provider via GitHub actions to source control (almost) all configuration for a tailnet.

As a result, I need to

• initially manually set up a federated identity for use by the provider with a set of "config write" privileged permissions.
• this Terraform then creates another, lower privilege, federated identity for GHA workload federation (potentially via different repos/workflows). This identity only has auth_keys and device:core:read privileges for a given tag to support ephemeral device registration on the tailnet, similar to:

  resource "tailscale_federated_identity" "ephemeral_device_federated_identity" {
    description = "GitHub Actions Ephemeral Device Registration"
    scopes      = ["auth_keys", "devices:core:read"]
    tags        = ["tag:ephemeral"]
    issuer      = "https://token.actions.githubusercontent.com"
    subject     = "repo:my-org/my-repo:ref:refs/heads/master" # Only allow token to be generated off master
  }

The problem here is a chicken-vs-egg type of problem on permissions and tag:ephemeral.

1. I only seem to be able to use the "privileged" federated identity to create/edit the "low privilege" federated identity with the auth_keys scope if the Terraform identity also has the auth_keys scope.
2. Creating/editing this scope seems to require the relevant tag tag:ephemeral to already exist
3. Tags are part of Access Controls, and my access controls are supposed to be "externally managed" by Terraform.
4. So now the tag is both "needs to be manually created" and "should be externally controlled" at the same time.

flowchart LR
  D[Tailscale Terraform\nAccess Controls config creation]
  E[Tailscale Terraform\nFederated Identity]
  A[Tailscale low privilege\nEphemeral Device\nFederated Identity creation]
  B[auth_keys scope]
  C[tag:ephemeral created]


  A -->|requires| B
  A -->|requires| E
  B -->|requires| C
  C -->|requires| D
  D -->|requires| E
  E -->|requires| B

Loading

Perhaps this is just intrinsic to the permissions model and not specific to the provider; but I wonder if there are scopes/techniques available to break the circular dependency on creation of the tag:ephemeral tag here while still using two different federated identities.

tailscale_federated_identity.ephemeral_device_federated_identity: Modifying... [id=***]
╷
│ Error: Failed to update federated identity
│ 
│   with tailscale_federated_identity.ephemeral_device_federated_identity,
│   on tailscale.tf line 55, in resource "tailscale_federated_identity" "ephemeral_device_federated_identity":
│   55: resource "tailscale_federated_identity" "ephemeral_device_federated_identity" {
│ 
│ actor cannot set scopes: [auth_keys devices:core:read] (403)
╵

Ideally if intending to use Terraform to manage ones ACLs, and other federated identities - it'd be better to not have this circular dependency on tag creation via the auth_keys scope ... somehow. Is there a way?

[chadlwilson]

This is possibly broadly related to tailscale/tailscale#12402 and #437 . I have not specified tag owners here, if that's relevant.

[neinkeinkaffee]

Hi @chadlwilson, thanks for raising this! The tag for the parent federated identity is indeed a bootstrap dependency, unless it gets granted the “all” scope, which gives it access to all tags.

Unless I’m mistaken, there isn’t a direct way to cut the dependency cycle you describe without “all”. One idea could be to coordinate the work between two federated identities, one that manages the policy file (including tags and their owners), and one with a tag that can create other federated identities (with any tags that it owns).

I’ve tried to recreate your scenario and play around with it to see if I’m missing something. Meanwhile, we’d be very open to hearing any ideas that might help make this better!

[chadlwilson]

The all scope is the uber-permissions one, right? Too scary to give to terraform automation. 😅 I wanted to limit what the automation can do as much as possible, partly to be clear about features used, partly for security. Not sure if that actually makes sense though, as obviously it has to be relatively privileged.

Currently my bootstrap instructions are to manually create an identity for terraform to use like this (expressed as terraform for clarity, but done with click ops)

description = "GitHub Actions Config Write Identity"
scopes      = ["dns", "policy_file", "devices:core:read", "devices:posture_attributes", "auth_keys", "federated_keys", "account_settings", "feature_settings", "networking_settings"]
tags        = ["tag:ephemeral"] # requires manual pre-creation of tag due to https://github.com/tailscale/terraform-provider-tailscale/issues/677
issuer      = "https://token.actions.githubusercontent.com"
subject     = "repo:myorg/myrepo:*" # WARNING: allows GHA pull request builds to assume role also, required for terraform plan (but not intended to apply)

If there was a way to specify “all tags” for this bootstrap identity that then allows it to subsequently create another federated identity with a specific tag - that would be sufficient, but I am not sure if that is within the permissions model or has other side effects. Either via that “tags” setting (tags = [“*”] / tags = [“tag:*”] etc), or via a special scope (e.g auth_keys:tags_all? Or possibly something clearly scoped only to what variants of other federated identities this identity can create, such as federated_keys:tags_all) - whatever makes sense and minimises chance of confused deputy problems or misconfig.

I could not find a way to express this via the UI, but that doesn’t mean it doesn’t exist :)

PS: 👋 from one ex Twer to another 😏