Zero Trust Versus Identity Providers

(Day 13 of 22 in our Cybersecurity Awareness Month series. Today: zero trust and identity)

Zero trust might be the most overused phrase in security marketing. Products claim to deliver it, architectures claim to embody it, and people ask for it because someone asked them if they have implemented it. Along the way, a lot of people came to believe that putting an identity provider in front of everything and turning on multifactor authentication (MFA) is the same thing as zero trust. Not quite.

An identity provider is a big part of zero trust, though, and a good one. It’s also a single system that everything depends on and that every attacker wants to control, because the group memberships it hands out usually drive authorization, too. And when you compromise a system like that, you can control everything else that trusts it.

Identity providers are a big part of security when it comes to VMware Cloud Foundation (VCF), so let’s look at them through the lens of zero trust.

What Zero Trust Actually Wants

A great place to start is NIST’s definition of zero trust. Zero trust “is not a single architecture but a set of guiding principles,” built on the idea that no user or system should be trusted automatically “based solely on their physical or network location” (NIST SP 800-207). Among its tenets: access is granted one session at a time, authentication and authorization are “dynamic and strictly enforced before access is allowed,” and the organization monitors the security posture of everything it owns. CISA’s Zero Trust Maturity Model organizes the work into five pillars: identity, devices, networks, applications and workloads, and data (CISA).

Identity is one pillar of five. NIST also points out that the components making zero trust decisions become targets themselves: an administrator with access to them may be able to make unapproved changes, and disrupting them disrupts everything that relies on them. That part tends to get lost when zero trust turns into a product category.

Identity Providers and VCF

VCF makes it straightforward to connect the platform to an identity provider. The federated identity features of the VCF Identity Broker provide single sign-on for vCenter, NSX, VCF Operations, VCF Automation, and other components. VCF supports SAML identity providers, Active Directory, LDAP, and OpenID Connect providers. Federation is the preferred way to authenticate to vCenter, and MFA comes from the identity provider, so you have a lot of options, from more basic 2FA to things like passkeys and hardware devices like YubiKeys. That’s a real improvement over a separate password for every console. A few details are worth planning for:

• Local accounts still exist for administration and recovery, like root on ESX and vCenter, the vCenter single sign-on administrator, and local accounts on NSX, VCF Operations, and other appliances (accounts). They need strong, managed passwords and close monitoring, and VCF Operations can manage many of those passwords for you.
• Choose the single sign-on model with the blast radius in mind. Broadcom’s design guidance notes that an impact to a fleet-wide VCF Identity Broker affects the entire VCF fleet (design). Giving each VCF instance its own identity broker limits an outage to that instance, at the cost of more appliances to manage and a separate sign-in for each instance (single-instance model). Our Identity and Access Management Best Practices whitepaper covers the broker’s deployment modes and how to test for its failure.

The Identity Provider Is a Dependency and a Target

Centralizing identity concentrates risk. NSA and CISA describe the availability side of it bluntly: “If SSO fails, access to all related systems is lost” (NSA and CISA). The VCF Security Configuration Guide is just as plain about the security side: “Centralized identity providers (IdPs) are themselves high-value attacker targets, and a single compromise of the IdP yields privileged access to every system that federates to it.”

Attackers have noticed. Identity providers, and the people and processes around them, are targeted again and again:

• Attackers have talked service desks into resetting MFA for administrator accounts, then added an identity provider of their own to impersonate users (report).
• An identity vendor’s support system was breached through a service account, exposing files that customers had shared with support, some of which held session tokens that were then used to hijack sessions at several customers (report).
• A joint advisory from the FBI, CISA, and their partners describes a group that gets passwords and MFA reset through help desks, adds federated identity providers to victims’ single sign-on tenants, and encrypts ESX servers (advisory).

Infrastructure is part of that pattern. Threat researchers describe attackers going from a help desk call to control of vCenter in hours, and point out that vCenter logins backed by Active Directory often lack MFA (report). If one identity system controls both the corporate desktop and the hypervisor, compromising it once is enough.

Build a Separate Identity Boundary for Infrastructure

Broadcom’s guidance is to give infrastructure its own identity boundary. The VCF Security Configuration Guide recommends using “an identity source dedicated to infrastructure administration rather than the general-purpose corporate directory,” and Broadcom’s identity design guidance explains the reasoning in detail (identity best practices). Threat researchers suggest the same thing, recommending a separate identity provider for infrastructure (report).

In practice, that looks like:

• A dedicated identity provider, or a dedicated tenant, for infrastructure administrators, with its own administrators, its own help desk process, and no trust relationship with the corporate directory that would let a compromise there flow into VCF.
• Separate accounts for infrastructure administration, used only for that work, ideally from privileged access workstations. NSA and CISA recommend separate user and administrative accounts, and phishing-resistant MFA for privileged users.
• Phishing-resistant MFA, like FIDO2 security keys, for every infrastructure administrator. The FBI and CISA recommend it because attackers have become good at talking their way past other kinds.
• vCenter permissions granted through local VCF single sign-on groups, so that, in the words of the guide, “an AD compromise alone does not grant vCenter administration.”
• No help desk resets for infrastructure accounts over the phone. Make recovery for those accounts deliberately slow, ideally in person, and when it can’t be, verify the person with a callback to a number you already had on file.

Microsoft’s privileged access model describes the same idea, where the control plane is protected so that nothing in a lower tier can control it (Microsoft). The hypervisor and its management belong in that control plane, because whoever controls them controls every workload on top, domain controllers included.

Have a Plan for the Identity Provider Being Down

Every identity provider has a bad day eventually, whether from an outage, a misconfiguration, or an attack. When that happens, you still need to run and fix your infrastructure, so plan for access that doesn’t depend on it:

• Keep break-glass accounts, like the vCenter single sign-on administrator and the local administrator accounts on each component, with long random passwords stored offline or in a vault that doesn’t depend on the identity provider or on the infrastructure it protects.
• Monitor those accounts closely. Their use should be rare, so every login is worth an alert. You can set alerts for this usage in VCF Log Management.
• Know the dependencies. If the identity provider runs on the infrastructure it authenticates, or depends on DNS and Active Directory that do, a bad day can turn into a worse one. The same technologies that make workloads mobile and resilient, like vMotion, Storage vMotion, and VCF Operations HCX, can also make it possible to create a dependency loop by accident. Take an hour and map these things out ahead of time so you know what state you are in.
• Test it. Practice logging in with the break-glass accounts, on a schedule, before you need them. Tabletop exercises are a great way to work through an incident with your team, think about what you might need to recover, and get everyone on the same page about how that would look.

VCF 9.1 also adds emergency access clients, which provide API access with the highest role and largest scope for emergencies (docs). Treat their tokens like any other break-glass credential, because that’s what they are.

Trust, but Limit the Blast Radius

Zero trust still involves trust. Somebody has to vouch for identities, and somebody has to run the systems that check them. Zero trust asks you to be deliberate about whom you trust, to give each trusted system as little power as possible, and to make sure that when one of them fails, it doesn’t take everything else down with it.

For VCF, that means an identity boundary for infrastructure that’s separate from everything else, phishing-resistant MFA, break-glass access that works when the identity provider doesn’t, and logging that watches all of it.