Pulumi Blog: Pulumi enterprise

Using Pulumi Securely

Tushar Shah — Thu, 13 Oct 2022 00:00:00 +0000

Cloud computing’s greatest strength and weakness is the proliferation of a massive number of services globally. To adequately assess and mitigate the inherent risks for your company, customers, and employees, cloud architects are typically responsible for a vast surface area of potential endpoints and vectors of attack.

Cloud Security Posture

AWS likes to talk about a Shared Responsibility Model, their friendly way of saying, “we’ve got our stuff covered, and if you’re compromised, it’s almost certainly your fault.” They have built up practices and recommendations, like the AWS Well-Architected Framework. Their pillars of architecture philosophy give you your best chances to securely use their resources (following these recommendations is easy with Crosswalk for AWS from Pulumi). Increasing high-profile attacks against private and open-source software supply chains have developers increasingly on high alert and conscious of incorporating more security into their DevOps.

Risks associated with maintaining a good cloud security posture extend to your infrastructure as code with Pulumi and it’s important to leverage the features and capabilities of the Pulumi platform along with good industry practices to secure your code, configuration and secrets.

Pulumi’s Hierarchy

Pulumi has three levels to consider access for: users, teams and organizations.

Organizations are a space for you to collaborate on shared projects and stacks. You may have multiple cloud accounts from a single cloud provider or multiple cloud provider accounts tied to an organization in any combination. It’s recommended that you segment organizations and cloud accounts to limit access and the “blast radius” of security or financial events that may occur within them.

Teams are groups of users within an organization with specific permissions to stacks. Consider using these to break up access to environments such as dev, staging and production. You should look to mirror your code repository or IAM teams/groups as much as possible.

Users are tied to personal identities, often with an identity provider and should be used wherever a human is using Pulumi. These identities should not be used for any systems, tools or pipeline-based provisioning.

Security Best Practices with Pulumi

The following recommendations should help you get started and prepare you to scale your company, application and cloud engineering team long term.

Manage Federated Identity

Connect your user and Pulumi organization with an Identity Provider such as Github, Gitlab or BitBucket, your Single Sign On (SSO) system and/or another System for Cross-Domain Identity Management (SCIM). Your code repositories hold your Infrastructure as Code, and most organizations are motivated to keep access tightly controlled. SSO improves this process across tools and puts more control into your organization’s hands. SCIM enables you to manage your users and groups centrally in your Identity Provider (IdP) and then synchronize those users and groups to the Pulumi Service. Leveraging your existing onboarding and offboarding process will help limit the risk of bad actors in Pulumi itself.

Build Pulumi Teams

Teams improve on basic role-based access control (RBAC) for administrators and users by allowing you to group users and their access to specific stacks in your organization. For example, a team called productionreadonly could be created and scoped so that all members have only limited access to read the production stacks, while another team, productionadmins, would retain full privileges to those stacks.

Import Manually Created Resources

Manually created cloud resources are error-prone and difficult to audit, iterate and improve on. If you’ve created manual resources, consider importing them to Pulumi programs.

Tag your Stacks

We have previously covered Tag Policies as a best practice for the cloud resources themselves. Still, you can also tag your Pulumi stacks to help organize and visualize your application resources in logical groupings that will help you assess, respond and automate incident remediation. Here are two examples of using tagging your stacks automatically: in Python and TypeScript.

Deploy from Pipelines

Automate every step of your deployment process for anything beyond local development by creating CI/CD pipelines. Manual approval steps in your pipeline should be avoided. Consider creating automated checks to ensure your infrastructure is created only with approved Pulumi Packages and automatically ensure your infrastructure is in compliance by using CrossGuard.

Leveraging Automation API as the programmatic interface for running Pulumi programs without the Pulumi CLI is a strongly typed and safe way to use Pulumi in embedded contexts such as web servers without having to shell out to a CLI. For example, Elkjop Nordic uses Automation API to provide a self-service portal that serves as a secure IT vending machine full of their application and infrastructure building blocks.

Log Everything

Track key system events such as user and pipeline activity, attempted and restricted activity, and identity and access control changes. Use Pulumi audit logs to simplify this process out of the box. If applicable, we would suggest automatically exporting Pulumi Audit Logs to your systems.

Use Tokens

