Merge branch 'main' into RADAR-6812-adding-documentation-for-aws-secrets-manager-indexing

Author: kishanHashicorp

.github/workflows/label-content-prs.yml

@@ -5,7 +5,9 @@
 
 name: 🏷️ Label content PRs
 
-on: [pull_request_target]
+on:
+  pull_request_target:
+    types: [opened, synchronize, reopened]
 
 jobs:
 

content/hcp-docs/data/docs-nav-data.json

@@ -762,10 +762,6 @@
         "title": "Secrets inventory reporting<sup>Beta</sup>",
         "path": "vault/secrets-inventory"
       },
-      {
-        "title": "HCP Vault API",
-        "href": "/hcp/api-docs/vault"
-      },
       {
         "title": "Additional resources",
         "routes": [

content/terraform-docs-common/docs/cloud-docs/integrations/service-now/service-catalog-terraform/developer-reference.mdx

@@ -20,9 +20,9 @@ This function looks for variables following these conventions:
 
 | ServiceNow Variable Name         | HCP Terraform Variable                                   |
 | -------------------------------- | ---------------------------------------------------------- |
-| `tf_var_VARIABLE_NAME`           | Terraform Variable: `VARIABLE_NAME`                        |
+| `tf_var_hcl_VARIABLE_NAME`           | Terraform Variable: `VARIABLE_NAME`                        |
 | `tf_env_ENV_NAME`                | Environment Variable: `ENV_NAME`                           |
-| `sensitive_tf_var_VARIABLE_NAME` | Sensitive Terraform Variable (Write Only): `VARIABLE_NAME` |
+| `sensitive_tf_var_hcl_VARIABLE_NAME` | Sensitive Terraform Variable (Write Only): `VARIABLE_NAME` |
 | `sensitive_tf_env_ENV_NAME`      | Sensitive Environment Variable (Write Only): `ENV_NAME`    |
 
 This function takes the ServiceNow Variable Set and HCP Terraform workspace
@@ -61,17 +61,17 @@ Server Development > Script Include.
 
 ### Example Service Catalog Flows and Actions
 
-The ServiceNow Service Catalog for Terraform provides sample catalog items that use **Flows**
-and **Workflows** as their primary process engines.  **Flows** are a newer solution developed
-by ServiceNow and are generally preferred over **Workflows**. To see which engine an item is using, open it
-in the edit mode and navigate to the **Process Engine** tab. For example, **Create Workspace** uses a **Workflow**,
-whereas **Create Workspace Flow** is built upon a **Flow**. You can access both in the **Studio**. You can also
+The ServiceNow Service Catalog for Terraform provides sample catalog items that use **Flows** 
+and **Workflows** as their primary process engines.  **Flows** are a newer solution developed 
+by ServiceNow and are generally preferred over **Workflows**. To see which engine an item is using, open it 
+in the edit mode and navigate to the **Process Engine** tab. For example, **Create Workspace** uses a **Workflow**, 
+whereas **Create Workspace Flow** is built upon a **Flow**. You can access both in the **Studio**. You can also 
 manage **Flows** in the **Flow Designer**. To manage **Workflows**, navigate to **All > Workflow Editor**.
 
-You can find the ServiceNow Example Flows for Terraform in the **ServiceNow Studio > Flows** (or **All > Flow Designer**).
-Search for items that belong to the **Terraform** application. By default, Flows execute when someone submits an order request
-for a catalog item based on a Flow. Admins can customize the Flows and Actions to add approval flows, set approval rules based
-on certain conditions, and configure multiple users or roles as approvers for specific catalog items.
+You can find the ServiceNow Example Flows for Terraform in the **ServiceNow Studio > Flows** (or **All > Flow Designer**). 
+Search for items that belong to the **Terraform** application. By default, Flows execute when someone submits an order request 
+for a catalog item based on a Flow. Admins can customize the Flows and Actions to add approval flows, set approval rules based 
+on certain conditions, and configure multiple users or roles as approvers for specific catalog items. 
 
 | Flow Name                     | Description                                                                                                                                                                  |
 | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -80,19 +80,17 @@ on certain conditions, and configure multiple users or roles as approvers for sp
 | Create Run                    | Creates and queues a new run in the HCP Terraform workspace.                                                                                                                   |
 | Apply Run                     | Applies a run in the HCP Terraform workspace.                                                                                                                              |
 | Provision Resources           | Creates a new HCP Terraform workspace (with auto-apply), creates and queues a run, then applies the run when ready.                                                                     |
-| Provision Resources with Vars | Creates a new HCP Terraform workspace (with auto-apply), creates any variables, creates/queues a run, applies the run when ready.
+| Provision Resources with Vars | Creates a new HCP Terraform workspace (with auto-apply), creates any variables, creates/queues a run, applies the run when ready.  
 | Provision No-Code Workspace and Deploy Resources | Creates a new HCP Terraform workspace based on a no-code module configured in the private registry (with auto-apply), creates any variables, creates and queues a run, then applies the run when ready.                                                |
 | Delete Workspace              | Creates a destroy run plan.                                                                                                                                                  |
 | Worker Poll Run State         | Polls the HCP Terraform API for the current run state of a workspace.                                                                                                      |
 | Worker Poll Apply Run         | Polls the HCP Terraform API and applies any pending Terraform runs.                                                                                                        |
 | Worker Poll Destroy Workspace | Queries ServiceNow Terraform Records for resources marked `is_destroyable`, applies the destroy run to destroy resources, and deletes the corresponding Terraform workspace. |
-| Update No-Code Workspace and Deploy Resources | Updates an existing no-code workspace to the most recent no-code module version, updates that workspace's attached variable values, and then starts a new Terraform run.
+| Update No-Code Workspace and Deploy Resources | Updates an existing no-code workspace to the most recent no-code module version, updates that workspace's attached variable values, and then starts a new Terraform run.     
 | Update Workspace              | Updates HCP Terraform workspace configurations, such as VCS repository, description, project, execution mode, and agent pool ID (if applicable).                               |
 | Update Workspace with Vars    | Allows you to change details about the HCP Terraform workspace configurations and attached variable values.                                                          |
 | Update Resources              | Updates HCP Terraform workspace details and starts a new Terraform run with these new values.                                                                              |
 | Update Resources with Vars    | Updates your existing HCP Terraform workspace and its variables, then starts a Terraform run with these updated values.                                                    |
-| Provision Resources with Vars with Approval | Creates a new HCP Terraform workspace, enables auto-apply, creates workspace variables, starts a speculative plan, then pauses for approval. If you approve the run, HCP Terraform applies the plan.
-| Update Resources with Vars with Approval | Updates your existing HCP Terraform workspace and its variables, then starts a Terraform run (speculative plan) with these updated values. If request is approved, the plan is applied. If it is rejected then the it will not be applied.                                                   |
 
 ## ServiceNow ACLs
 

content/terraform-docs-common/docs/cloud-docs/registry/publish-modules.mdx

@@ -58,7 +58,7 @@ For example, you could use the following release tags in your Git repository:
 
 Then, you could specify `app-` in the **Module Tag Prefix** field when configuring the settings for publishing modules in HCP Terraform or Terraform Enterprise. As a result, the platform selects the module tagged with `app-v1.0.0` and publishes `v1.0.0` to the registry. In this example, HCP Terraform or Terraform Enterprise would also publish version `v1.0.1` of the module when a new release in the repository is tagged with `app-v1.0.1`.   
 
-To change the default behavior, you can disable the **Publish modules to your private registry from a single repository** option in your workspace's general settings. When disabled, you should store the source code for each module in separate repositories, otherwise HCP Terraform and Terraform Enterprise may publish new versions of all modules in the repository each time you create a new release tag. 
+To change the default behavior, you can disable the **Publish modules to your private registry from a single repository** option in your organization settings. When disabled, you should store the source code for each module in separate repositories, otherwise HCP Terraform and Terraform Enterprise may publish new versions of all modules in the repository each time you create a new release tag. 
 
 ## Publish a new module
 

content/terraform/v1.12.x/docs/language/import/index.mdx

@@ -84,7 +84,7 @@ import {
   id = "i-abcd1234"
 }
 
-resource "aws_instance" "example {
+resource "aws_instance" "example" {
   count = 2
   #. . .
 }

content/terraform/v1.12.x/docs/language/modules/configuration.mdx

@@ -44,6 +44,7 @@ In the following example, Terraform selects the module version from a Git reposi
 module "vpc" {
   source = "git::https://example.com/vpc.git?ref=v1.2.0"
 }
+```
 
 You can also source a module using its SHA-1 hash: 
 

content/terraform/v1.13.x/docs/language/import/index.mdx

@@ -89,7 +89,7 @@ import {
   id = "i-abcd1234"
 }
 
-resource "aws_instance" "example {
+resource "aws_instance" "example" {
   count = 2
   #. . .
 }

content/terraform/v1.13.x/docs/language/modules/configuration.mdx

@@ -44,6 +44,7 @@ In the following example, Terraform selects the module version from a Git reposi
 module "vpc" {
   source = "git::https://example.com/vpc.git?ref=v1.2.0"
 }
+```
 
 You can also source a module using its SHA-1 hash: 
 

content/vault/global/partials/important-changes/breaking-changes/allowed-parameters-list.mdx

@@ -0,0 +1,34 @@
+### Item-by-item list comparison for allowed_parameters and denied_parameters ((#allowed-parameters-list))
+
+| Change       | Affected version | Vault edition
+| ------------ | ---------------- | -------------
+| Breaking     | 1.21.0+          | All
+
+Previous versions of Vault only matched list parameters when the associated
+policy defined the list as a whole. As a result, Vault allowed lists containing
+denied values as long as the policy did not deny that exact list and denied
+lists containing allowed values because the policy did not allow the exact list.
+
+Vault now checks each value in a list parameter against allowed/denied values
+in the applicable Vault policy and allows or denies requests if the policy
+defines the list as a whole or every/any individual element of the list. For
+example, if the request includes a list like `['a', 'b', 'c']`, it still matches
+to a policy that includes `['a', 'b', 'c']` but also matches to an approve
+policy that includes all the individual values `a`, `b`, and `c` or a deny
+policy that includes any of the individual values.
+
+#### Recommendation
+
+Workflows that previously succeeded may now fail due to permission checks
+involving `denied_parameters` because the new matching behavior correctly
+identifies the fact that the list contains individually denied values even when
+the exact list does not appear in the policy.
+
+To address the broken workflow:
+- Check whether or not your policies are overly restrictive.
+- Update your workflows to avoid including explicitly denied values in lists.
+
+Refer to [list parameter evaluation](/vault/docs/concepts/policies#list-parameter-evaluation) for more information.
+
+You can temporarily revert to the deprecated matching behavior by setting the
+`VAULT_LEGACY_EXACT_MATCHING_ON_LIST` environment variable on your Vault server.

content/vault/global/partials/important-changes/breaking-changes/client-count-timestamp.mdx

@@ -0,0 +1,29 @@
+### Renamed timestamp fields for client count activity export ((#client-count-export))
+
+| Change       | Affected version | Vault edition
+| ------------ | ---------------- | -------------
+| Breaking     | 1.21.0+          | All
+
+Vault counts a client the first time that client makes an authenticated API
+during the billing period.
+
+Previously, the Activity Export endpoint response included a `timestamp`
+field that reflected the creation time and date for the client token, which
+could precede the start of the billing period, rather than the time and date
+of the first authenticated API call.
+
+To clarify the data returned, the endpoint now returns two timestamp parameters:
+
+- **`client_first_usage_time`** - (new) indicates when the client first made an
+  authenticated API call during the billing period.
+- **`token_creation_time`** - (replaces `timestamp`) indicates the creation
+  timestamp of the token.
+
+
+#### Recommendation
+
+Review your use of the `timestamp` field and:
+
+1. Consider if the context makes `client_first_usage_time` a more appropriate
+   timestamp.
+1. Update any remaining references to `timestamp` to use `token_creation_time`.