Question
Pulumi Cloud vs Self-Managed Object Storage for Data-Residency and Access-Control Constraints
Sky Moss
0 reputation · 25 Mar 2023, 10:34 UTC
59.2K views1
Loading…
0 reputation · 25 Mar 2023, 10:34 UTC
Our team must choose a Pulumi state backend that satisfies strict data-residency and access-control requirements while preserving operational visibility. Pulumi Cloud offers managed encryption, organization-level RBAC, and audit logs, but stores state in a third-party SaaS environment that may conflict with sovereignty policies. Self-managed backends such as S3, Azure Blob, or GCS keep state inside our own cloud account and integrate with native IAM, yet require manual configuration of bucket policies, encryption keys, versioning, and access logging.
The unresolved trade-off is that Pulumi does not provide a unified policy layer across both backend types. RBAC granularity and audit retention differ significantly between Pulumi Cloud and self-managed storage, and backend-specific behaviors—including server-side encryption defaults and the exact IAM permissions required to read and write state—change across Pulumi versions. We need to determine whether a vendor-operated backend is acceptable or whether full cloud-account ownership of infrastructure metadata is mandatory.
Does Pulumi Cloud's organization-level RBAC and audit logging meet strict data-residency requirements when state is stored in a third-party SaaS region, or is a self-managed backend required? For self-managed object storage, what is the minimal set of IAM permissions and bucket policy conditions needed to prevent accidental public access while still allowing Pulumi to read and write state? Is there a documented way to unify audit retention and access granularity across Pulumi Cloud and self-managed backends, or must teams accept divergent policy models?
32775 reputation · 25 Mar 2023, 13:08 UTC
If your policy requires that Pulumi state remain inside your own cloud account, Pulumi Cloud is not a compliant option. A self-managed backend (S3, Azure Blob, or GCS) is required. Pulumi Cloud’s organization RBAC and audit logs operate inside a third-party SaaS environment; they do not change where state bytes are stored. There is no documented unified policy layer that harmonizes Pulumi Cloud RBAC with cloud-native IAM, so teams must accept divergent access and retention models.
Confirmed: Self-managed backends store state in your account and inherit your cloud IAM. Pulumi Cloud stores state in Pulumi-operated infrastructure regardless of SaaS RBAC features. Versioning, default encryption, and access logging are not automatically enabled on self-managed buckets; you must configure them.
Uncertain / verify for your version: Exact region availability and residency guarantees for Pulumi Cloud change over time. GCS state-locking semantics differ from S3 and Azure. Overly narrow IAM policies can break checkpoint or history reads. Encryption-key permissions (e.g., KMS) add separate dependencies. Because these details shift across Pulumi releases, verify current documentation for your CLI version before finalizing policies.
For an S3 backend, the working minimum is typically:
pulumis3:ListBucket and s3:GetBucketLocation on the bucket.s3:GetObject, s3:PutObject, and s3:DeleteObject on objects in that bucket.Pair this with S3 Block Public Access enabled and a bucket policy that denies non-TLS requests and any public principal. For Azure Blob, use the Storage Blob Data Contributor role with public blob access disabled and HTTPS-only transport. For GCS, grant storage.objectAdmin (or equivalent) with uniform bucket-level access and public access prevention enabled.
pulumi whoami -v to confirm the active backend URL.pulumi stack export after migration to verify read/write and encryption headers.You can export Pulumi Cloud audit logs and cloud provider logs to a central SIEM, but that is log aggregation only. It does not unify RBAC granularity or retention. If strict residency is mandatory, plan for two policy domains: Pulumi organization roles (if still used for team management) and cloud IAM/bucket policies for state.
One diagnostic detail would change the concrete policy shape: which cloud provider and Pulumi CLI version are you targeting? That determines the exact role names, locking behavior, and whether additional KMS permissions are needed.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.