Trust Models for Machine Identities in Multi-Tenant Systems

Workload Identity Trust Models in Multi-Tenant Environments

So, you know how a lot of companies these days use multi-tenant environments, right? Basically, it's where multiple customers share the same tech infrastructure. (Multi-tenancy Matters: A 3-part series on security, scale and innovation) This makes managing identities, especially the non-human ones like workloads and machine identities, a real headache. Let's get into what workload identity trust models are and how they actually work in these shared setups.

What is Workload Identity?

Workload identity is just the digital identity given to an app or service running in a cloud environment. (Workload Identity | CyberArk) It's super important for letting different services and resources talk to each other securely. In multi-tenant places, making sure each workload can prove who it is and get permission without messing up other tenants' security is key.

Trust Models in Workload Identity

A trust model is basically how identities get checked and trusted in a system. In multi-tenant environments, there are a few ways to go about this: (Tenancy Models for a Multitenant Solution - Azure Architecture Center)

1. Federated Trust Model
   With this model, workloads can authenticate using external identity providers (IdPs). This means workloads from different tenants can securely access shared stuff without needing to manage a bunch of separate logins. It's like using your Google account to log into another website.

   Example: Google Cloud’s Identity-Aware Proxy (iap) is a good example. It lets workloads authenticate using oauth tokens that are issued by external identity providers, like Google itself, or even other systems like Azure Active Directory or Okta. This is really handy for multi-tenant apps because each tenant can use their own existing identity system to grant access to your app's workloads.

2. Hierarchical Trust Model
   This model sets up a chain of trust. Think of it like a company org chart. A central authority, like a parent account or a main identity management system, manages all the identities and how they relate to each other. Tenants can then trust the identities of workloads in other tenants because they're all part of this established hierarchy.

   Example: AWS Organizations is a great illustration here. It lets you group aws accounts together, creating a hierarchy. You can then share access policies across these accounts. So, if a workload in one account needs to access a resource managed by another account within the same organization, the hierarchical trust model allows this based on the defined policies and the account structure. It's not just about account management; it's about how that structure dictates which workloads (represented by service accounts or IAM roles) are trusted to interact with resources across different parts of the organization.

3. Mutual Trust Model
   Here, workloads from different tenants have to authenticate each other before they can do anything. It's super secure because everyone's checking everyone else, but it can slow things down a bit because of all the back-and-forth authentication.

   Example: In Kubernetes, you can use mutual tls (mTLS) to make sure that services are really who they say they are before they start talking. This is great for ensuring that a workload from tenant A can only talk to a workload from tenant B if they both present valid, trusted certificates.

Comparing Trust Models

Let's expand on those cons a bit. For the Federated model, relying on external services means you're kinda at their mercy. If the external IdP goes down, your workloads might not be able to authenticate. Plus, you've got to trust that the external IdP is keeping those identities secure. In a multi-tenant setup, a breach at an external IdP could potentially impact multiple tenants if not managed carefully.

For the Hierarchical model, the complexity in establishing trust chains really comes into play when you have a lot of tenants, or when those tenant structures get really nested or change often. You have to carefully define who trusts whom at each level, and if you mess up the hierarchy or the policies, you could accidentally grant too much or too little access. It's like trying to manage a massive family tree with complex inheritance rules.

Categories of Workload Identity

• Static Identity: This type of identity is pretty much fixed and doesn't change. It's easy to manage because you set it up once, but it's not very flexible if your workload's needs change a lot. Think of it like a permanent employee ID.
• Dynamic Identity: These identities are created and then destroyed as needed, based on what the workload is doing. This is super flexible, letting workloads get temporary credentials for specific tasks, but it means you need really good systems to manage their creation, rotation, and deletion securely. It's more like a temporary contractor pass.

Real-Life Scenario

Let's picture a cloud provider that hosts a bunch of different apps for various clients. Every app needs to access a shared database.

Using the Federated Trust Model, each app can authenticate using the client’s own identity provider. This keeps things secure and makes it easy for clients to grant access to your app without you managing their user accounts.

Now, here's where the Hierarchical Trust Model comes in to play with the federated part. Imagine the cloud provider has a main account, and then each client has its own sub-account within that. The hierarchical model can enforce policies at the main account level that dictate which federated identities (i.e., which client IdPs) are even allowed to request access to the shared database. For instance, the main account might have a policy that says only workloads authenticated via IdPs from clients in "Tier 1" of the hierarchy can access the production database, while "Tier 2" clients might only get access to a staging version. So, the hierarchy governs the scope of trust granted to the federated identities.

Visualizing the Process

To give you a better idea of how this all fits together in a multi-tenant setup, here’s a more detailed look at the authentication flow:

This shows how workloads from different tenants (Tenant A, Tenant B) interact with a central identity provider. The identity provider might use federation to verify the workload's identity, and then a trust decision is made, potentially influenced by hierarchical policies that dictate what each tenant's workloads are allowed to do with the shared resource.

In short, getting a handle on these workload identity trust models is pretty darn important for keeping things secure in multi-tenant environments. Each model has its good points and its not-so-good points, and you usually pick the one that best fits what you're trying to do.