🔐Advanced25 minSecurity

Lock down a workspace with SSO & RBAC

Connect Okta or Azure AD over SAML, map IdP groups to VxCloud roles, enforce MFA on production paths, and confirm every privileged action lands in the audit stream.

What you'll build

SSO via SAML 2.0 (Okta or Azure AD)
IdP groups mapped to developer / admin / finance roles
MFA enforced on production deploys and Vault access

Before you begin

Workspace owner / admin role
Admin access to your Okta or Azure AD tenant
A test user in a non-admin IdP group to verify mapping

Register the identity provider

Go to Settings → Security → SSO. Choose Okta or Azure AD and paste the Entity ID, SSO URL, and signing certificate from your IdP. This is stored on the organization as sso_config; the certificate is sealed in Vault at workspaces/<org>/sso/saml_certificate.

app.prodxcloud.com/settings/security/sso

Provider: Okta

Entity ID: https://acme.okta.com/…

SSO URL: https://acme.okta.com/app/…/sso/saml

Certificate: uploaded → Vault

SAML 2.0 metadata in; the cert never sits in the database in plaintext.

Map IdP groups to roles

On the IdP side, send a groups assertion. In VxCloud, map each group to a role. Mapping is least-privilege: an unmapped group gets no access, not default access.

group → role mapping

eng:dev        ->  developer   # deploy to staging, read prod
eng:admin      ->  admin       # manage nodes, keys, SSO
billing:fin    ->  finance     # billing + usage, no infra
(unmapped)     ->  (no access)

Test with a non-admin first

Always verify with a user who is only in eng:dev. If an unmapped user can log in and see anything, stop and fix the mapping before rollout.

Enforce MFA on sensitive paths

Turn on MFA enforcement for production deploys, Vault reads, and audit-sensitive operations. VxCloud uses TOTP; users enroll on next login and re-prompt on these actions even within a session.

app.prodxcloud.com/settings/security/mfa

Production deploysMFA required

Vault secret accessMFA required

Developer key issuanceMFA required

Read-only dashboardoff

MFA is required at the action boundary, not just at login — a stolen session can’t deploy to prod.

Verify every privileged action is audited

RBAC is only trustworthy if it’s observable. Confirm a privileged action shows up in the audit stream with the actor and a hash-chained record:

audit check

$ curl …/api/v3/audit/events?category=apikey&[email protected]

{"action":"issued xc_live_ key","severity":"warning","actor":"[email protected]"}

hash chained to prev_hash — tamper-evident

Workspace locked down

SSO, least-privilege roles, action-boundary MFA, and an auditable trail. Ship that trail to your SIEM with the next tutorial.

Nice work — you're done!

You completed Lock down a workspace with SSO & RBAC. Keep the momentum going with the next walkthrough, or jump back to the full catalog.

Next: Stream audit events to Splunk / Datadog All tutorials

Run vxcli inside GitHub Actions Stream audit events to Splunk / Datadog