User and Machine Identities

To interact with secrets and resource with Infisical, it is important to understand the concept of identities. Identities can be of two types:

• People (e.g., developers, platform engineers, administrators)
• Machines (e.g., machine entities for managing secrets in CI/CD pipelines, production applications, and more)

Both people and machines are able to utilize corresponding clients (e.g., Dashboard UI, CLI, SDKs, API, Kubernetes Operator) together with allowed authentication methods (e.g., email & password, SAML SSO, LDAP, OIDC, Universal Auth).

​

Calculating Identity Counts

Understanding how to calculate your identity requirements helps with capacity planning and licensing.

​

User Identities

User identity count is straightforward—it equals the number of human users who need access to Infisical. This includes developers, DevOps/platform engineers, security administrators, and any other team members requiring direct Infisical access.

​

Machine Identities

If you’re familiar with cloud provider IAM concepts, Infisical machine identities work the same way: Just as you don’t create a new IAM role for every EC2 instance or a new service account for every VM, you don’t create a new Infisical machine identity for every machine. Instead, machine identities are permission-based, not machine-based—they represent a unique set of access permissions that can be shared across multiple workloads.

​

How to Calculate Machine Identities

Consider these factors when determining your machine identity count:

​

Examples

Example 1: Multiple VMs with identical access

Scenario: 10 VMs in your production environment all need read access to the same database credentials in prod/database/*.Machine identities needed: 1All VMs share the same permission requirements, so they authenticate using a single machine identity. This is equivalent to having 10 EC2 instances assume the same IAM role.

Example 2: Separate environments

Scenario: You have application servers for staging and production, each needing access to their respective environment’s secrets.Machine identities needed: 2

• 1 identity for staging servers → access to staging/*
• 1 identity for production servers → access to prod/*

Even if you have 20 staging servers and 50 production servers, you only need 2 identities—just as you’d have separate IAM roles for staging vs. production access.

Example 3: CI/CD pipelines with different scopes

Scenario: Your CI/CD system has:

• Build pipelines that need read access to artifact registry credentials
• Deployment pipelines that need read access to cloud provider secrets and database URLs
• Security scanning pipelines that need access to scanning tool API keys

Machine identities needed: 3Each pipeline type has distinct permission requirements, warranting separate identities.

Example 4: Multi-cloud authentication

Scenario: Your application runs across AWS EKS, GCP GKE, and Azure AKS, but all clusters need identical access to the same secrets.Machine identities needed: 1A single machine identity can have multiple authentication methods configured simultaneously. You would attach AWS IAM Auth, GCP IAM Auth, and Azure Auth to the same identity, allowing workloads from any cloud to authenticate to the same permission set.

Example 5: Microservices architecture

Scenario: You have 15 microservices:

• 10 services need access only to shared infrastructure secrets (Redis, message queue)
• 3 services need access to payment processing secrets
• 2 services need access to third-party integration API keys

Machine identities needed: 3Group services by their secret access requirements, not by the number of service instances or replicas.

​

Best Practices

While consolidating machine identities reduces management overhead, more granular identities provide stronger security through least-privilege access and reduced blast radius. The right balance depends on your security requirements.

​

When to Use Separate Identities

Create distinct machine identities to enforce security boundaries between:

​

When Consolidation is Acceptable

Sharing a machine identity across workloads is appropriate when:

• Replicas of the same application — Multiple pods/instances running identical code with identical secret needs
• Stateless workers — Horizontally scaled workers performing the same job
• Tightly coupled services — Services that are deployed together and share a security boundary

​

Kubernetes Best Practices

For Kubernetes environments, we recommend mapping machine identities at the namespace level:

Example: Multi-tenant Kubernetes cluster

Scenario: You have a shared Kubernetes cluster with three teams, each with their own namespace:

• team-payments — handles payment processing
• team-platform — runs shared infrastructure (API gateway, service mesh)
• team-analytics — runs data pipelines

Recommended approach: 3 machine identities

Identity	Namespace	Access
k8s-payments	team-payments	Payment secrets only
k8s-platform	team-platform	Infrastructure secrets only
k8s-analytics	team-analytics	Analytics pipeline secrets only

This ensures that a compromised pod in team-analytics cannot access payment processing credentials, even if an attacker gains cluster-level access.

​

Quick Assessment Questions

When planning your machine identity strategy, consider:

1. What’s the blast radius? If this identity is compromised, what secrets are exposed? Design boundaries to limit damage.
2. Are these workloads in the same trust boundary? Applications that shouldn’t access each other’s data need separate identities.
3. What are your compliance requirements? Regulated workloads may require documented isolation from non-regulated systems.
4. What’s your authentication topology? A single identity can authenticate from multiple sources (Kubernetes + AWS IAM + GCP), so multi-cloud doesn’t necessarily mean multiple identities—but multi-tenant does.