v1.8.2

Two fixes for issues reported against 1.8.1. No state migration is needed for this release.

Fixed

• secureworkload_port can now create an ANY service, meaning all protocols and all ports. Leave start_port, end_port and proto out of the resource:

  resource "secureworkload_port" "any" {
    policy_id = secureworkload_policies.policy1.id
  }

  Ports cannot be used with a wildcard protocol, so if you set start_port and end_port you must also set proto, and if you set one port you must set both. Both cases are now reported before the request is sent instead of coming back as an error from the cluster. (#53)

• secureworkload_enforce can now manage a workspace that is already enforcing. Before this the apply failed with version pN is already enforced, and there was no way to import the existing enforcement, so the only option was to disable enforcement first and leave the workspace unenforced until the next apply. (#54)

Import

Enforcement that is already running on a workspace can now be brought into Terraform. The ID is the workspace ID:

terraform import secureworkload_enforce.enforced <workspace-id>

Importing only reads the workspace, so the enforcement stays as it is.

Full Changelog: v1.8.1...v1.8.2

v1.8.1

Bug fix release covering the four open issues, plus some problems found while testing them.

Upgrading

Back up your state file before you upgrade.

secureworkload_port used to store the ID of the parent policy instead of the ID of the service port, and secureworkload_enforce used to store the enforcement epoch instead of the workspace ID. Both are corrected here, and existing state is migrated for you the first time you run a plan or an apply.

The migration only goes one way. After you apply with 1.8.1, version 1.8.0 will not read the state of those two resources any more and reports Resource instance managed by newer provider version. Restoring a state backup is the only way back.

Run terraform plan first. A plan does not write state, so you can check the result before committing to it. For ports and enforcement you should see no changes.

Fixed

• secureworkload_port could not be deleted. The delete request was built but never sent, so removing or changing a port left the old one in place on the policy. Ports also all shared the ID of their parent policy, so Terraform could not tell two ports apart. (#41)
• Enforcement never moved to newer policy versions. There is a new track_latest_version option that enforces the latest version of the workspace on each apply, so you no longer have to look the version up and put it in your config. Changing version now re-enforces in place instead of disabling and re-enabling. (#35)
• Resources were destroyed and recreated on every run. The main cause was the policy resource reading policy_action from the API response, which the API returns as action, so the value came back empty and Terraform planned a replacement every time. Replacing the policy then took its ports with it. (#36)
• Requests that fail with HTTP 429 or a 5xx error are retried with a backoff, and Retry-After is honoured when the API sends it. Number of attempts can be set with max_retries. (#40)
• API calls now have a timeout, set with http_timeout and defaulting to 120 seconds. Before this the provider used a client with no timeout at all, so a request could hang forever if the cluster stopped responding.

Also fixed

• secureworkload_role can change name and description without being recreated. Before, changing either failed with doesnt support update and the plan could not be applied at all.
• secureworkload_workspace can change name, description and primary without being recreated.
• secureworkload_scope no longer shows a change to policy_priority on every plan. The API does not support changing it on an existing scope, so it now forces a new scope instead of reporting success and doing nothing.
• secureworkload_scope reads sub_type back from the API, so a change made outside Terraform is detected.
• secureworkload_cluster and secureworkload_filter read their query back from short_query rather than the expanded query, which never matched what you wrote and caused the resource to be replaced on every plan.
• Reads no longer fail when a resource has been deleted outside Terraform. The resource is removed from state instead.
• secureworkload_user no longer sends empty entries in role_ids.

Known limitations

• Nested cluster, filter and policy blocks inside secureworkload_workspace still force the workspace to be recreated. The API only accepts name, primary and description on an update, so there is no way to change them in place. Use the separate secureworkload_cluster, secureworkload_filter and secureworkload_policies resources instead. See #52.
• A secureworkload_workspace with a nested cluster block cannot be created. This also affects 1.8.0. See #51.
• The 429 handling has not been confirmed against a cluster that is actually rate limiting. See #40.

Full Changelog: v1.8.0...v1.8.1

v1.8.0

What's Changed

• documentation changes by @kadadhic in #38

Full Changelog: v1.7.7...v1.8.0

v1.7.7

What's Changed

• fixing documentation bug by @kadadhic in #37

Full Changelog: v1.7.6...v1.7.7

v1.7.6

What's Changed

• updating workflow by @kadadhic in #34

Full Changelog: v1.7.5...v1.7.6

v1.7.5

What's Changed

• updating workflow by @kadadhic in #33

Full Changelog: v1.7.4...v1.7.5

v1.7.4

What's Changed

• updating workflow by @kadadhic in #32

Full Changelog: v1.7.3...v1.7.4

v1.7.3

What's Changed

• updating workflow by @kadadhic in #31

Full Changelog: v1.7.2...v1.7.3

v1.7.2

What's Changed

• updating workflow by @kadadhic in #30

Full Changelog: v1.7.1...v1.7.2

v1.7.1

What's Changed

• fixing bug by @kadadhic in #29

Full Changelog: v1.7.0...v1.7.1