Issue a Cloud Credential

A Cloud names a provider account; a CloudCredential is the vaulted secret that pays for provisioning against it. This lesson — the second of the three that build the provisioning catalog — issues a Credential under the Cloud you created in Create a Cloud, still acting as the platform operator.

The payload you hand it is the secret material the broker later spends. It is accepted inbound only and never crosses any read surface again, so a throwaway value is all this lesson needs.

This lesson takes about five minutes.

Before you start

This lesson builds on Create a Cloud: the demo Cloud must already exist, because a Credential is issued under a Cloud. Complete that lesson first. Beyond it you need only a running, logged-in stack from Set up your local plexsphere and jq on your $PATH.

You act as the platform operator throughout — operator@example.com, which holds the platform:plexsphere#admin authoring grant and the manage relation it received on the Cloud when it created it. See the tutorials overview for the full cast.

Recreate the shell environment and read the Acme Corp Domain id and its active IdP binding with make dev-ids — the operator sign-in needs both:

export PATH="$PWD/bin:$PATH"
export PLEXSPHERE_URL=http://localhost:8080

eval "$(make -s dev-ids)"
echo "domain=$DOMAIN_ID binding=$BINDING_ID"

Step 1 — Recover the Cloud id

Sign in as the platform operator under the operator profile, completing sign-in in the browser as operator@example.com with the password password:

plexctl login --profile-name operator --domain-id "$DOMAIN_ID" --idp-binding-id "$BINDING_ID"

The credential is issued under the demo Cloud, so recover that Cloud's id from the catalog by its slug:

CLOUD_ID=$(plexctl cloud list --all --profile operator --output json \
  | jq -r '.items[] | select(.slug == "demo-cloud") | .id')
echo "$CLOUD_ID"

Step 2 — Issue the demo Credential

Issue the CloudCredential under that Cloud. The payload is the secret material the broker spends; it is accepted inbound only and never crosses any read surface again, so a throwaway value is fine for the lesson:

printf '{"access_key_id":"AKIAEXAMPLE","secret_access_key":"example"}' > /tmp/demo-credential.json
CREDENTIAL_ID=$(plexctl cloud credential create \
  --cloud-id "$CLOUD_ID" \
  --display-name demo-credential \
  --payload-file /tmp/demo-credential.json \
  --profile operator --output json | jq -r '.id')
echo "$CREDENTIAL_ID"

The create returns metadata only — the credential material lives in the secrets engine and never crosses this surface again. If the call returns Permission Denied, the manage grant from creating the Cloud has not reached the authorization mirror yet; wait a second and re-run it.

What you learned

• A CloudCredential is the secret that pays for a Cloud. It is owned by a Cloud — issuing one needs the manage relation on that Cloud, the residency pivot the issue gate authorises against.
• The payload is inbound-only. The create returns metadata only; the secret material lives in the secrets engine and no read surface ever returns it again, so keep your own copy if you need it elsewhere.
• The credential id is what a Project requests. A Project owner later names this CREDENTIAL_ID to request a credential assignment — the two-party governance the provisioning lesson exercises.

Where to go next

• Keep learning by doing — Register a Blueprint authors the cloudless recipe a Resource is provisioned from — the last piece of the catalog.

Or pick the quadrant that matches what you need now:

• You have a job to do — the Issue a Cloud Credential how-to covers the operator runbook, including supplying the payload from a file or stdin.
• You want the exact contract — the plexctl cloud reference documents the cloud credential command surface and its output shape.
• You want to understand why credentials are brokered this way — the OpenBao Credential Broker context explains how the secret material is vaulted.