Wardengate

Administer

Organizations

An organization is the tenancy boundary inside a single Wardengate install. Every target, account, policy, recording, and audit event belongs to exactly one org. Admins of one org cannot see into another. The system-level admin role sits above all orgs and is kept small on purpose.

What an org actually isolates

The isolation is a hard boundary, not a UI filter. An OrgAdmin in tenant acme querying the API for targets will receive an empty list for any target that lives in a different org — not a 403, not a filtered view, the object simply is not theirs to know about. The same applies to:

  • Targets and asset groups.
  • Stored accounts and the encrypted vault entries backing them.
  • Policies, MFA policies, and approval routes.
  • Session recordings and audit events.
  • Notification channels and webhooks.
  • Identity providers and SCIM tokens.

One org or many?

The default answer for most teams is one. Orgs are a heavy tool — they fragment your audit picture, duplicate policy, and make cross-team access requests awkward. Reach for more than one org only when one of the following is true:

  • You are an MSP or platform team running Wardengate on behalf of separate customers who must not see each other's environments.
  • Legal or regulatory boundaries force separation — for example, a PCI scope you want to keep demonstrably apart from the rest of production.
  • Two business units have incompatible identity providers and no shared operator population.
  • You are running a long-lived pilot or acquired-company integration that needs its own policy vocabulary for six to twelve months.

If you are tempted to create an org per environment (prod, staging, dev), stop. That is what asset groups and policy scoping are for. Environments are a tag dimension, not a tenancy one.

Creating an org

Org creation is a system-admin action. The resulting org starts empty — no users, no IdP, no targets — and the creator is not automatically a member. Add an admin binding in the same apply:

apiVersion: wardengate/v1
kind: Organization
metadata:
  name: payments-pci
spec:
  displayName: Payments (PCI scope)
  defaultTimezone: Europe/London
  contactEmail: payments-secops@acme.example
  retention:
    recordings: 2y
    auditEvents: 7y
  features:
    recording: true
    approvals: true
    discovery: false
---
apiVersion: wardengate/v1
kind: RoleBinding
metadata:
  name: bootstrap-admins
  organization: payments-pci
spec:
  role: OrgAdmin
  subjects:
    - kind: User
      email: secops-lead@acme.example

Inviting and onboarding admins

Once an IdP is wired, admin onboarding is just a matter of adding users or groups to an org-level role binding. Before the IdP is up, system admins can invite people directly by email; the invite creates a local user scoped to that org and expires after 72 hours if unclaimed.

wgctl org invite \
  --org payments-pci \
  --email pam.ito@acme.example \
  --role OrgAdmin

Per-org identity providers

Each org owns its own set of IdentityProvider resources. The same user (by email) can exist independently in two orgs with different group memberships and different policy outcomes. When a user signs in, Wardengate looks at the hostname and the IdP used to decide which org context to present; if a user belongs to multiple orgs, the console shows an org picker after SSO.

For MSP-style deployments with many orgs, consider giving each tenant its own subdomain of the base URL. Wardengate resolves <org>.wardengate.example.com to the matching org context and skips the picker entirely.

Cross-org visibility

There are three narrow cases where visibility crosses org lines. All three are opt-in and all are audited:

  • SystemAdmin can list orgs, targets per org, and session counts, but cannot play back recordings or read stored credentials without a temporary impersonation token.
  • Auditor (global) can read audit events and recording metadata across all orgs. Useful for a central SOC. The role does not grant any write capability.
  • Shared targets can be explicitly exported from one org to another with an OrgShare resource. The target stays owned by the source org; the consumer org gets a read-only reference that their policies can name.

Moving objects between orgs

There is no in-place move. Targets and policies are created in an org and die there. The supported pattern is to re-create the object in the destination org and, once traffic has cut over, delete the original. Audit history does not migrate — which is usually the right outcome, since audit is about what happened, not about how you have reorganised the account structure since.

Org-level defaults

Several settings are org-scoped and inherited by every object in the org unless explicitly overridden: retention windows, notification channels, approval SLAs, default session idle timeout, and recording mode. Setting sensible org-level defaults is cheaper than copying the same knob onto every policy.

wgctl org set payments-pci \
  --default-idle-timeout 15m \
  --default-session-cap 4h \
  --default-recording metadata \
  --retention recordings=2y,audit=7y

Deleting an org

Deletion is deliberate and takes two steps. First, mark the org as frozen — this blocks all new sessions and new writes but keeps audit and recording data queryable. After a cooling-off period that defaults to 30 days, you can run the purge. Frozen orgs cannot be revived, but a purge can still be cancelled right up until it runs.

wgctl org freeze payments-pci --reason "wind-down; see CR-4412"
# ...after cooling-off...
wgctl org purge payments-pci --yes-really

Purge removes the control-plane rows, but — because of object-lock on the recordings bucket — it cannot unilaterally delete recordings. Follow the pointer in the deletion receipt to tell object storage to expire the recordings on your retention schedule.

Related