Organization Access Tokens, Team Access Tokens and Personal Access Tokens securely connect your automation pipelines and development environments with Pulumi without the risks of association user/password combinations. Machines talk to Pulumi with tokens of various types, and it is always advisable to use Tokens over Users where possible. More on the types of tokens is below.

Organizational Access Tokens

These are scoped to the entire Pulumi organization. Use these for tooling with broad access across stacks and resources deployed in that organization. For example, if your production environment runs in an isolated cloud account and organization, then an Organization Access Token is likely appropriate for your CI/CD pipeline that deploys production.

Team Access Tokens

Scoped to the stack access of a Pulumi team. Use these when resources associated with different environments or services are commingled within a single cloud account or organization. In general, it is often recommended to create a Team Access Token for each CI/CD pipeline, for example, dev vs production.

Personal Access Tokens

Scoped to individual users. Used whenever a developer deploys from their local machine. Be sure your users are part of a Pulumi team to simplify their role-based access within the platform.

Rotate the Tokens

Add Pulumi to your list of tokens to rotate on a regular basis.

Assessing and Implementing

Even if you’ve been using Pulumi for a while, we recommend you regularly take these three steps to continuously audit and improve your cloud security posture as it relates to your infrastructure as code:

Confirm your users’, teams’, and organization access are in line with either or both your code access or cloud access policies; make any necessary updates to access, permissions or scope of privilege.
Audit any pipeline that uses Pulumi and ensure that they use fresh, rotated tokens.
Review your audit logs regularly, noting any abnormal or unexpected activity. It is advisable to export these audit logs and process them with a security event management system.

Some of the features mentioned, such as teams, SSO/SCIM and audit logs, are only available to Enterprise and/or Business Critical Edition users and those on our 14-day trial. If you would like to implement and/or test any of these features please start a trial or contact us for access.

How Elkjøp Nordic enables self-service infrastructure for developers

George Huang — Fri, 01 Jul 2022 00:00:00 +0000

At PulumiUP 2022, Tomas Jansson, software architect at Elkjøp Nordic, gave a presentation on how to enable developers to self-service infrastructure by using Pulumi’s Automation API.

Elkjøp Nordic is the leading consumer electronics retailer in the Nordics. The company sells consumer electronics, mobile phones, computers, white goods, domestic appliances, and services linked to these products both directly to consumers and to businesses. It is an omnichannel retailer and serves customers both online and through more than 400 stores. Elkjøp has retail outlets in Norway, Sweden, Finland and Denmark, and franchise operations in Greenland and Faroe Islands.

To support the company’s modernization strategy, Tomas developed a self-service infrastructure platform that would enable any developer to easily provision cloud infrastructure that uses approved resources and security practices. The goal was to empower teams at Elkjøp to increase their development velocity by using the cloud, while maintaining guardrails that uphold security and compliance.

Watch the full presentation below or read on to learn the highlights of his presentation:

The Problem: Balancing Agility and Governance

To achieve his goals, Tomas knew he had to solve the problem of balancing freedom with control. On the one hand, he wanted to foster the creativity of his developers and encourage innovation. He wanted his team to feel they were trusted and had the room to create the best solutions they could. On the other hand, he knew he had to maintain some control. Elkjøp needed to keep its applications secure. It also needed good governance so that teams can keep track of who is making changes. Tomas also wanted to limit the impact of deploying untested code. Code that was still being developed needed to be confined to the developer’s own environment. Finding the right balance between independence and control was paramount. Tomas believed this would result in great software and in developers who would enjoy their work.

The Solution: A Self-Service Infrastructure Platform

Tomas’ solution was to build a self-service infrastructure platform. Self-service infrastructure makes it possible for developers to easily access the infrastructure they need while limiting access to resources they don’t need. In effect, self-service infrastructure is a walled garden. Within the garden, developers have all the freedom they need. However, nothing they do affects what’s outside the wall. Code that causes unintended changes only affects them and no one else.

Tomas built an application that provides a “walled garden” of self-service infrastructure. Developers can create the environments they need, including an Azure resource group and a Kubernetes namespace, all through a graphical user interface. Developers can define whether the environment is for development, test or production. They can also assign values, such as which team members should have admin privileges to the associated GitHub repositories or who can contribute. From there, the platform handles provisioning and configuring all of these resources.

Here is an example that shows how a developer can create a repository simply by selecting a few parameters from a drop-down list.

