tailscale_tailnet_key resource expires in terraform at the same time that the key expires in tailscale.

[rowanmoul]

Describe the bug
A clear and concise description of what the bug is.

The tailscale_tailnet_key resource expires in terraform at the same time that the key becomes invalid for use in the tailnet. On the surface this would seem to make sense, but it means terraform will not automatically re-generate the key prior to it's expiry, which can cause down time for nodes relying on the key.

To Reproduce
Steps to reproduce the behaviour:

1. Create a tailscale_tailnet_key with terraform (set a short expiry for the sake of testing)
2. Observe that terraform apply will not prompt to re-create the key until after expiry, at which point the key also becomes invalid on the tailnet.

Expected behaviour
A clear and concise description of what you expected to happen.

terraform apply should trigger the re-generation of the key if it is within some fraction of the exprity time. Alternatively, there should be a configuration setting to specify how long before expiry the terraform resource should become invalid.

Desktop (please complete the following information):

• OS: Linux
• Terraform Version: 1.10.2
• Provider Version: 0.17.2

Additional context
Add any other context about the problem here.

Calling this a bug might be a stretch, but this really does have the potential to cause down time (as it has in my company's setup).

[tomelliff]

I was just looking into this exact problem as we begin to rollout Tailscale to our organisation.

I spoke to @abrown152 about this and she recommended the following options:

The most common way to address this is preemptive key rotation, ensuring a valid key is always available before expiration. Below are some best practices that might help:

1. Preemptive Key Rotation:

• Instead of waiting for Terraform to detect an expired key, schedule a Lambda function or cron job to check key expiration in SSM and trigger a Terraform apply ahead of expiry.

• Alternatively, adjust Terraform to refresh the key proactively, so it never reaches expiry before a new one is available.

2. Using a Persistent Instance for Key Distribution:

• Some teams maintain a small, always-on instance that holds a valid auth key and distributes it to new ASG instances.

• This reduces reliance on Terraform timing and prevents authentication failures when a key expires unexpectedly.

3. OAuth Client vs. Ephemeral Auth Keys

• Giving instances an OAuth client to generate single-use keys introduces risk—OAuth credentials are long-lived, and any instance with access could create new devices indefinitely.

• The GitHub Action approach you referenced works by using an OAuth secret as an auth key, which simplifies provisioning but requires tight access controls to avoid exposure.

I think I'd rather keep this in Terraform and just make sure Terraform is refreshing ahead of time when it applies.

I think I'd call this a feature request and have something like this potential configuration for the resource:

resource "tailscale_tailnet_key" "sample_key" {
  reusable      = true
  ephemeral     = false
  preauthorized = true
  description   = "Sample key"

  recreate_if_invalid = "always"
  # keys last 7 days if not rotated before then but will be rotated 6 days ahead of expiry (so 1 day after creation)
  expiry                         = 60 * 60 * 24 * 7
  recreate_seconds_before_expiry = 60 * 60 * 24 * 6
}

Happy to add this if a maintainer (@oxtoacart and @mpminardi looking at recent contributors?) is accepting pull requests for it?

[mpminardi]

@tomelliff that sounds good to me! Feel free to add us on the PR when it is ready.

[oxtoacart]

@tomelliff Sounds good to me overall. To confirm, your plan would be to schedule a CRON job that runs apply periodically so that the provider has an opportunity to rotate the key based on the configured period?

recreate_seconds_before_expiry = 60 * 60 * 24 * 6

It might be easier to read if this was defined as the rotation period, so something like

rotation_period = 60 * 60 * 24 * 1

[rowanmoul]

So if I am understanding the above correctly, this will essentially do exactly what I suggested, and allow me to define a time less than the expiry after which terraform would rotate the key?
The job of making sure terraform actually runs during this time would be left to the user? (perhaps with CRON, as suggested above)
This sounds great to me as well.