diff --git a/content/docs/iac/automation-api/getting-started-automation-api.md b/content/docs/iac/automation-api/getting-started-automation-api.md index e831458110e6..0c85e2658d11 100644 --- a/content/docs/iac/automation-api/getting-started-automation-api.md +++ b/content/docs/iac/automation-api/getting-started-automation-api.md @@ -58,7 +58,7 @@ Install the required language runtime, if you have not already. ### Obtain a Pulumi access token -You'll need a [Pulumi access token](/docs/pulumi-cloud/accounts#access-tokens) so that your programs can store the resulting state in the Pulumi Cloud. The easiest way to obtain a token is to run `pulumi login` from the command line. +You'll need a [Pulumi access token](/docs/pulumi-cloud/accounts#access-tokens) so that your programs can store the resulting state in Pulumi Cloud. The easiest way to obtain a token is to run `pulumi login` from the command line. ## Define your Pulumi program diff --git a/content/docs/iac/concepts/logging.md b/content/docs/iac/concepts/logging.md index b8bf0503bedd..e930e7a192e0 100644 --- a/content/docs/iac/concepts/logging.md +++ b/content/docs/iac/concepts/logging.md @@ -16,7 +16,7 @@ aliases: - /docs/concepts/logging/ --- -The {{< pulumi-log >}} collection of functions allow you to log diagnostics, warnings, or errors with the Pulumi engine. These are displayed, alongside all other Pulumi output, in the CLI and in the Pulumi Cloud. Events are logged and kept for historical purposes in case you want to audit or diagnose a past event. +The {{< pulumi-log >}} collection of functions allow you to log diagnostics, warnings, or errors with the Pulumi engine. These are displayed, alongside all other Pulumi output, in the CLI and in Pulumi Cloud. Events are logged and kept for historical purposes in case you want to audit or diagnose a past event. {{< chooser language "javascript,typescript,python,go,csharp,java" >}} diff --git a/content/docs/iac/concepts/stacks.md b/content/docs/iac/concepts/stacks.md index d55a3a60b5df..5354428a2a79 100644 --- a/content/docs/iac/concepts/stacks.md +++ b/content/docs/iac/concepts/stacks.md @@ -149,7 +149,7 @@ Stacks have associated metadata in the form of tags, with each tag consisting of Stack tags are only supported with the [Pulumi Cloud backend](/docs/concepts/state/). {{% /notes %}} -Custom tags can be assigned to a stack by running [`pulumi stack tag set `](/docs/cli/commands/pulumi_stack_tag_set) and can be used to customize the grouping of stacks in the [Pulumi Cloud](https://app.pulumi.com). For example, if you have many projects with separate stacks for production, staging, and testing environments, it may be useful to group stacks by environment instead of by project. To do this, you could assign a custom tag named `environment` to each stack. For example, running `pulumi stack tag set environment production` assigns a custom `environment` tag with a value of `production` to the active stack. Once you've assigned an `environment` tag to each stack, you'll be able to group by `Tag: environment` in the Pulumi Cloud. +Custom tags can be assigned to a stack by running [`pulumi stack tag set `](/docs/cli/commands/pulumi_stack_tag_set) and can be used to customize the grouping of stacks in the [Pulumi Cloud](https://app.pulumi.com). For example, if you have many projects with separate stacks for production, staging, and testing environments, it may be useful to group stacks by environment instead of by project. To do this, you could assign a custom tag named `environment` to each stack. For example, running `pulumi stack tag set environment production` assigns a custom `environment` tag with a value of `production` to the active stack. Once you've assigned an `environment` tag to each stack, you'll be able to group by `Tag: environment` in Pulumi Cloud. As a best practice, custom tags should not be prefixed with `pulumi:`, `gitHub:`, or `vcs:` to avoid conflicting with built-in tags that are assigned and updated with fresh values each time a stack is updated. diff --git a/content/docs/iac/concepts/state-and-backends.md b/content/docs/iac/concepts/state-and-backends.md index 6ef276c35aa7..5314e112fb21 100644 --- a/content/docs/iac/concepts/state-and-backends.md +++ b/content/docs/iac/concepts/state-and-backends.md @@ -24,9 +24,9 @@ aliases: Pulumi stores metadata about your infrastructure so that it can manage your cloud resources. This metadata is called _state_. Each [stack](/docs/concepts/stack/) has its own state, and state is how Pulumi knows when and how to create, read, delete, or update cloud resources. -Pulumi stores state in a _backend_ of your choosing. A backend is an API and storage endpoint used by the CLI to coordinate updates, and read and write stack state whenever appropriate. Backend options include the Pulumi Cloud, an easy-to-use, secure, and reliable hosted application with policies and safeguards to facilitate team collaboration, in addition to simple object storage in AWS S3, Microsoft Azure Blob Storage, Google Cloud Storage, any AWS S3 compatible server such as Minio or Ceph, or a local filesystem. +Pulumi stores state in a _backend_ of your choosing. A backend is an API and storage endpoint used by the CLI to coordinate updates, and read and write stack state whenever appropriate. Backend options include Pulumi Cloud, an easy-to-use, secure, and reliable hosted application with policies and safeguards to facilitate team collaboration, in addition to simple object storage in AWS S3, Microsoft Azure Blob Storage, Google Cloud Storage, any AWS S3 compatible server such as Minio or Ceph, or a local filesystem. -The default experience is to use the hosted Pulumi Cloud, which takes care of the state and backend details for you. Conversely, when using cloud storage or a local filesystem as your backend, you gain control over where your state is located at the expense of having to handle security, state management, auditing, and other concerns the Pulumi Cloud would otherwise handle for you. +The default experience is to use the hosted Pulumi Cloud, which takes care of the state and backend details for you. Conversely, when using cloud storage or a local filesystem as your backend, you gain control over where your state is located at the expense of having to handle security, state management, auditing, and other concerns Pulumi Cloud would otherwise handle for you. > Pulumi state does not include your cloud credentials. Credentials are kept local to your client — wherever the CLI runs — even when using the managed Pulumi Cloud backend. Pulumi _does_ store configuration and secrets, but encrypts those secrets using your chosen encryption provider. To learn more, see [Configuration and Secrets](/docs/concepts/secrets/). @@ -73,7 +73,7 @@ This will remove all credentials information from `~/.pulumi/credentials.json` a To change backends, run `pulumi logout` followed by `pulumi login`. -The basic form of `login` will use the Pulumi Cloud by default. If you wish to log in to a specific backend, pass the backend-specific URL as the sole argument: +The basic form of `login` will use Pulumi Cloud by default. If you wish to log in to a specific backend, pass the backend-specific URL as the sole argument: ```sh $ pulumi login @@ -91,7 +91,7 @@ backend: .... ``` -For details on the various backend URL formats and options, please see the sections on using the Pulumi Cloud and DIY backends. +For details on the various backend URL formats and options, please see the sections on using Pulumi Cloud and DIY backends. If you forget to log in, you will be automatically prompted to do so before you do anything that requires stacks or state. @@ -128,7 +128,7 @@ To view your access tokens, or create a new one manually, view the -To log into a self-hosted instance of the Pulumi Cloud, pass its API URL to the `login` command: +To log into a self-hosted instance of Pulumi Cloud, pass its API URL to the `login` command: ```sh $ pulumi login https://pulumi.acmecorp.com @@ -138,15 +138,15 @@ Everything works the same as with the standard Pulumi Cloud, except that Pulumi ### Pulumi Cloud Architecture -The Pulumi Cloud is comprised of two Internet-accessible endpoints—a web application at `app.pulumi.com` and a REST API at `api.pulumi.com`—with an assortment of cloud infrastructure to support its features. A simplified diagram of its architecture looks like this: +Pulumi Cloud is comprised of two Internet-accessible endpoints—a web application at `app.pulumi.com` and a REST API at `api.pulumi.com`—with an assortment of cloud infrastructure to support its features. A simplified diagram of its architecture looks like this: Pulumi Cloud Architecture -The Pulumi Cloud doesn't ever acquire your cloud credentials, and does not communicate with your cloud provider directly. Instead, the CLI itself coordinates with both the Pulumi Cloud's API and your cloud provider's API directly. This ensures your IAM and key management does not need to change while adopting Pulumi. In particular, if you are running Pulumi deployments from [within a CI/CD environment](/docs/using-pulumi/continuous-delivery/), you can rely on existing mechanisms and security practices that your organization has already put in place. +Pulumi Cloud doesn't ever acquire your cloud credentials, and does not communicate with your cloud provider directly. Instead, the CLI itself coordinates with both Pulumi Cloud's API and your cloud provider's API directly. This ensures your IAM and key management does not need to change while adopting Pulumi. In particular, if you are running Pulumi deployments from [within a CI/CD environment](/docs/using-pulumi/continuous-delivery/), you can rely on existing mechanisms and security practices that your organization has already put in place. -The Pulumi Cloud is reliable, secure, and has undergone multiple audits, including SOC2 and professional pen-testing. Because of the client/server division of responsibilities — notably that the server doesn't have direct access to your cloud credentials, runtime data, or PII — the Pulumi Cloud has been used in organizations with advanced compliance needs, including PCI, ISO 27001, HIPAA, and more. If you'd like to discuss any of these topics, please [contact us](/contact/). +Pulumi Cloud is reliable, secure, and has undergone multiple audits, including SOC2 and professional pen-testing. Because of the client/server division of responsibilities — notably that the server doesn't have direct access to your cloud credentials, runtime data, or PII — Pulumi Cloud has been used in organizations with advanced compliance needs, including PCI, ISO 27001, HIPAA, and more. If you'd like to discuss any of these topics, please [contact us](/contact/). -It is possible to host your own version of the Pulumi Cloud in your private cloud environment. Pulumi offers versions that run natively on AWS, Azure, Google Cloud, Kubernetes, or simple virtual machine-based private and hybrid cloud environments. The architecture is very similar to the online version, but is privately hosted and does not depend on public access over the Internet: +It is possible to host your own version of Pulumi Cloud in your private cloud environment. Pulumi offers versions that run natively on AWS, Azure, Google Cloud, Kubernetes, or simple virtual machine-based private and hybrid cloud environments. The architecture is very similar to the online version, but is privately hosted and does not depend on public access over the Internet: Pulumi Enterprise Architecture @@ -263,7 +263,7 @@ Existing DIY backends will continue to use the global namespace for stacks. You ## Migrating Between State Backends -It is possible to start with one backend and then later migrate to another. This is common if you have began your project with Pulumi using a DIY backend but later decided to adopt the Pulumi Cloud for easier use within your team. This section describes how to perform this operation, however, if you would like our assistance with a migration, [please get in touch](/contact/). +It is possible to start with one backend and then later migrate to another. This is common if you have began your project with Pulumi using a DIY backend but later decided to adopt Pulumi Cloud for easier use within your team. This section describes how to perform this operation, however, if you would like our assistance with a migration, [please get in touch](/contact/). The state for a stack includes information about its backend as well as other unique information such as its encryption provider. As such, moving a stack between backends isn't as simple as merely copying its state file. The [`pulumi stack rename` command](/docs/cli/commands/pulumi_stack_rename) can be used for simple renames within the same backend; however, Pulumi also supports migrating stacks between backends using the `pulumi stack export` and `pulumi stack import` commands, which understand how to perform the necessary translations. @@ -288,7 +288,7 @@ $ pulumi stack init my-app-production $ pulumi stack import --file my-app-production.stack.json ``` -After performing these steps, your stack will now be under the management of the Pulumi Cloud. All subsequent operations should be performed using this new backend. +After performing these steps, your stack will now be under the management of Pulumi Cloud. All subsequent operations should be performed using this new backend. > **Note:**: After migration, your stack's state will be managed by the Pulumi Cloud backend, but the stack will continue using the same secrets provider. You can separately [change the secrets provider](/docs/concepts/secrets#changing-the-secrets-provider-for-a-stack) for your stack if needed. @@ -306,7 +306,7 @@ To learn more about importing existing resources, see [Importing Infrastructure] Pulumi state is usually stored in a transactional snapshot called a _checkpoint_. Pulumi records checkpoints early and often as it executes so that Pulumi can operate reliably, similar to how database transactions work. The basic functions of state allow Pulumi to diff your program's goal state against the last known update, recover from failure, and destroy resources accurately to clean up afterwards. The checkpoint format augments this with additional failure recovery capabilities in the face of partial failure. -The Pulumi Cloud backends records every checkpoint so that it is possible to recover from exotic failure scenarios. DIY backends may have more trouble recovering from these situations as they typically store a singular Pulumi state file. +The Pulumi Cloud backend records every checkpoint so that it is possible to recover from exotic failure scenarios. DIY backends may have more trouble recovering from these situations as they typically store a singular Pulumi state file. ### State Encryption @@ -316,7 +316,7 @@ State is stored in your target backend in the form of checkpoints. In the case o A Pulumi "secret" can be used to store sensitive configuration values like database passwords and cloud tokens, and will always be handled safely. Pulumi understands the transitive usage of that secret in your state and will ensure everything it touches is encrypted, no matter which backend you've chosen. -A secret can be created one of two ways: passing `--secret` to the `pulumi config set` command, or by [creating one programmatically](/docs/concepts/secrets#secrets). In both cases, the value is encrypted using your stack's chosen encryption provider. By default with the Pulumi Cloud, a server-side HSM key is used, but you may customize the encryption provider if you'd like more control over keys, rotation, and so on. +A secret can be created one of two ways: passing `--secret` to the `pulumi config set` command, or by [creating one programmatically](/docs/concepts/secrets#secrets). In both cases, the value is encrypted using your stack's chosen encryption provider. By default with Pulumi Cloud, a server-side HSM key is used, but you may customize the encryption provider if you'd like more control over keys, rotation, and so on. To learn more about available encryption providers and how to customize your stack's, see [Configuring Secrets Encryption](/docs/concepts/secrets#configuring-secrets-encryption). diff --git a/content/docs/iac/concepts/vs/cloud-templates/cloudformation/_index.md b/content/docs/iac/concepts/vs/cloud-templates/cloudformation/_index.md index 83d5a6968c46..be85074b037b 100644 --- a/content/docs/iac/concepts/vs/cloud-templates/cloudformation/_index.md +++ b/content/docs/iac/concepts/vs/cloud-templates/cloudformation/_index.md @@ -89,7 +89,7 @@ Many high-quality plugins are available to assist you with authoring CloudFormat ### State Management {#state} -Both Pulumi and CloudFormation provide built-in support for keeping track of the state of your infrastructure. By default, Pulumi uses the free Pulumi Cloud, which handles state management automatically, but you can also choose to manage your infrastructure state on your own, either by bringing your own storage mechanism (e.g., an S3 bucket, S3-compatible service, third-party blob storage, or just a flat file) or even self-hosting the Pulumi Cloud within your enterprise network. CloudFormation state is managed entirely within the CloudFormation service. +Both Pulumi and CloudFormation provide built-in support for keeping track of the state of your infrastructure. By default, Pulumi uses the free Pulumi Cloud, which handles state management automatically, but you can also choose to manage your infrastructure state on your own, either by bringing your own storage mechanism (e.g., an S3 bucket, S3-compatible service, third-party blob storage, or just a flat file) or even self-hosting Pulumi Cloud within your enterprise network. CloudFormation state is managed entirely within the CloudFormation service. For more information on how Pulumi manages state, or using alternative backends, see [State and Backends](/docs/concepts/state/). @@ -191,7 +191,7 @@ To learn more about configuring projects and stacks with Pulumi, see [Configurat ### Audit Capabilities {#auditing} -Administrators of organizations backed by the Pulumi Cloud are able to view and export audit logs that keep track of all user-related activity across the organization. Audit logs capture many kinds of events (stack update requests, failed login attempts, decrypted secrets, removed policies, etc.) along with the timestamp of the event, the user who triggered it, and the source IP address of the call that was made. Audit logs are available to Pulumi Enterprise and Business Critical subscribers. CloudFormation offers similar capability through its integration with AWS CloudTrail. +Administrators of organizations backed by Pulumi Cloud are able to view and export audit logs that keep track of all user-related activity across the organization. Audit logs capture many kinds of events (stack update requests, failed login attempts, decrypted secrets, removed policies, etc.) along with the timestamp of the event, the user who triggered it, and the source IP address of the call that was made. Audit logs are available to Pulumi Enterprise and Business Critical subscribers. CloudFormation offers similar capability through its integration with AWS CloudTrail. To learn more about Audit Logs and the kinds of events they capture, see [Audit Logs](/docs/pulumi-cloud/audit-logs/). diff --git a/content/docs/iac/concepts/vs/opentofu.md b/content/docs/iac/concepts/vs/opentofu.md index 004f75ae74c5..2d90e4fcda33 100644 --- a/content/docs/iac/concepts/vs/opentofu.md +++ b/content/docs/iac/concepts/vs/opentofu.md @@ -92,7 +92,7 @@ OpenTofu has plugins for some IDEs. However, the features are varied and limited The OpenTofu engine takes care of provisioning and updating resources. With Pulumi, you use general purpose languages to express desired state, and Pulumi’s engine similarly gives you diffs and a way to robustly update your infrastructure. -By default, OpenTofu requires that you manage concurrency and state manually, by way of its “state files.” Pulumi, in contrast, uses the free [Pulumi Cloud](https://app.pulumi.com/) to eliminate these concerns. This makes getting started with Pulumi, and operationalizing it in a team setting, much easier. For advanced use cases, it is possible to [use Pulumi without the Pulumi Cloud](/docs/support/faq#can-i-use-pulumi-without-depending-on-the-/pulumi-cloud/), which works a lot more like OpenTofu, but requires you to manage state and concurrency issues. Pulumi errs on the side of ease-of-use. +By default, OpenTofu requires that you manage concurrency and state manually, by way of its “state files.” Pulumi, in contrast, uses the free [Pulumi Cloud](https://app.pulumi.com/) to eliminate these concerns. This makes getting started with Pulumi, and operationalizing it in a team setting, much easier. For advanced use cases, it is possible to [use Pulumi without Pulumi Cloud](/docs/support/faq#can-i-use-pulumi-without-depending-on-the-/pulumi-cloud/), which works a lot more like OpenTofu, but requires you to manage state and concurrency issues. Pulumi errs on the side of ease-of-use. For more information on how Pulumi manages state or how to use different backends, see [State and Backends](/docs/concepts/state/). diff --git a/content/docs/iac/concepts/vs/terraform/_index.md b/content/docs/iac/concepts/vs/terraform/_index.md index 6728a19a2e83..56b4b213a04c 100644 --- a/content/docs/iac/concepts/vs/terraform/_index.md +++ b/content/docs/iac/concepts/vs/terraform/_index.md @@ -247,7 +247,7 @@ Transformations, which are unique to Pulumi IaC, allow you to programmatically s The Terraform engine takes care of provisioning and updating resources. With Pulumi IaC, you use general purpose languages to express desired state, and Pulumi IaC’s engine similarly gives you diffs and a way to robustly update your infrastructure. -By default, Terraform requires that you manage concurrency and state manually, by way of its “state files.” Pulumi IaC, in contrast, uses the free [Pulumi Cloud](https://app.pulumi.com/) to eliminate these concerns. This makes getting started with Pulumi IaC, and operationalizing it in a team setting, much easier. For advanced use cases, it is possible to [use Pulumi IaC without the Pulumi Cloud](/docs/support/faq#can-i-use-pulumi-without-depending-on-the-/pulumi-cloud/), which works a lot more like Terraform, but requires you to manage state and concurrency issues. Pulumi IaC errs on the side of ease-of-use. +By default, Terraform requires that you manage concurrency and state manually, by way of its “state files.” Pulumi IaC, in contrast, uses the free [Pulumi Cloud](https://app.pulumi.com/) to eliminate these concerns. This makes getting started with Pulumi IaC, and operationalizing it in a team setting, much easier. For advanced use cases, it is possible to [use Pulumi IaC without Pulumi Cloud](/docs/support/faq#can-i-use-pulumi-without-depending-on-the-/pulumi-cloud/), which works a lot more like Terraform, but requires you to manage state and concurrency issues. Pulumi IaC errs on the side of ease-of-use. For more information on how Pulumi IaC manages state or how to use different backends, see [State and Backends](/docs/concepts/state/). diff --git a/content/docs/iac/concepts/vs/terraform/opentofu.md b/content/docs/iac/concepts/vs/terraform/opentofu.md index 65744450d673..bd8bca120453 100644 --- a/content/docs/iac/concepts/vs/terraform/opentofu.md +++ b/content/docs/iac/concepts/vs/terraform/opentofu.md @@ -84,7 +84,7 @@ Pulumi lets you take advantage of decades of innovation in modern IDEs. These to ### State Management {#state} -With Pulumi, you use general purpose languages to express desired state, and Pulumi’s engine similarly gives you diffs and a way to robustly update your infrastructure. It uses the free [Pulumi Cloud](https://app.pulumi.com/) to eliminate concerns around concurrency management requirements and state manually by way of "state files". This makes getting started with Pulumi, and operationalizing it in a team setting, much easier. For advanced use cases, it is possible to [use Pulumi without the Pulumi Cloud](/docs/support/faq#can-i-use-pulumi-without-depending-on-the-/pulumi-cloud/), which works a lot more like Terraform, but requires you to manage state and concurrency issues. Pulumi errs on the side of ease-of-use. +With Pulumi, you use general purpose languages to express desired state, and Pulumi’s engine similarly gives you diffs and a way to robustly update your infrastructure. It uses the free [Pulumi Cloud](https://app.pulumi.com/) to eliminate concerns around concurrency management requirements and state manually by way of "state files". This makes getting started with Pulumi, and operationalizing it in a team setting, much easier. For advanced use cases, it is possible to [use Pulumi without Pulumi Cloud](/docs/support/faq#can-i-use-pulumi-without-depending-on-the-/pulumi-cloud/), which works a lot more like Terraform, but requires you to manage state and concurrency issues. Pulumi errs on the side of ease-of-use. For more information on how Pulumi manages state or how to use different backends, see [State and Backends](/docs/concepts/state/). diff --git a/content/docs/iac/crossguard/awsguard.md b/content/docs/iac/crossguard/awsguard.md index b0074490590c..18a2c4601fe7 100644 --- a/content/docs/iac/crossguard/awsguard.md +++ b/content/docs/iac/crossguard/awsguard.md @@ -184,6 +184,6 @@ aws:s3:Bucket (my-bucket): ## Next Steps -Once you've validated the behavior of the AWSGuard policies you've configured in your Policy Pack, an organization administrator can publish the Policy Pack to the Pulumi Cloud to be enforced across your organization. To learn more see [Enforcing a Policy Pack Across an Organization](/docs/using-pulumi/crossguard/get-started#enforcing-a-policy-pack). +Once you've validated the behavior of the AWSGuard policies you've configured in your Policy Pack, an organization administrator can publish the Policy Pack to Pulumi Cloud to be enforced across your organization. To learn more see [Enforcing a Policy Pack Across an Organization](/docs/using-pulumi/crossguard/get-started#enforcing-a-policy-pack). Now that you've seen how to configure and use AWSGuard policies, you may want to write your own policies. See the [Getting Started tutorial](/docs/using-pulumi/crossguard/get-started/) to get started. diff --git a/content/docs/iac/crossguard/configuration.md b/content/docs/iac/crossguard/configuration.md index 3206fba0ff68..65af8793bb7c 100644 --- a/content/docs/iac/crossguard/configuration.md +++ b/content/docs/iac/crossguard/configuration.md @@ -23,7 +23,7 @@ aliases: Configuration allows you to author flexible Policy Packs that can be reused across your entire organization. As an organization administrator, you can use a single Policy Pack yet vary configuration (e.g. enforcement level, the allowed instance types, cost allowances, etc.) from one Policy Group to the next. For example, you may have a Policy Group for your non-production stacks that allow smaller instance types, while your Production Policy Group allows for use of large instance types. -Configuration schema is defined per policy, and then the actual configuration can be set via a form in the Pulumi Cloud or using a JSON file. +Configuration schema is defined per policy, and then the actual configuration can be set via a form in the Pulumi Cloud console or using a JSON file. ## Writing Configurable Policy Packs @@ -203,9 +203,9 @@ To run this Policy Pack locally with the configuration, you can run: $ pulumi preview --policy-pack --policy-pack-config ``` -## Using the Pulumi Cloud +## Using Pulumi Cloud -Configuration can also be added, edited and enabled via the Pulumi Cloud. Once a Policy Pack has been published to the Pulumi Cloud, organization administrators can enable the pack with configuration on a Policy Group using the console. Learn more in the [Enforcing a policy pack guide](/docs/using-pulumi/crossguard/get-started#enforcing-a-policy-pack). +Configuration can also be added, edited and enabled via Pulumi Cloud. Once a Policy Pack has been published to Pulumi Cloud, organization administrators can enable the pack with configuration on a Policy Group using the console. Learn more in the [Enforcing a policy pack guide](/docs/using-pulumi/crossguard/get-started#enforcing-a-policy-pack). On a Policy Group page, you can click the ADD button to enable a new Policy Pack. @@ -217,11 +217,11 @@ If the selected Policy Pack has configuration, a form will appear for you to ent ### Using the CLI with the Console -The `pulumi` CLI can also be used to interact with Policy Packs enforced by the Pulumi Cloud. The CLI allows you to both validate configuration and enable Policy Packs with configuration files. +The `pulumi` CLI can also be used to interact with Policy Packs enforced by Pulumi Cloud. The CLI allows you to both validate configuration and enable Policy Packs with configuration files. #### Validating Configuration -If the Policy Pack has already been published to the Pulumi Cloud, you can validate the configuration using the `pulumi policy validate-config` command. +If the Policy Pack has already been published to Pulumi Cloud, you can validate the configuration using the `pulumi policy validate-config` command. ```bash $ pulumi policy validate-config / --config diff --git a/content/docs/iac/crossguard/core-concepts.md b/content/docs/iac/crossguard/core-concepts.md index 01e1f3154a08..6fb2a6c7af3d 100644 --- a/content/docs/iac/crossguard/core-concepts.md +++ b/content/docs/iac/crossguard/core-concepts.md @@ -43,7 +43,7 @@ Policies may also define *remediations* to automatically fix violations rather t ### Insights Policies -When used with Pulumi Insights account discovery, policies provide visibility into compliance issues across your entire cloud footprint regardless of how they were created such as with Terraform, CloudFormation, or click-ops. Policies are executed whenever a scanned resource changes or the policy configuration is updated. Policy violations can be viewed in the Pulumi Cloud via the Policy Violations page. +When used with Pulumi Insights account discovery, policies provide visibility into compliance issues across your entire cloud footprint regardless of how they were created such as with Terraform, CloudFormation, or click-ops. Policies are executed whenever a scanned resource changes or the policy configuration is updated. Policy violations can be viewed in Pulumi Cloud via the Policy Violations page. ### Policy Packs @@ -85,7 +85,7 @@ PolicyPack( {{< /chooser >}} -There are no restrictions on which policies you combine within a pack, and you should pack them however makes sense for your organization. As part of CrossGuard, organization administrators can author, publish to, and enforce Policy Packs using the Pulumi Cloud. +There are no restrictions on which policies you combine within a pack, and you should pack them however makes sense for your organization. As part of CrossGuard, organization administrators can author, publish to, and enforce Policy Packs using Pulumi Cloud. ### Types of Policies @@ -473,7 +473,7 @@ The [Pulumi Policy Packs examples repository](https://github.com/pulumi/examples ## Policy Groups -A *Policy Group* is a group of stacks and accounts with the same set of Policy Packs enforced. Policy Groups are only available from within the Pulumi Cloud when CrossGuard is enabled. A stack or account may belong to multiple Policy Groups. An example use of Policy Groups is to have a different group per environment. For example, you can have one for your stacks in production and a more permissive Policy Group for your other environments such as `staging` and `dev`. +A *Policy Group* is a group of stacks and accounts with the same set of Policy Packs enforced. Policy Groups are only available from within Pulumi Cloud when CrossGuard is enabled. A stack or account may belong to multiple Policy Groups. An example use of Policy Groups is to have a different group per environment. For example, you can have one for your stacks in production and a more permissive Policy Group for your other environments such as `staging` and `dev`. Organization admins can create new Policy Groups, add stacks and accounts to a Policy Group, or remove stacks and accounts from a group. diff --git a/content/docs/iac/crossguard/faq.md b/content/docs/iac/crossguard/faq.md index 418321721d98..a5dd56e3ec49 100644 --- a/content/docs/iac/crossguard/faq.md +++ b/content/docs/iac/crossguard/faq.md @@ -23,17 +23,17 @@ aliases: The [Pulumi Policy SDK](https://github.com/pulumi/pulumi-policy) and Pulumi-authored policy packs like [Compliance Ready Policies](https://www.pulumi.com/docs/iac/crossguard/compliance-ready-policies/) are open-source under the Apache 2.0 license. The Pulumi CLI (also under the Apache 2.0 license) allows you to run policies during `pulumi preview` or `pulumi up` by specifying the `--policy-pack` flag free of charge, with the caveat that the policy must be present on disk. -Pulumi CrossGuard is available to [Pulumi Business Critical](/pricing/) organizations and allows for enforcing Policy Packs across an organization and viewing Policy Pack results in the Pulumi Cloud. +Pulumi CrossGuard is available to [Pulumi Business Critical](/pricing/) organizations and allows for enforcing Policy Packs across an organization and viewing Policy Pack results in Pulumi Cloud. ## How do Policy Packs enforced by the service interact with Policy Packs specified by the local Policy Pack flag? -Policy Packs enforced by the Pulumi Cloud are always run by the Pulumi CLI. +Policy Packs enforced by Pulumi Cloud are always run by the Pulumi CLI. -Therefore, if a Policy Pack is specified locally using `--policy-pack`, the Pulumi CLI will run the local Policy Pack as well as the Policy Packs enforced by the Pulumi Cloud. A violation by any of the Policy Packs would halt an update. +Therefore, if a Policy Pack is specified locally using `--policy-pack`, the Pulumi CLI will run the local Policy Pack as well as the Policy Packs enforced by Pulumi Cloud. A violation by any of the Policy Packs would halt an update. ## What happens if a stack or account belongs to multiple Policy Groups? -If a stack or account belongs to multiple Policy Groups, the Pulumi Cloud will aggregate all required Policy Packs from those Policy Groups. Only one version of each Policy Pack will be run per update. +If a stack or account belongs to multiple Policy Groups, Pulumi Cloud will aggregate all required Policy Packs from those Policy Groups. Only one version of each Policy Pack will be run per update. This means that if a stack belongs to multiple Policy Groups that specify different versions of a Policy Pack, only the newest version of that pack will be run. For example, if a stack `my-stack` belongs to Policy Group `production-stacks` that requires Policy Pack `aws-policies` version 2 and Policy Group `platform-stacks` that requires Policy Pack `aws-policies` version 4, only version 4 of `aws-policies` would be run. In the case that a stack has the same version of a Policy Pack with different configuration enabled, the most recently modified Policy Pack and configuration will be enforced. @@ -137,7 +137,7 @@ runtime: python When managing the virtual environment on your own and [running the Policy Pack locally](/docs/using-pulumi/crossguard/get-started#running-locally) against a Pulumi program, you'll need to run any `pulumi` commands (such as `pulumi up`) from an activated virtual environment shell (or, if using a tool like [Pipenv](https://github.com/pypa/pipenv), prefix any `pulumi` commands with `pipenv run pulumi ...`). If the Pulumi program is also Python, both the Policy Pack and Pulumi program can use the same virtual environment. -Enforced Policy Packs that are published to the Pulumi Cloud will automatically create a virtual environment, install dependencies in the virtual environment, and use the virtual environment when running against a Pulumi stack. +Enforced Policy Packs that are published to Pulumi Cloud will automatically create a virtual environment, install dependencies in the virtual environment, and use the virtual environment when running against a Pulumi stack. ### Adding a new dependency diff --git a/content/docs/iac/crossguard/get-started.md b/content/docs/iac/crossguard/get-started.md index 10f84d3b181d..69f11c3d1637 100644 --- a/content/docs/iac/crossguard/get-started.md +++ b/content/docs/iac/crossguard/get-started.md @@ -294,7 +294,7 @@ Now that your Policy Pack is ready to go, let's enforce the pack across your org Server-side enforcement of policy packs across an organization is only available in **Pulumi Business Critical**. See [pricing](/pricing/) for more details. {{% /notes %}} -Once you’ve validated the behavior of your policies, an organization administrator can publish them to the Pulumi Cloud to be enforced across your organization. Any Pulumi client (a developer’s workstation, CI/CD tool, etc) that interacts with a stack via the Pulumi Cloud will have policy enforcement during the execution of `preview` and `update`. Policy Packs are versioned by the Pulumi Cloud so that updated policies can be published and applied as ready and also reverted to previous versions as needed. +Once you’ve validated the behavior of your policies, an organization administrator can publish them to Pulumi Cloud to be enforced across your organization. Any Pulumi client (a developer’s workstation, CI/CD tool, etc) that interacts with a stack via Pulumi Cloud will have policy enforcement during the execution of `preview` and `update`. Policy Packs are versioned by Pulumi Cloud so that updated policies can be published and applied as ready and also reverted to previous versions as needed. 1. From within the Policy Pack directory, run the following command to publish your pack: @@ -302,7 +302,7 @@ Once you’ve validated the behavior of your policies, an organization administr $ pulumi policy publish ``` - The output will tell you what version of the Policy Pack you just published. The Pulumi Cloud provides a monotonic version number for Policy Packs. + The output will tell you what version of the Policy Pack you just published. Pulumi Cloud provides a monotonic version number for Policy Packs. ``` Obtaining policy metadata from policy plugin diff --git a/content/docs/iac/crossguard/policy-violations.md b/content/docs/iac/crossguard/policy-violations.md index 744e59c3003a..ab31ab413272 100644 --- a/content/docs/iac/crossguard/policy-violations.md +++ b/content/docs/iac/crossguard/policy-violations.md @@ -22,7 +22,7 @@ Policy Violations occur when a resource in a stack or account does not comply wi ## How to See Policy Violations -Policy Violations can be viewed in the Pulumi Cloud via the Policy Violations page. This page provides a centralized view of all violations across your organization, allowing you to filter and group them by various criteria such as Policy Pack, Project, Stack/Account, and Enforcement Level. +Policy Violations can be viewed in Pulumi Cloud via the Policy Violations page. This page provides a centralized view of all violations across your organization, allowing you to filter and group them by various criteria such as Policy Pack, Project, Stack/Account, and Enforcement Level. ### Accessing the Policy Violations Page