docs/internals/security.mdx
As a security infrastructure platform dealing with highly-sensitive data, Infisical follows a robust security model with the goal of ensuring the security and integrity of all its managed data and associated components.
As part of the security model, data at rest and in transit must be secure from eavesdropping or tampering, clients must be authenticated and authorized to access data, and all operations in the platform are audited and can be traced back to their source.
This page documents security measures used by Infisical, the software, and Infisical Cloud, a separate managed service offering for the software.
Infisical’s (the software) threat model spans communication, storage, response mechanisms, and more.
Infisical (the software) does not consider the following as part of its threat model:
Note that while these points fall outside the Infisical’s threat model, they remain considerations in the broader platform architecture.
Infisical’s architecture consists of various systems which together we refer to as the Infisical platform:
The server requires clients to be authenticated and authorized for every inbound request. If using Infisical Cloud, all traffic is routed through Cloudflare which enforces TLS and requires a minimum of TLS 1.2.
The server mandates that each request includes a valid token (issued for a user or machine identity) used to identify the client before performing any actions on the platform. Clients without a valid token can only access login endpoints with the exception of a few intentionally unauthenticated endpoints. For tokens issued for machine identities, Infisical provides significant configuration, including support for native authentication methods (e.g. AWS, Azure, Kubernetes, etc.); custom TTLs to restrict token lifespan; IP restrictions to enforce network-based access controls; and usage caps to limit the maximum number of times that a token can be used.
When accessing Infisical via web browser, JWT tokens are stored in browser memory and appended to outbound requests requiring authentication; refresh tokens are stored in HttpOnly cookies and included in requests as part of token renewal. Note also that Infisical utilizes the latest HTTP security headers and employs a strict Content-Security-Policy to mitigate XSS.
To mitigate abuse and enhance system stability, the server enforces configurable rate limiting on read, write, and secrets operations. This prevents excessive API requests from impacting system performance while ensuring fair usage across clients.
Once traffic enters the server, any sensitive data (e.g. secrets, certificates entering the server), where applicable, is encrypted using a 256-bit Advanced Encryption Standard (AES) cipher in the Galois Counter Mode (GCM) with 96-bit nonces prior to being persisted in the storage backend. Encryption is an integral part of Infisical’s platform-wide cryptographic architecture, which also supports seal-wrapping with external KMS and HSMs. Before responding to a client request, the server securely retrieves and decrypts requested data from the storage backend. Each decryption operation includes integrity verification to ensure data has not been altered or tampered with.
Within Infisical, an internal threat and critical security concern is an attacker gaining access to sensitive data that they are not permitted to, especially if they are able to authenticate with some degree of access to the system.
Before a client can perform any actions on the platform, it must authenticate with the server using a supported authentication method such as username-password, SAML, SSO, LDAP, AWS/GCP/Azure, OIDC, or Kubernetes authentication. A successful authentication results in the issuance of a client (JWT) token containing a reference to the user or machine identity bound to it.
When a client uses the token to make authenticated requests against the server, Infisical validates the token and maps the bound-identity to access control policies that exist at the organization and project level, both types of namespaces within the platform. The access control policies are configured by operators of Infisical ahead of time and may involve role-based, attribute-based, and one-off “additional privilege” resource constraints. Given the robustness of the access control system, we recommend reading the full documentation for it.
For example, an operator of Infisical may define the following constraints to restrict client access to particular resources:
All symmetric encryption operations in Infisical, with the exception of those proxied through External KMS and HSM systems, use a software-backed 256-bit Advanced Encryption Standard (AES) cipher in Galois Counter Mode (GCM) with 96-bit nonces, AES-256-GCM. This authenticated encryption scheme provides both confidentiality and integrity guarantees for all encrypted data.
Infisical employs a multilayer encryption architecture where keys are organized hierarchically. Each layer encrypts the layer below it, ensuring that accessing any sensitive data requires both server configuration (the root encryption key) and data from the storage backend. This defense-in-depth approach means that compromising the database alone is insufficient to decrypt sensitive data.
The following diagram illustrates Infisical's key hierarchy, showing how encryption keys are organized and how they protect data at different levels of the platform.
%%{init: {
'theme': 'base',
'themeVariables': {
'primaryColor': '#ECF26D',
'primaryTextColor': '#000000',
'primaryBorderColor': '#000000',
'lineColor': '#000000',
'secondaryColor': '#F5F5F5',
'tertiaryColor': '#FFFFFF',
'background': '#FFFFFF',
'mainBkg': '#FFFFFF',
'nodeBorder': '#000000',
'clusterBkg': '#FAFAFA',
'clusterBorder': '#000000',
'titleColor': '#000000',
'edgeLabelBackground': '#FFFFFF'
}
}}%%
flowchart LR
subgraph INSTANCE["Infisical Instance"]
direction LR
subgraph LAYER1[" "]
ROOT["<b>Root Encryption Key</b>
<i>256-bit AES</i>
<i>Environment Variable</i>"]
end
subgraph LAYER2[" "]
INTERNAL["<b>Internal KMS Root Key</b>
<i>Created on first startup</i>"]
end
subgraph LAYER3["Tenant Keys"]
direction TB
ORG["<b>Organization Data Key</b>
<i>One per organization</i>"]
PROJ["<b>Project Data Key</b>
<i>One per project</i>"]
end
subgraph LAYER4["Encrypted Data"]
direction TB
ORGDATA["<b>Organization Data</b>
<i>SSO, SCIM, Settings</i>"]
PROJDATA["<b>Project Data</b>
<i>Secrets, Certs, Creds</i>"]
end
ROOT -->|"encrypts"| INTERNAL
INTERNAL -->|"encrypts"| ORG
INTERNAL -->|"encrypts"| PROJ
ORG -->|"encrypts"| ORGDATA
PROJ -->|"encrypts"| PROJDATA
end
classDef rootKey fill:#ECF26D,stroke:#000000,stroke-width:2px,color:#000000
classDef internalKey fill:#E2E89E,stroke:#000000,stroke-width:2px,color:#000000
classDef entityKey fill:#F0F4C3,stroke:#000000,stroke-width:1px,color:#000000
classDef data fill:#FAFAFA,stroke:#000000,stroke-width:1px,color:#000000
classDef invisible fill:none,stroke:none
class ROOT rootKey
class INTERNAL internalKey
class ORG,PROJ entityKey
class ORGDATA,PROJDATA data
class LAYER1,LAYER2 invisible
The root encryption key is a 256-bit AES key provided by the operator as an environment variable. This key is the foundation of Infisical's encryption architecture and never leaves the server's memory during operation.
Key characteristics:
The root encryption key can alternatively be sourced from an external Hardware Security Module (HSM) such as Thales Luna HSM or AWS CloudHSM, providing additional security guarantees, and removing the need for the operator to store the root encryption key in an environment variable.
The Internal KMS Root Key is automatically generated when an Infisical instance starts for the first time. This key serves as an intermediate layer between the operator-provided root key and tenant-specific data keys.
Key characteristics:
This separation ensures that the operator-provided root key is only used to protect a single key (the Internal KMS Root Key), limiting its exposure during cryptographic operations.
Data keys are the encryption keys that directly protect sensitive data within Infisical. Each organization and each project has its own dedicated data key, providing cryptographic isolation between tenants.
Organization Data Keys protect organization-level sensitive data, including:
Project Data Keys protect project-level sensitive data, including:
Key characteristics:
Project data keys can optionally be managed by an external KMS instead of the Internal KMS Root Key, allowing organizations to maintain control over their encryption keys. See External KMS Integration for more details.
1. **Key Retrieval**: The appropriate data key (organization or project) is retrieved from the database in its encrypted form.
2. **Key Decryption**: The encrypted data key is decrypted using the Internal KMS Root Key.
3. **Data Encryption**: The plaintext data is encrypted using the decrypted data key with AES-256-GCM and a randomly generated 96-bit nonce.
4. **Storage**: The ciphertext, along with the nonce and authentication tag, is stored in the database.
1. **Key Retrieval**: The appropriate data key (organization or project) is retrieved from the database in its encrypted form.
2. **Key Decryption**: The encrypted data key is decrypted using the Internal KMS Root Key.
3. **Data Retrieval**: The ciphertext, nonce, and authentication tag are retrieved from the database.
4. **Data Decryption**: The ciphertext is decrypted using the decrypted data key with AES-256-GCM, the stored nonce, and the authentication tag. The GCM authentication tag ensures that any tampering with the ciphertext is detected during decryption.
Instead of the Internal KMS Root Key decrypting the project data key, the encrypted data key is sent to the external KMS provider (e.g., AWS KMS, GCP KMS) for decryption. The external KMS performs the key unwrapping operation and returns the plaintext data key, which is then used for the AES-256-GCM encryption/decryption of the actual data. This approach ensures that the project's root of trust lies with the external KMS, giving organizations full control over key access policies and audit logging at the KMS level. </Tip>
All cryptographic keys in Infisical are generated using Node.js's core cryptographic library, which provides cryptographically secure pseudo-random data. When FIPS mode is enabled, this library is guaranteed to use FIPS-validated cryptographic implementations.
For organizations with specific compliance requirements or those who need to maintain control over their encryption keys, Infisical supports integration with external Key Management Systems. When configured, project data keys can be encrypted by an external KMS instead of the Internal KMS Root Key.
Supported external KMS providers include:
For detailed configuration instructions, see the KMS Configuration documentation.
Infisical can be deployed in a FIPS-compliant configuration, using FIPS 140-3 validated cryptographic modules for all encryption operations within the FIPS boundary. When FIPS mode is enabled:
For detailed information on deploying Infisical in FIPS mode, see the FIPS documentation (Enterprise Only).
Infisical Cloud uses a number of strategies to keep services running smoothly and ensure data stays available, even during failures; we document these strategies below:
Infisical Cloud utilizes several strategies to ensure high availability, leveraging AWS services to maintain continuous operation and data integrity.
To handle regional failures, Infisical Cloud keeps backups both within AWS and across cloud providers in GCP updated and ready to take over when needed.
Infisical hires external third parties to perform regular security assessment and penetration testing of the platform.
Most recently, Infisical commissioned cybersecurity firm Cure53 to perform a full-coverage, gray box penetration test against the platform's entire attack surface to identify vulnerabilities according to industry standards (OWASP, ASVS, WSTG, TOP-10, etc.).
Please email [email protected] to request any reports including a letter of attestation for the conducted penetration test.
Whether or not Infisical or your employees can access data in the Infisical instance and/or storage backend depends on many factors how you use Infisical:
It should be noted that, even on Infisical Cloud, it is physically impossible for employees of Infisical to view the values of secrets if users have not explicitly granted Infisical access to their project (i.e. opted out of zero-knowledge).
Please email [email protected] if you have any specific inquiries about employee data and security policies.