Customers and users have asked for the ability to change the secrets manager associated with their stacks. This would allow a user to rotate their secrets providers when people leave their organization or even to be able to migrate to another secret manager of their choice. The v2.8.0 release of Pulumi adds support for this specific feature. Let’s have a look at how to change a secrets provider for an existing stack:
The secrets in your infrastructure are a vital part of your security model, and provisioning infrastructure is an inherently privileged process. Previously we introduced secret encryption and started encrypting secret configuration values inside the Pulumi state so that users could be confident their passwords, tokens, and other secret values were viewable only by them while managing their infrastructure. Our first iteration of the encryption used either a passphrase for encrypting the secret or encryption via the Pulumi service backend. However, these options didn’t meet the needs of our users who needed more control over their data. That’s why we also added support for “Cloud Secret Providers,” giving users full confidence that their sensitive values are for their eyes only.
Over the past few months, we have been hard at work on Pulumi CrossGuard, a Policy as Code solution. Using CrossGuard, you can express flexible business and security rules using code. CrossGuard enables organization administrators to enforce these policies across their organization or just on specific stacks. CrossGuard allows you to verify or enforce custom policies on changes before they are applied to your resources. CrossGuard is 100% open source and available to all users of Pulumi, including the Community Edition. Advanced organization-wide policy management features are available to Team Pro and Enterprise customers.
While some people coming to Pulumi are entirely new to Infrastructure as Code, increasingly teams are moving from other tools - whether cloud-specific in the form of CloudFormation or ARM Templates, or cloud-agnostic tools such as Terraform. In these organizations, new infrastructure provisioned with Pulumi must co-exist with existing resources provisioned with other tools, and often by different teams. For example, it’s common to see an application team deploying into a VPC owned and managed by a network operations team.
this kind of workflow
natively using the
type from the Pulumi SDK. Integration with the most popular
cloud-specific tools have been supported by Pulumi since the earliest
aws.cloudformation.getStack()function can be used to obtain the outputs from a CloudFormation Stack.
We recently added similar support for reading the outputs of a Terraform
state file - both from local
.tfstate files, and from all of the
remote state backends supported by Terraform. This is exposed via the
terraform.state.RemoteStateReference type in the
We’ve had a 1st class concept of encrypted secrets configuration ever since first releasing Pulumi. Customers have told us they love having such a simple and easy way to ensure safe management of tokens, database passwords, and more. Since launching, however, we’ve also heard that you’d like more control over encryption and to see this protection expanded to cover not just configuration, but all of the secret data within their Pulumi deployments.
To support this, we’ve added two new features to Pulumi in our latest 0.17.12 release:
- Automatic tracking of secret values throughout a Pulumi program to ensure that all such values are always encrypted in the resulting state, no matter how they are used.
- A new option to use custom client-side encryption, instead of the default of using the Pulumi backend for encryption, to have full control over the secrets encryption and decryption.
Together, these features provide you with complete control over how secrets are managed within Pulumi deployments. We have worked with customers with advanced security and compliance needs while developing this feature, enabling them to use our online hosted SaaS with even greater confidence.
Google Cloud is one of the most exciting cloud platforms available today, with a breadth of powerful infrastructure services from Google Container Engine (GKE) and Google Cloud Functions to Cloud Firestore and Cloud Spanner.
Pulumi is the most productive tooling available today for teams building cloud applications and infrastructure, in your favorite languages. Add them together, and teams can easily take maximum advantage of Google Cloud Platform’s rich features, productively, with a combined platform that makes it easy to collaborate, share, and reuse.
Pulumi makes developing and deploying rich serverless and container-based applications a breeze. But how do you monitor and observe those applications while they are being developed and once they are deployed? There are many great answers: from the built-in capabilities of the underlying cloud services (Lambda, ECS, Kubernetes, and more), to great 3rd party solutions like IOpipe and Epsagon which we highlighted recently on this blog.
The Pulumi CLI provides another way to do logging, without requiring the
additional setup of these existing solutions and seamlessly integrated
into your Pulumi development workflow. The
pulumi logs command
provides a great first place to start for understanding your Pulumi
application’s behavior. Especially during development, this command
provides direct insight into the behavior of your application, bringing
together logs across all of the different forms of compute you are using -
from code running in serverless functions to containers to VMs.
Let’s take a quick look at
pulumi logs and some of the ways it can be
used as part of the inner loop of your Pulumi development.
We have been hard at work the past few months providing our users with more ways to connect to Pulumi. Here are some our past announcements related to identities: Support for Atlassian identity Connecting multiple identities to an existing Pulumi account Support for GitLab identity Today, we are pleased to announce that we are launching support for email-based identities. You no longer need to use a social identity to sign-up for an account on Pulumi.
Today we added support for yet another developer favorite product, Atlassian Bitbucket. You can now sign-up for a Pulumi account with an Atlassian identity. This also means you can connect your Atlassian identity with an existing Pulumi account.
This helps users with repos across the major version control systems to seamlessly import their GitHub Organizations and GitLab Groups - and now Atlassian Bitbucket Teams - into a single Pulumi account. Of course, you don’t need to connect identities. You can always create separate account for each of your identities, if that’s what you want to do.
When you’re able to build an app for any cloud using real languages, the obvious question is “Where to start?”. We hear you, and so we’ve built some new features to help you scaffold your app and program the cloud even faster than before.
In this post, we’ll look at how to use
pulumi new and our selection
of templates to build your Pulumi