Tomas determined that the best way to implement self-service infrastructure was with Pulumi and its Automation API. By using Pulumi, he could use standard programming languages to define infrastructure while using familiar software tools like IDEs and test frameworks. Pulumi also natively supports Azure and Kubernetes with 100% coverage of each provider’s APIs and same-day access to new features and updates. Finally, the Pulumi Automation API would enable him to program infrastructure automation directly into his application.

The Pulumi Automation API is a programmatic interface for running Pulumi programs without the Pulumi CLI. Automation API encapsulates the functionality of the CLI (pulumi up, pulumi preview, pulumi destroy, pulumi stack init, etc.) but with more flexibility since infrastructure operations can be controlled programmatically.

How the self-service infrastructure platform was built

Here is the workflow for the Elkjøp self-service infrastructure platform.

The self-service platform is a web application that runs the Pulumi Automation API on the server side. The application uses Pulumi to provision and configure every environment resource such as Azure resource groups, Kubernetes namespaces, service principals, and Kubernetes service accounts. Each environment comes with a Git repository that’s used by developers to manage their deployments. The Git repositories are the locus of each environment because they store everything needed to deploy changes such as infrastructure code and environment credentials.

Using the Pulumi Automation API, the application creates an Azure resource group, a team in both Azure AD and GitHub, and a new GitHub repository. The application then grants administrative access to the GitHub repo to members of the AD group. In addition to creating a Git repository for each environment, the application uses stack references for each Azure environment to inject the associated credentials into the GitHub Secret Store. These credentials are scoped to each GitHub environment so that developers can only work in their own environment. If a team has multiple environments, each environment has its own credentials so developers can’t, for example, deploy from a test environment to a production environment. Secrets are managed through the Pulumi Service.

Every new repository comes with Pulumi programs that developers can use to deploy their application. GitHub Actions initiate the deployment. When an action triggers, Pulumi reads the credentials that were generated by the self-service application, allowing Pulumi to deploy new Kubernetes or Azure resources to the environment.

Watch the demo

To illustrate how Elkjøp’s self-service platform works, Tomas presented a simplified demo application that’s based on Elkjøp’s production platform. The code for the application is available at https://github.com/mastoj/pulumi-automation-demo.

The demo is a TypeScript application that includes an API that provisions Azure and GitHub resources. Pulumi Automation API code is used to deploy new stacks by calling handler code, which is a Pulumi program that defines resources and outputs. The handler code can create Azure resource groups or GitHub repositories, and stack references are used so that outputs generated by the Azure resources can be stored in GitHub (e.g., resource group credentials).

Ready to dive into how this works in detail? Watch the demo in the video below starting around 10:20.

Next steps

After watching the demo of a self-service infrastructure platform, you can try it out for yourself by checking out the demo code. You can also learn more about Pulumi Automation API in our documentation.

If you’re new to Pulumi, then follow our getting started guide.

Launching Organization Access Tokens for the Pulumi Service

Devon Grove — Thu, 28 Apr 2022 00:00:00 +0000

As enterprise adoption of the Pulumi Service has grown 350% over the last year, we’ve seen a strong customer demand for tools to manage automated Pulumi use cases such as CI/CD and Automation API at scale. Today we are launching Organization Access Tokens to empower our largest customers to manage automated workloads in a secure and collaborative manner.

Enterprise and Business Critical customers of the Pulumi Service can now create Access Tokens tied to their Pulumi Organization. In addition to creating and managing Access Tokens tied to a user’s access (Personal Access Tokens), customers can utilize Organization Access Tokens, tokens which are not tied to a specific user. This feature is particularly useful for:

Enterprise customers using SSO/SAML/SCIM, as it enables them to create Pulumi Service tokens not tied to identities within their identity provider (IdP)
Garnering programmatic access for continuous integration and continuous delivery (CI/CD) tools and other automated processes

We’re excited to deliver one of the most requested features from the community and a top ask from some of the largest customers using the Pulumi Service. The need to use Personal Access Tokens to manage automation and organization-specific resources can lead to some friction. When a user is deprovisioned or otherwise leaves the organization, their tokens in use no longer grant access and pipelines can become broken. Additionally, since Personal Access Tokens grant access to all resources and organizations they have access to, using personal tokens in organization automation pipelines leads to the pipeline having more privileged access than is necessary. We want to enable our customers to use the principle of least privilege. At launch, Organization Access Tokens will have write permissions to stacks in an Organization. We plan to continue to expand options for scoping this access based on feedback from our customers.

