v3.0.0-beta5

[OPAL-10448] Implement state upgraders for opal_group and opal_resour…

…ce for version 0 -> version 1 (#51)

* Implement state upgrades for v0 -> v1 for opal_group and opal_resource

v3.0.0-beta4

opal_group

• message_channel_ids now required (can provide empty list [])
• on_call_schedule_ids now required (can provide empty list [])
• visibility now required
• audit_message_channel => message_channel_ids (List of string ids)
• on_call_schedule => on_call_schedule_ids (List of string ids)
• visibility_group => visibility_group_ids (List of string ids)
• manage_resources => removed in favor of optional declaration of group <> resource relationship
• resource => moved to separate resource opal_group_resource_list
• request_configuration => request_configurations. List of configurations with at minimum a default configuration. Optionally specify extra configurations to apply to targeted groups

opal_owner

• user (Block list) => user_ids (List of strings)
• user_ids required instead of optional

opal_resource

• admin_owner_id now optional
• visibility now required
• visibility_group => visibility_group_ids (List of string ids)
• request_configurations now required
• request_configuration => request_configurations. List of configurations with at minimum a default configuration. Optionally specify extra configurations to apply to targeted groups

New capabilities

opal_resources_users

• Grant access to a Resource for a specific User

opal_group_tag

• Associate a Group and a Tag

opal_resource_tag

• Associate a Resource and a Tag

opal_tag

• Create an Opal tag to use with other Opal objects

opal_tag_user

• Associate a User and a Tag

v3.0.0-beta3

Full Changelog: v3.0.0-beta1...v3.0.0-beta3

v3.0.0-beta1

Full Changelog: v2.0.2...v3.0.0-beta1

v2.0.2

What's Changed

• [OPAL-9309] Use TypeSet for visibility_groups and group_ids by @andrewsy-opal in #36

Full Changelog: v2.0.1...v2.0.2

v2.0.1

What's Changed

• [OPAL-8558] Fix request configuration reading by @andrewsy-opal in #34

Full Changelog: v2.0.0...v2.0.1

v2.0.0

New Changes in v2.0.0 🎉

In v2.0.0 of Terraform Provider Opal, we've introduced the ability to set complex and conditional request configurations. With the new request_configuration blocks, you can set multiple request configurations and control their priority. This is a major version bump and contains breaking changes.

Using Multiple request_configuration Blocks

Starting with v2.0.0, you can specify multiple request_configuration blocks within your opal_resource and opal_group blocks. The priority of these configurations is controlled by the priority field, which defaults to 0. The configuration with priority 0 is the default and applies to everyone who doesn't satisfy conditions defined in other request_configuration blocks.

Conditions

The conditions in request_configuration blocks are set using the group_ids field. If a user is part of the group specified by group_ids, then their request will follow the settings in that request_configuration block.

Constraints:

• Configurations with priority = 0 must have group_ids defined.
• Configurations with priority > 0 must have a non-empty group_ids defined.
• Currently, each request_configuration block can only support one group_id at a time.

Example

resource "opal_resource" "my_resource" {
  request_configuration {
    priority = 0 // not required since it defaults to 0
    auto_approval = true
  }
  request_configuration {
    priority = 1
    group_ids = ["bd8a3b83-2bac-410d-af5c-6c67263077ea"]
    require_mfa_to_request = true
    reviewer_stage {
      require_manager_approval = true
      reviewer {
        id = opal_owner.security.id
      }
    }
  }
}

In this example, users who are part of **bd8a3b83-2bac-410d-af5c-6c67263077ea** will be required to use multi-factor authentication to request resources, while all other users will have their requests auto-approved.

Manual Migration Guide 💪

We created a script to automatically migrate **.tf** files, but if you prefer to manually update your Terraform files, follow these steps:

Steps to Migrate Manually

1. Identify Fields to Wrap: Look for the following fields in your opal_resource and opal_group blocks:
   • auto_approval
   • require_mfa_to_request
   • require_support_ticket
   • max_duration
   • recommended_duration
   • request_template_id
   • is_requestable
2. Wrap Fields: Wrap these fields within a new block named request_configuration.
3. Indent Properly: Ensure proper indentation within the new request_configuration block.

Example

Before Migration

resource "opal_resource" "my_resource" {
  auto_approval = true
  require_mfa_to_request = false
  reviewer_stage {
    require_manager_approval = true
  }
  reviewer_stage {
    reviewer {
      id = opal_owner.security.id
    }
  }
}

After Manual Migration

resource "opal_resource" "my_resource" {
  request_configuration {
    auto_approval = true
    require_mfa_to_request = false
    reviewer_stage {
      require_manager_approval = true
    }
    reviewer_stage {
      reviewer {
        id = opal_owner.security.id
      }
    }
  }
}

After manually migrating your files, run terraform apply to ensure they are compatible with Terraform Provider Opal v2.0.0.

Automated Migration Using migration_script.py 🤖

If you prefer an automated approach, our migration_script.py can facilitate the migration process. This script will wrap the necessary fields within your Terraform files in a new request_configuration block to make them compatible with Terraform Provider Opal v2.0.0.

Script Constraints ❗️

Before running the script, please note that it is recommended that your .tf files follow the constraints below:

• No Multiline Comments: The script cannot parse opal_resource and opal_group blocks that contain multiline comments.
• No Multiline Strings: The script cannot parse blocks that contain multiline strings.
• Also, it is recommended that reviewer_stage blocks are properly formatted:
  • Opening brackets should be on the same line as the block name.
  • Closing brackets should be on their own line.
• If you insist on running the migration script without following these constraints, at the very least, do not add the characters **{** and **}** within multiline comments or strings that are inside **opal_resource** or **opal_group** blocks, but use at your own risk. ⚠️

Steps to Use the Migration Script

1. Download the Script: Copy scripts/migration_script.py and place it in the directory containing your .tf files.
2. Run the Script: Open your terminal and execute python migration_script.py. The script will scan your .tf files and generate new versions with the necessary changes in a directory called migration_autogen.
3. Review the Changes: Open the migration_autogen directory and carefully review the newly generated .tf files to ensure they meet the required standards and constraints.
4. Test: Before applying the changes to your environment, run terraform apply on the new .tf files to ensure they are compatible with Terraform Provider Opal v2.0.0.

By adhering to these guidelines and steps, your migration to Terraform Provider Opal v2.0.0 should be a smooth process.

v1.0.9

What's Changed

• Make group remote_info computed by @jan-opal in #32

Full Changelog: v1.0.7...v1.0.9

v1.0.8

What's Changed

• Make token argument optional (#26)
• Add resource creation support for GCP, Salesforce, and Pagerduty (#28)
• Add data source for resources and groups (#27)
• Allow using owners with / in their name (#31)
• Read remote info into terraform (#30)

Full Changelog: v1.0.6...v1.0.8

v1.0.6

What's Changed

• [OPAL-7906] Support AWS accounts in Terraform by @andrewsy-opal in #24

Full Changelog: v1.0.5...v1.0.6