Add new bastionzero_db_target resource

[ymarcus93]

• Add support for managing Db targets with the new bastionzero_db_target resource
• Add bastionzero_supported_database_configs data source which retrieves list of supported database auth configurations
• End-to-end tests
• Update docs

[asamborski]

We should modify this to say "Linux target" or something similar. We shouldn't refer to targets any longer by "bzero" since we separated out targets vs. agents.

[asamborski]

Find the Linux target

[asamborski]

Gets a little wonky here since we still call it a proxy target, but in theory I think it should be proxy agent... Maybe we can just say "Linux, Windows, or Kubernetes target"

[asamborski]

Same comment as above - "Find Linux target"

[asamborski]

Find Linux target

[ymarcus93]

This data source list can include Linux or Windows targets, so I've changed it to that. Lmk if that's okay.

[asamborski]

Let's add in here that for GCP, we recommend using value 0

[asamborski]

Windows, Linux, or Kubernetes targets

[asamborski]

Linux, Windows, or Kubernetes targets

[asamborski]

Linux, Windows, or Kubernetes target

[lipmas]

I definitely missed the reason for transitioning a bunch of tests to use environment policy objects in this PR- what was the reason for doing this?

[ymarcus93]

In the policy TF acctests, we need policies.Environment object. But honestly, looking at this code again I could actually get away with just one func and re-map from environments.Envrionment to policies.Environment where needed

[lipmas]

Finished manually testing the db target resource and looking good!

[lipmas]

Actually one more question about this attribute of the resource. Since this is just a "computed" value returned from the api and could be constantly changing and shows up in the tf plan when other changes are made does it really make sense to include it in the resource? What advanatges are there for having it in the resource? Just to use as an output value? Same argument could be made for the status, region attributes as well

Terraform will perform the following actions:

  # bastionzero_db_target.example will be updated in-place
  ~ resource "bastionzero_db_target" "example" {
      ~ agent_public_key               = "n/a" -> (known after apply)
      ~ agent_version                  = "n/a" -> (known after apply)
        id                             = "3eb923b8-ccf0-4457-8f07-46a5becdac2b"
      + last_agent_update              = (known after apply)
        name                           = "tf-example-psql-db-target"
      - proxy_environment_id           = "312d0fc0-5679-4a47-9f5a-af4884d3bee5" -> null
      + proxy_target_id                = "b0c0a199-8e74-4a05-ac07-e904a33a0e6f"
      ~ region                         = "n/a" -> (known after apply)
      ~ status                         = "Online" -> (known after apply)
        # (5 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

[ymarcus93]

Since this is just a "computed" value returned from the api and could be constantly changing and shows up in the tf plan when other changes are made

Just to reiterate what I think you're talking about above...It will only show (known after apply) like in the example you posted when one of the bastionzero_db_target resource's configurable attributes is modified. If you refer to one of the resource's read-only/computed attributes in an output or somewhere else (like another resource or data source) without changing the resource's configurable attributes, it should show the refreshed value (if changed). Here is an example when I tried to restart the backing agent of a db target (using zli) with some outputs that refer to last_agent_update and status (outputs start with foo below) and then running terraform apply:

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply" which may have affected this plan:

  # bastionzero_db_target.example has changed
  ~ resource "bastionzero_db_target" "example" {
        id                             = "c7e9f2c5-e078-4699-94a5-f2ac20108b40"
      ~ last_agent_update              = "2023-11-15T19:29:04Z" -> "2023-11-15T19:34:28Z"
        name                           = "example-splitcert-db-target"
      ~ status                         = "Online" -> "Restarting"
        # (9 unchanged attributes hidden)
    }


Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.

─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Changes to Outputs:
  ~ foo_status                      = "Online" -> "Restarting"
  ~ foo_update                      = "2023-11-15T19:29:04Z" -> "2023-11-15T19:34:28Z"

You can apply this plan to save these new output values to the Terraform state, without changing any real infrastructure.

does it really make sense to include it in the resource?

All of these attributes: status, last_agent_update, region, agent_public_key, etc. are part of the CRUD BastionZero API responses and Hashicorp recommends making the TF resource/attribute schema map the underlying API as close as possible:

A Terraform resource and associated schema should follow the naming and structure of the API, unless the it degrades the user experience or works in a way counter to a user's expectations of Terraform.

Source: https://developer.hashicorp.com/terraform/plugin/best-practices/hashicorp-provider-design-principles#resource-and-attribute-schema-should-closely-match-the-underlying-api

That link includes the benefits for following this practice.

Furthermore, it would be a bit jarring for the bastionzero_db_target data source to include these attributes, but not in the resource itself. Meaning if a user wanted to refer to any of these fields, they would have to do an extra API call / use the data source for a resource they've already created in TF. But under the hood, the resource should already have these fields since the refresh/planning procedure calls the GET API already for the resource (and that API returns those fields anyways).

---

Also, if you're wondering why some of the other computed/read-only values do not display (known after apply), this is because I've added plan modifiers that prevent this behavior for attributes that cannot change even after update--id and type are examples of this.

I agree though it can look a bit noisy. But this is also what happens in bastionzero_environment.targets as well (I think you had a similar offline comment about that a long time ago).

Lastly, in the example you mentioned above, all of those computed attributes can potentially change after update, especially when going from proxy_environment_id --> proxy_target_id (or changing proxy_target_id to another proxy target):

• agent_public_key will be different if proxy_target_id changes to a different underlying agent or if you switch from proxy env --> proxy target (n/a --> to actual key)
• agent_version same logic as above
• last_agent_update same logic as above
• region same logic as above
• status same logic as above (e.g. switching to a diff proxy target whose status is no longer Online)

[lipmas]

Thanks for the detailed explanation and links those were helpful. I definitely agree with you overall we should keep them in the resource.

It will only show (known after apply) like in the example you posted when one of the bastionzero_db_target resource's configurable attributes is modified.

Yup true so that does makes this considerably less annoying since it wont ever show up as a update in the terraform plan unless there is a real configurable change.

All of these attributes: status, last_agent_update, region, agent_public_key, etc. are part of the CRUD BastionZero API responses and Hashicorp recommends making the TF resource/attribute schema map the underlying API as close as possible:

Alright i guess that makes sense. I do see the value in that but was still wondering if making it a subset of the api would also make sense and reduce noise. I was struggling to think of any practical reasons why last_agent_update or status would need to be referenced in terraform (other than as output values for display purposes maybe). Its a little easier to see how something like agent_public_key may need to be referenced in another resource. I guess technically you could have other resources depend on the status or last_agent_update attributes but then its going to always cascade into plan changes when those attributes change. Practically speaking i dont think anyone would want that. All that said i guess there really isnt much harm in including them just in case.

Furthermore, it would be a bit jarring for the bastionzero_db_target data source to include these attributes, but not in the resource itself. Meaning if a user wanted to refer to any of these fields, they would have to do an extra API call / use the data source for a resource they've already created in TF. But under the hood, the resource should already have these fields since the refresh/planning procedure calls the GET API already for the resource (and that API returns those fields anyways).

yeah point very well taken here - it would be annoying to have to use a data source to reference one of these attributes when you the resource is already part of your terraform model. So if we have the attributes in the data source we should also have them in the resource.

[asamborski]

LGTM

The base branch was changed.