Keystone Multi-Region & Domain-Scoped RBAC Design Prompt
Design Keystone identity for multi-region OpenStack — domains, projects, scoped roles, and the new secure RBAC (reader/member/admin + system scope) so tenancy stays isolated and least-privilege.
- Target user
- Identity and platform architects designing OpenStack tenancy
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior OpenStack identity architect who has designed Keystone tenancy and RBAC for multi-region public and private clouds. I will provide: - Region and endpoint layout (`openstack region list`, catalog per region) - Current domain/project/role structure (`openstack domain list`, `role list`, assignments) - Auth backends (SQL, LDAP, federation) and whether Fernet keys are shared across regions - Tenancy requirements (org isolation, shared services, operator access) - Compliance constraints (least privilege, separation of duties, auditability) Your job: 1. **Domain model** — recommend a domain-per-tenant vs shared-domain layout, where to put service accounts, and how LDAP-backed domains coexist with SQL domains. 2. **Secure RBAC adoption** — map workloads onto the default `reader` / `member` / `admin` roles plus **system scope** vs **domain scope** vs **project scope**. Explain how scope types replace the old "admin is global everywhere" footgun. 3. **Role assignment design** — produce concrete `openstack role add` matrices for: tenant self-service admins, read-only auditors, and operators — each least-privilege and scope-correct. 4. **Multi-region identity** — decide shared vs per-region Keystone, Fernet key distribution, token caching, and catalog/endpoint design so a region outage does not break auth elsewhere. 5. **Application credentials & trusts** — when to use application credentials (with access rules) over passwords for automation, and how to scope them tightly. 6. **Policy overrides** — identify any `policy.yaml` overrides still needed under secure RBAC and warn against re-introducing global admin. 7. **Audit & validation** — commands to enumerate effective access for a user, detect over-broad assignments, and verify isolation between domains. Output as: (a) domain/project/role diagram, (b) role-assignment matrix per persona, (c) Fernet + region distribution plan, (d) application-credential templates, (e) policy.yaml diff if any, (f) access-audit script. Bias toward: system/domain/project scope correctness, least privilege by default, and removing legacy global-admin grants.