See below what the experience looks like in the Pulumi Service:

Users can now create an Organization Access Token in the Pulumi Service, give it a unique human-readable name (i.e. jenkins-ci-dev) and then use it to gain access to their Pulumi Service Organization. Only Organization Admins can create and manage Organization Access Tokens. As a security consideration for our customers, Organization Access Tokens cannot create other Organization Access Tokens. When a token is created they are provided a one-time token value. These tokens can only be deleted as an explicit action, either by clicking a button in the console or calling an API to delete the token. Creating or deleting an Organization Access Token will be logged as an event in the Audit Logs.

To determine which actions have been taken by which Organization Access Tokens, and to give greater clarity into specifically which tokens are conducting what operations, we have expanded Audit Log events to include information about the Organization Access Token that took the action. As an organization can have multiple Organization Access Tokens, this is a necessary step to ensure that accurate auditing can be done in the event that a token is compromised or is being used maliciously.

See below how Organization Access Tokens appears in Audit Logs:

Learn more about using this feature in our Access Token documentation.

Let’s explore how one of our customers is adopting Organization Access Tokens in the Pulumi Service. Fauna, a Pulumi customer, is a distributed document relational database, delivered as a Cloud API. A native serverless architecture means no operations are required. Developers choose Fauna to build new applications faster and confidently scale existing ones across regions and the globe.

Previously, Fauna created a user on the Pulumi Service under a shared email account and generated a Personal Access Token for that account to manage their organization wide access. This worked well as it meant the access token was not tied to a specific user. However, when they migrated to using the Pulumi Service single sign-on (SSO) for their Organization, this approach no longer worked since all Pulumi users were now attached to their SSO provider. “This will immediately solve the issues we have. This is an improvement over the process we’re using today,” said Ben Cohen, Software Engineer at Fauna.

This feature is available to all Enterprise and Business Critical customers today, as well as on our 14-day trial. You can start a trial or Contact Us about the Pulumi Service Enterprise Edition and Business Critical Edition to take it for a spin!

Six Things You Might Not Know About the Pulumi Service

Chris Smith — Mon, 24 Jan 2022 00:00:00 +0000

As a reader of this blog, you’ve probably heard of the Pulumi Service, the default state-management backend of the Pulumi CLI. If that’s the case, there’s also a good chance you’ve heard of a number of the Service’s key features, like helping you organize your projects and stacks, collaborate with others with the help of organizations, or handle sensitive data securely with built-in support for encrypted secrets.

What you might not know, though, is that we’re adding new features to the Pulumi Service all the time, and that some of these features can be fairly easy to miss. So in this post, we’ll highlight a handful of the features you might not be aware of, and that we think make it even easier to manage your infrastructure with Pulumi.

Let’s get started!

Feature 1: Stack Tags

The first thing we’ll cover is the Pulumi stack tags feature. Stack tags are key/value pairs that are associated with your Pulumi stack. You can use them for any number of purposes, from keeping things organized to even flagging whether or not it’s okay for a script to reclaim the stack’s resources.

While you can create, edit, and remove stack tags using the Pulumi CLI (see pulumi stack tag), you can also do so in the Pulumi Console:

Once set, you can quickly filter stacks on your organization’s Projects tab as well.

Feature 2: Link Updates to your CI/CD pipeline

Another helpful thing the Pulumi Service can do is link the Pulumi stack update to the CI/CD job or run that was used to perform it, as well as to the specific source commit:

When Pulumi updates a stack, it will store some information about the local machine state, such the current git SHA if the stack resides in a git repository. It is with this data that the Pulumi Service links to relevant services where possible.

If you’re curious to know all of the information Pulumi has for a stack update, you can navigate to the Environment tab for that update:

Feature 3: Custom Update Messages

One of the most useful pieces of additional data stored with each update is the message property. By default, Pulumi will use whatever the latest git commit message is. But did you know you can customize that message from the command line?

By passing the --message (or -m) flag to pulumi up, you can provide a custom update message, which can help explain the context for why you made a particular infrastructure change:

$ pulumi up --message "Release the hounds\!"

Feature 4: Viewing Resource Changes

