Identity and Access Management for Private Cloud

Attackers log in more often than they break in

Cybersecurity Awareness Month tends to focus on the people side of security, and for good reason. Stolen and misused credentials remain one of the most common ways attackers get into cloud environments. Once they have a valid login, your firewall sees an authorized user, not an intruder.

That is why identity has become the real perimeter. The question is no longer only "can someone reach this server?" but "if someone logs in as this user, what can they touch?"

A quick distinction before we start. Your identity provider, such as Microsoft Entra ID, Okta, or Google Workspace, answers who someone is. Your cloud's identity and access management answers what they are allowed to do once inside. Both have to be right. This guide covers the second half for an OpenStack private cloud: how access is structured, how to apply least privilege, and how to keep it clean over time.

How access is structured in an OpenStack private cloud

OpenStack handles identity through Keystone, its identity service. Every API call, CLI command, and dashboard action is checked against it. Four building blocks matter:

OpenStack ships with three default roles that cover most needs:

• reader: can view resources but not change them. Ideal for auditors, finance, and support staff.
• member: can create and manage resources within a project.
• admin: can manage the project or, at higher scope, the cloud itself. This role should be rare.

The key design choice is that permissions are scoped. A user can be an admin in the staging project and a reader in production. That scoping is your strongest tool for limiting damage when an account is compromised.

Design roles around least privilege

Least privilege means each person and system gets the minimum access needed to do its job, and nothing more. In practice:

1. Assign roles to groups, not individuals. Create groups like "platform-admins", "app-developers", and "auditors", assign roles to the groups, then add people. When someone changes teams, you move them between groups instead of hunting down individual assignments.
2. Separate environments into projects. Developers can hold the member role in dev and staging and the reader role in production. Production changes go through a pipeline or a small admin group.
3. Keep cloud-wide admin to a handful of named people. Every admin account is a high-value target. Two or three is usually enough for a mid-sized team.
4. Default to reader. When someone asks for access, start with read-only and upgrade only when there is a concrete need.
5. Do not share accounts. Shared logins make it impossible to know who did what, and impossible to revoke one person's access without disrupting everyone.

Turn on MFA and connect your identity provider

A password alone is not enough protection for anyone who can change cloud infrastructure. Two steps close most of the gap.

Require multi-factor authentication. Keystone supports time-based one-time passwords (TOTP) and lets you set per-user rules that require more than one authentication method. At minimum, enforce MFA for every account with the admin role and for anyone with access to production projects.

Federate with your existing identity provider. Keystone can trust an external identity provider over SAML 2.0 or OpenID Connect. Users sign in with the same corporate account they use everywhere else, and your IdP's MFA, conditional access, and password policies apply automatically. The biggest benefit shows up at offboarding: disable someone in your IdP and their cloud access ends with it.

Federation also lets you map IdP groups to cloud roles, so "Finance" in your directory can become "reader on the billing project" without anyone creating local accounts.

Treat machine identities as seriously as human ones

Scripts, CI/CD pipelines, backup jobs, and monitoring tools all need to talk to your cloud. These machine identities often hold more access than any human, and their credentials end up in config files, environment variables, and sometimes public repositories.

• Use application credentials instead of user passwords. Keystone application credentials let a user create a separate secret for a specific tool, scoped to one project and a subset of their roles, with an optional expiry date. If the credential leaks, you revoke it without changing anyone's password.
• Restrict what each credential can call. Application credentials support access rules that limit them to specific API operations. A backup job that only needs to snapshot volumes should not be able to delete instances.
• Set expiry dates and rotate. A credential with no expiry is a credential someone will forget about.
• Keep secrets out of code. Store credentials in a secrets manager such as HashiCorp Vault or OpenStack's Barbican, and scan repositories for leaked keys.
• Manage SSH keys the same way. Remove keys for people who have left, and avoid one shared key across a whole team.

Review, revoke, and log: an October IAM checklist

Access tends to grow and rarely shrinks. People change roles, contractors finish projects, and test accounts outlive their tests. A regular review keeps permissions matched to reality.

• List every role assignment in each project and domain (openstack role assignment list --names)
• Confirm every admin assignment belongs to a named person who still needs it
• Disable accounts for anyone who has left the company or finished their engagement
• Confirm MFA is enforced for all admin and production users
• List application credentials and revoke any that are unused, unowned, or have no expiry
• Remove local accounts that should be federated through your identity provider
• Confirm audit logging is on and someone reviews it. OpenStack services can emit audit events in the CADF format, which can be forwarded to your SIEM.
• Tie offboarding to HR: access removal should happen the same day someone leaves, not at the next review
• Put the next review on the calendar, quarterly at minimum.