Configure cloud storage and rotate credentials with no downtime

A cloud storage provider integration connects the Prisma Browser to Microsoft OneDrive or Google Drive so policy can route data there (for example, file uploads governed by an access and data rule). Provider credentials (a client secret or a service account key) expire and must be rotated on a schedule. This walkthrough configures a provider and then rotates its credentials without an outage.

Use this when: you manage cloud storage integrations as code, or you need to rotate an Azure client secret / Google service account key before it expires without breaking the integration.

Prerequisites: a Super User service account and the environment variables from Getting started. For Microsoft: an Azure AD app (tenant ID, client ID, client secret). For Google: a Workspace admin email for domain-wide delegation and a base64-encoded service account JSON key.

caution

Credentials are validated live before they are saved. Both create and replace validate against the provider before persisting. If validation fails the call returns 422 and nothing changes, so a bad rotation can never take down a working integration.

1. Configure a provider

POST /integrations/cloud-storage. displayName must be unique (1 to 30 characters), type is microsoft or google, and you send the credential block that matches the type.

# Microsoft OneDrive
curl -sS -X POST "$PB_API_BASE/integrations/cloud-storage" \
  -H "Authorization: Bearer $PB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "displayName": "OneDrive - Corp",
        "type": "microsoft",
        "microsoft": {
          "tenantId": "00000000-0000-0000-0000-000000000000",
          "clientId": "11111111-1111-1111-1111-111111111111",
          "clientSecret": "EXAMPLE~oldClientSecretValue"
        }
      }'

Response (201):

{ "id": "0CSEXAMPLEPROVIDERXXXXXXXXX" }

For Google, send a google block instead: { "emailAddress": "admin@example.com", "serviceAccountKey": "<base64-encoded JSON key>" }.

caution

Credential fields are write-only. Reads return the provider with its live status (connected / disconnected) and non-secret properties, never the secret or key you sent.

2. Find the provider and check its status

List all providers (each includes live connectivity status) to get the id you rotate against.

curl -sS "$PB_API_BASE/integrations/cloud-storage" \
  -H "Authorization: Bearer $PB_TOKEN"

Response (shape)

{
  "providers": [
    {
      "id": "0CSEXAMPLEPROVIDERXXXXXXXXX",
      "displayName": "OneDrive - Corp",
      "type": "microsoft",
      "enabled": true,
      "status": "connected"
    }
  ]
}

3. Rotate credentials with no downtime

PUT /integrations/cloud-storage/{providerId} replaces the credentials. The provider type cannot change, and every credential field is required on each call. Because the new credentials are validated live before they are persisted, the swap is atomic: it only takes effect if the new secret actually works.

The no-downtime sequence:

1. Create the new secret/key at the provider (Azure or Google) while the old one is still valid.
2. PUT the new credentials. On success (200), the integration now uses them; on 422, the old credentials remain in force.
3. Confirm status is connected.
4. Only then delete the old secret/key at the provider.

export PROVIDER_ID='0CSEXAMPLEPROVIDERXXXXXXXXX'

curl -sS -X PUT "$PB_API_BASE/integrations/cloud-storage/$PROVIDER_ID" \
  -H "Authorization: Bearer $PB_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "microsoft": {
          "tenantId": "00000000-0000-0000-0000-000000000000",
          "clientId": "11111111-1111-1111-1111-111111111111",
          "clientSecret": "EXAMPLE~newRotatedSecretValue"
        }
      }'

Response (200):

{ "id": "0CSEXAMPLEPROVIDERXXXXXXXXX" }

caution

Do not revoke the old secret until the rotation succeeds. If the PUT returns 422 or the provider comes back disconnected, the old credentials are still the ones in use. Fix the new secret and retry; revoking the old one first is what causes an outage.

Tips and gotchas

• type is immutable. Sending type on a PUT is rejected (400). To change provider type, delete and recreate.
• Delete is blocked while in use. DELETE /integrations/cloud-storage/{providerId} returns 409 with a ruleIds list if any policy rule references the provider. Detach it from those rules first.
• Schedule ahead of expiry. Drive rotation from the secret's expiry date, not a fixed calendar, so a new secret is always in place before the old one lapses.

Related

• Use cases: Manage login and data controls, Set a DLP profile on a rule