Another thing you might have missed is that the Pulumi Service supports multiple views for a stack update’s logs.

The standard view mimics the Pulumi CLI’s output. However, you can switch to the Diff or Diagnostic views, too.

The Diff view displays all of the properties of modified resources, along with their previous/updated values. This can be helpful when trying to understand exactly what happened for a stack update.

The Diagnostic view just outputs so-called “diagnostic” messages from the Pulumi update. Most commonly, this is where you will see the output of things like calls to JavaScript’s console.log(...) or Python’s print(...) functions. It’ll also include the output of dependent tools, like the output when building Docker containers.

Feature 5: Stack Resource Visualization

Another cool feature of the Pulumi Service is being able to visualize a stack’s resources and their relationships to one another. This is a really important feature!

One of the advantages of using an infrastructure as code tool like Pulumi is that you aren’t just creating a flat list of resources. Instead, by the virtue of how the code and resource graph is structured, you are building a graph of resources.

This means that Pulumi has a semantic understanding of not only what resources are in your stack but also how they relate to one another.

If you navigate to a stack’s Resources tab, by default you see them listed in a table. You can filter this list by resource type, or by providing a custom filter:

However, in order to see the expanded resource graph, click the Graph View button. This will switch to rendering the resources as an interactive graph.

Notice here that the resources that are part of a component are grouped together. Also, you can double click on those nodes in the graph to expand or collapse them!

Feature 6: Drilling into Resource Properties

But you don’t need to just settle for a “top-level view” of your resources. You can click on any specific resource on the Resources tab, and see all of the properties of that resource.

This allows you to see all of the properties that Pulumi is tracking for that resource. It will also show you any relationships to other resources in the same stack.

The Pulumi Service also links you to the resource’s cloud provider’s console where possible, so you can see even more details.

Is your resource missing a link to the cloud provider console? With new services being launched from the myriad providers Pulumi supports every day, it’s hard to keep up. So if you would like us to add cloud provider links, please file an issue over in the pulumi/console-requests GitHub repository so we can update our database.

There are plenty of other features to check out in the Pulumi Service, and we have exciting improvements on the way! As always, feel free to stop by the Pulumi Community Slack to learn more, ask questions, or share anything cool you’re up to!

Easily bring your team to Pulumi with SAML SSO and SCIM

Alex Mullans — Tue, 20 Apr 2021 00:00:00 -0700

Pulumi’s Cloud Engineering Platform helps teams of all sizes deliver and manage cloud apps and infrastructure. In the Pulumi Service, everyone on the team can see the infrastructure the team is responsible for, when it was last deployed, how it’s configured, and more. You can see a full breakdown of the infrastructure and understand how the team brings together individual cloud services to create applications. When you bring your teams together on Pulumi, you get a “single pane of glass” over all the cloud applications and infrastructure managed with Pulumi.

Most teams larger than a few people define their team members, and the groups they’re a part of, using an Identity Provider (IdP) like Okta, Microsoft’s Azure Active Directory, or Google Cloud Identity & Access Management. Defining groups allows you to set policies based on logical groupings of teammates, such as giving different capabilities to individual developers versus infrastructure administrators. Pulumi works seamlessly with these IdPs (and many more) by providing Single Sign-On with SAML and user and group synchronization via SCIM 2.0. When you use both SAML SSO and SCIM, you can manage the users who should have access to Pulumi and the Pulumi teams they belong to entirely from your IdP. Managing users and teams this way helps keep your organization more secure by ensuring a single point of control over the users who have access to manage and update your infrastructure. It also saves you time by centralizing all of your identity and access management workflows in your identity provider.

SAML SSO and SCIM support are only available in Pulumi Enterprise. See pricing for more details.

SAML SSO

In a world of many cloud applications and service providers, IT departments can use single sign-on with SAML to make it easier for their employees to sign in and be productive. In addition, if an employee leaves, all of that employee’s access can be disabled from a single pane of glass, rather than having to manually update each application and service provider separately. Pulumi’s support for single sign-on with SAML provides this functionality. We support any IdP that implements the SAML 2.0 specification, with specific integrations for Azure Active Directory, Okta, and GSuite.

To configure single sign-on with SAML for your Pulumi organization, use the guide that matches your IdP:

After configuring your IdP, any and all changes, either to your cloud applications and infrastructure, or your account’s settings, will be tracked and associated with the user who performed that activity. The end result is full end-to-end visibility and attestation for important changes to your Pulumi organization.

User and group synchronization via SCIM

After you’ve configured single sign-on with SAML, you can take it one step further by synchronizing your users and groups using SCIM. Synchronization extends the power of single sign-on by enabling organization administrators to use their IdP to manage the users who have access to Pulumi and which teams each user belongs to. Granting and revoking user access is seamless and automatically provides the right level of permissions to critical infrastructure.

To configure user and group synchronization via SCIM, use the guide that matches your IdP:

Distributed, least privilege access permissions model

In addition to support for standards like SAML and SCIM, the Role-Based Access Control (RBAC) permissions model enables you to set up a least privilege access model for your infrastructure resources. In such a model, all access to infrastructure is specifically granted to individual users by creating Teams that have the appropriate level of access (Read, Write, or Admin) to a set of Stacks, then adding users to those teams. Team membership can be managed manually by Team Admins or automatically using SCIM group synchronization.

Learn how to create Teams in the Teams docs.

Next steps

The Pulumi Cloud Engineering Platform’s support for the SAML and SCIM standards for SSO, user synchronization, and group synchronization makes it easy to ensure every team member has the right access and the right permissions, allowing you to empower the right teammates while still applying the principle of least privilege. Here’s how to get started:

If you’re an existing Pulumi customer, you can enable SAML in your organization settings.
If you’re new to Pulumi, start your trial now or contact sales to request a demo.

Easily bring your team to Pulumi with SAML SSO and SCIM

Alex Mullans — Wed, 24 Feb 2021 00:00:00 +0000

The Pulumi Service helps teams of all sizes deliver and manage cloud apps and infrastructure. In the console, everyone on the team can see the infrastructure the team is responsible for, when it was last deployed, how it’s configured, and more. They can see a full breakdown of the infrastructure as well, so they can understand how the team brings together individual cloud services to create their applications. When you bring your teams together on the Pulumi Service, you can provide a “single pane of glass” over all the infrastructure that you manage with Pulumi.

Most teams larger than a few people define their team members, and the groups they’re a part of, using an Identity Provider (IdP) like Okta, Microsoft’s Azure Active Directory, or Google Cloud Identity & Access Management. The Pulumi Service works seamlessly with these IdPs (and many more) by providing Single Sign-On with SAML and user and group synchronization via SCIM 2.0.

When you use both SAML SSO and SCIM, you can manage the users who should have access to Pulumi and the Pulumi teams they belong to entirely from your IdP. Managing users and teams this way helps keep your organization more secure by ensuring a single point of control over the users who have access to manage and update your infrastructure. It also saves you time by centralizing all of your identity and access management workflows in your identity provider.

SAML SSO

In a world of many cloud applications and service providers, IT departments can use single sign-on with SAML to make it easier for their employees to sign in and be productive. In addition, if an employee leaves, all of that employee’s access can be disabled from a single pane of glass, rather than having to manually update each application and service provider separately. The Pulumi Service’s support for single sign-on with SAML provides this functionality. We support most IdPs that implement the SAML 2.0 specification.

To configure single sign-on with SAML for your Pulumi organization, use the guide that matches your IdP:

User and group synchronization via SCIM

After you’ve configured single sign-on with SAML, you can take it one step further by synchronizing your users and groups using SCIM. Synchronization extends the power of single sign-on by enabling organization administrators to use their IdP to manage the users who have access to the Pulumi Service and which Pulumi teams each user is a member of. Granting and revoking user seat licenses is seamless and easily provides the right level of permissions to critical infrastructure.

To configure user and group synchronization via SCIM, use the guide that matches your IdP:

Next steps

The Pulumi Cloud’s support for the SAML and SCIM standards for SSO, user synchronization, and group synchronization make it easy to ensure every team member has the right access and the right permissions. Here’s how to get started:

If you’re an existing Pulumi customer, you can enable SAML in your organization settings.
If you’re new to Pulumi, start your trial now or contact sales to request a demo.

Pulumi is SOC 2 Certified

Eric Rudder — Thu, 07 Jan 2021 00:00:00 +0000

Pulumi’s Commitment

Pulumi is committed to operational excellence for our customers and one of the ways that we decided to demonstrate this was by completing our SOC 2 Type 2 Audit. After a lot of hard work these past few months, we are pleased to announce that Pulumi is now SOC 2 compliant!

The audit involved the entire Pulumi team. We needed to have proper controls in place across the organization and ensure that our key processes were documented and exercised. In addition, we reviewed our vendor selection process and made sure that all of our key partners were compliant with SOC as well. Our team used the overall process as an opportunity to review our overall governance and risk management procedures. Interestingly, the change in our work environment caused by Covid-19 actually helped us stress some of our process and policies, since we were forced to work remotely, much as if we had any type of interesting “event” at our headquarters.

Of course, we spent a large amount of time reviewing the security of our service. Security is already baked into our culture, with processes around training, code reviews, and the like, however, there’s no doubt this process helped us “up our game.” The policies that we already had in place (encryption of data at rest and in transit, auditing, logging, secure backup, etc.) gave us a strong foundation, however, as we reviewed key areas we found several areas for simplification and improvement.

The SOC 2 Journey

As an organization, SOC 2 requires us to promise that we abide by well-documented policies, procedures, and operational controls and to prove it to an accredited firm that reviews our operational discipline for several months. We were fortunate to find a great partner that was a superb resource as we initiated our first report. The auditors had to review a tremendous amount of data, much of it over shared screens in Zoom. Their experience also helped us think about how we can continuously improve in several key areas.

We decided to use a third party tool to help with the process. In retrospect, this was one of the best decisions we made, and picking a tool that fits with your organization is hugely important. Our engineering culture definitely believes in “get clean, stay clean” and a great tool that automates many of the routine checks is indispensable. In addition, having a central dashboard that lets you know “where you are” in your journey is incredibly valuable and can really help motivate the team. The tool also helped us find a number of enhancements that go above and beyond what SOC strictly requires. For example, we created a network diagram, which, while not strictly a SOC requirement, was a suggestion from the tool. Finally, all team members now have agent software on their laptops that helps maintain key standards that we’ve chosen for our security profile.

In addition, much of the operational excellence for SOC certification requires great DevOps discipline. Here, we had a huge insider’s advantage! We were able to use Pulumi itself to automate key procedures required by the process.

Going Forward

While we already had the key cultural attributes required for operational excellence, our SOC 2 journey was a great way to reinforce the importance of this to the entire team. Security, privacy, and resiliency are everyone’s job!

We’ve added additional training, and some templates and processes that will help us do an even better job in the future.

We have a leadership team that reviews key areas of the SOC profile quarterly, with each quarter having a special focus. For example, one quarter may focus on security, while the next may zero-in on disaster recovery. The meetings are documented and any work items identified go onto our team’s task list.

Most importantly, the journey isn’t over! Pulumi will continue to evolve. The SOC standards will continue to evolve. Industry tools and best practices will continue to evolve. We’ve come a long way since we started our SOC 2 journey and we’re committed to continuing to improve our operational excellence every day.

If you’re interested in learning more about how we approach security at Pulumi or have questions about our SOC 2 process, please reach out. We’re happy to share what we’ve learned along the way.

Auditing Your Organization's Infrastructure as Code Activity

Sean Holung — Thu, 20 Feb 2020 00:00:00 +0000

We are excited to announce the release of Audit Logs on Pulumi for Enterprise organizations. Audit logs enable you to track the activity of users within an organization. They attempt to answer what a user did, when they did it and where. They help answer these questions by recording user actions.

Pulumi’s audit logs allow you to account for the activity your users are taking within your organization. These logs are available to organizations with an Enterprise level subscription. The logs are immutable and and record all user actions. Auditing makes the activity of members in an organization attributable. The logs capture the UNIX timestamp of the event, the user who invoked the action, the event that took place, and the source IP of the call the user made.

Using Pulumi Audit Logs

Audit logs are available to organizations with an Enterprise level subscription only. If you are an organization administrator, you can view your organization’s audit logs, by selecting your organization from the organization drop down. Then click on the settings tab. On the left nav-bar you should see a tab called Audit Logs. Clicking here will allow you to view the most recent audit logs for your organization.

This will show the most recent events in descending order. You can also filter logs by a particular user by clicking on the user’s avatar. Doing so will filter out the events performed by the user you selected.

We are excited to make this feature available to our users. Get started with audit logs on Pulumi today.