docs/documentation/guides/governance-models.mdx
Organizations adopt different approaches to secrets management governance based on their security requirements, compliance obligations, and team structures. Infisical supports a spectrum of governance models—from fully centralized platform administration to team-driven self-service.
This guide covers how to configure Infisical for different governance approaches and what tradeoffs to consider.
Most organizations don't operate at the extremes. Instead, they land somewhere on a spectrum between two models:
Centralized Administration: A dedicated platform or security team controls project creation, access policies, integrations, and secret lifecycle management. Application teams consume secrets but don't manage the underlying infrastructure.
Self-Service: Teams have autonomy to create projects, manage their own access, configure integrations, and operate independently. Central teams provide guardrails and standards rather than direct management.
<Note> The right model depends on your regulatory environment, team maturity, organizational scale, and security posture. Highly regulated industries often lean toward centralized control, while organizations with mature DevOps practices may benefit from self-service with guardrails. </Note>Project and environment structure is where governance decisions start to take shape.
| Approach | Centralized | Self-Service |
|---|---|---|
| Project creation | Platform team creates all projects on behalf of application teams | Teams create their own projects as needed |
| Naming conventions | Enforced through process and templates | Documented standards, team-enforced |
| Folder structure | Predefined conventions (e.g., /apps/{app-name}/{component}) | Teams define hierarchies that fit their needs |
Project Templates allow you to define standard environments, roles, and settings that are applied when creating new projects. This feature supports both governance models:
Environments define the deployment stages where secrets are managed.
dev, staging, prod) provide consistency and simplify cross-team collaborationqa, uat, perf-test, prod-eu, prod-us)With Project Templates, you can enforce a base set of environments while optionally allowing teams to add additional ones.
How you manage identity—both for users and machines—significantly affects your governance strategy.
| Approach | Centralized | Self-Service |
|---|---|---|
| Login methods | SSO enforced, local accounts disabled | SSO available, local accounts permitted |
| MFA | Required organization-wide | Encouraged or optional |
| Session duration | Short sessions enforced | Longer sessions permitted |
Infisical supports multiple authentication methods that can be configured based on your requirements:
| Approach | Centralized | Self-Service |
|---|---|---|
| User onboarding | Automatic via SCIM from identity provider | Direct invitations by project admins |
| Role assignment | Mapped from IdP groups | Assigned manually per project |
| Offboarding | Automatic deprovisioning via SCIM | Manual removal required |
SCIM provisioning enables automatic user lifecycle management synced with your identity provider. Combined with group mappings, you can automatically assign organization roles based on IdP group membership.
For organizations using SAML, group membership mapping synchronizes group memberships when users log in, ensuring access reflects current IdP state.
Machine identities authenticate applications, services, and automated systems with Infisical. Your governance model shapes how these identities are managed:
| Approach | Centralized | Self-Service |
|---|---|---|
| Identity creation | Platform team creates all identities; teams submit requests | Teams create identities for their own projects |
| Auth method selection | Standardized methods enforced (e.g., "Kubernetes Auth only in production") | Teams choose methods appropriate to their infrastructure |
| Credential management | Platform team manages and distributes credentials | Teams manage their own identity credentials |
Infisical supports multiple machine identity authentication methods:
Centralized organizations often standardize on platform-native authentication methods (Kubernetes Auth, cloud provider auth) to eliminate static credentials, while self-service models may permit Universal Auth for flexibility.
Infisical's role-based access control operates at two levels: organization and project. How you configure these controls determines who can do what across your secrets infrastructure.
Organization roles govern access to organization-wide resources like billing, member management, and identity provider configuration.
| Role | Capabilities |
|---|---|
| Admin | Full access to all organization settings and all projects |
| Member | Basic organization access; project access determined separately |
| Custom roles | Tailored permissions for specific administrative functions |
Project roles control what users and machine identities can do within a specific project.
| Approach | Centralized | Self-Service |
|---|---|---|
| Role definition | Custom roles defined by platform team; teams assigned predefined roles | Teams create project-level custom roles as needed |
| Production access | Restricted to specific roles; requires approval | Teams determine their own access patterns |
| Role assignment | Managed through groups synced from IdP | Project admins assign roles directly |
Built-in project roles include:
Custom roles let you define granular permissions for specific environments, folder paths, and actions—useful for implementing least-privilege access.
Groups simplify access management by allowing you to assign roles to collections of users rather than individuals.
Key behaviors:
| Approach | Centralized | Self-Service |
|---|---|---|
| Group management | Groups defined in IdP, synced via SCIM | Project admins create and manage local groups |
| Project membership | Controlled through IdP group assignments | Direct group/user additions by project admins |
For sensitive environments, both governance models benefit from time-limited access:
Centralized organizations typically require temporary access for production environments, while self-service models may use it selectively for high-risk operations.
Approval workflows add oversight to sensitive operations, supporting compliance requirements and change management practices.
Change policies require approval before secrets can be modified in specific environments or folder paths. When a policy applies, proposed changes enter a review queue where designated approvers can approve and merge—or reject—the changes.
| Approach | Centralized | Self-Service |
|---|---|---|
| Policy scope | Required for all production environments | Teams define policies for their sensitive environments |
| Approvers | Security team members or designated reviewers | Team leads or senior engineers |
| Bypass permissions | Strictly limited | May allow emergency bypass for on-call |
Access requests formalize the process of granting access to sensitive resources. Combined with temporary access, this enables just-in-time access patterns where users request and receive time-limited permissions.
| Approach | Centralized | Self-Service |
|---|---|---|
| Request requirement | Mandatory for production access | Optional or environment-specific |
| Approval workflow | Formal review by security team | Peer approval or team lead sign-off |
| Access duration | Strictly time-limited | Flexible based on need |
Approval workflows integrate with Slack and Microsoft Teams to notify approvers in real-time, reducing delays in the approval process.
Who creates, rotates, and retires secrets—and how—depends on your governance model.
App Connections are reusable integrations with third-party platforms like AWS, GCP, Azure, databases, and other services. They're required for secret rotation, dynamic secrets, and secret syncs—so how you manage them affects multiple workflows.
| Approach | Centralized | Self-Service |
|---|---|---|
| Connection creation | Platform team creates connections at the organization level and distributes access to projects | Teams create their own connections at the project level |
| Credential management | Platform team manages service accounts and API keys used by connections | Teams manage credentials for their own connections |
| Access distribution | Connections shared across multiple projects as needed | Each team maintains their own set of connections |
| Approach | Centralized | Self-Service |
|---|---|---|
| Shared secrets | Platform team provisions infrastructure secrets (databases, APIs) | Teams request or create their own |
| Application secrets | Teams manage within their designated paths | Teams have full ownership |
| Secret standards | Naming conventions and metadata requirements enforced | Guidelines provided, team-enforced |
Secret rotation automates credential lifecycle management, reducing the risk of long-lived secrets.
| Approach | Centralized | Self-Service |
|---|---|---|
| Rotation policies | Defined and managed by platform team | Teams configure for their services |
| Rotation schedules | Standardized intervals based on secret classification | Teams determine appropriate intervals |
Dynamic secrets generate short-lived credentials on demand, eliminating standing access to sensitive systems.
| Approach | Centralized | Self-Service |
|---|---|---|
| Configuration | Platform team sets up dynamic secret sources | Teams configure for their databases and services |
| Lease duration | Standardized TTLs based on use case | Teams determine appropriate durations |
| Access control | Restricted to specific roles | Available to authorized team members |
Secret referencing and imports allow secrets to be shared across environments and folders within the same project. This helps reduce duplication when the same secret is needed in multiple environments.
| Approach | Centralized | Self-Service |
|---|---|---|
| Reference patterns | Standardized import structures across projects | Teams define their own reference hierarchies |
| Base environment | Platform team designates source environments for imports | Teams choose which environments to reference from |
Infisical offers multiple methods for delivering secrets to applications and infrastructure.
Secret Syncs push secrets to third-party platforms like AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, and others. Syncs keep external secret stores updated when values change in Infisical.
| Approach | Centralized | Self-Service |
|---|---|---|
| Sync setup | Platform team configures syncs to approved destinations | Teams configure syncs for their projects |
| Target platforms | Limited to approved platforms | Teams choose appropriate destinations |
| Sync scope | Standardized patterns (e.g., sync prod to AWS SM only) | Teams determine what to sync and where |
For Kubernetes environments, two primary integration patterns are available:
| Approach | Centralized | Self-Service |
|---|---|---|
| Operator deployment | Single cluster-wide instance managed by platform team | Teams may deploy namespace-scoped instances |
| Secret sync patterns | Standardized CRD configurations | Teams define their own InfisicalSecret resources |
The Infisical Agent and CLI provide flexible secret consumption patterns:
| Approach | Centralized | Self-Service |
|---|---|---|
| Agent deployment | Managed by platform team as infrastructure | Teams deploy and configure their own agents |
| CLI usage | Standardized configurations provided | Teams use CLI as needed in their workflows |
Gateways enable Infisical to securely access private resources—such as databases in isolated VPCs—without exposing them to the public internet. Gateways are lightweight components deployed within your private network that establish secure, outbound-only connections to Infisical.
Gateways are essential for features that require direct access to private infrastructure:
Gateways operate at two levels within Infisical:
Organization-level registration: Gateways are registered and visible in Organization Settings → Access Control → Gateways. This provides central visibility into all gateway infrastructure.
Project-level linking: When configuring features like dynamic secrets, teams select from available gateways to route requests through private networks.
This architecture naturally supports a hybrid governance model where infrastructure teams manage gateway deployment while application teams consume them.
| Approach | Centralized | Self-Service |
|---|---|---|
| Gateway deployment | Platform/infrastructure team deploys gateways in shared network zones | Teams deploy gateways in their own VPCs or network segments |
| Machine identity management | Platform team creates and manages identities used by gateways | Teams create identities for gateways they deploy |
| Network configuration | Central team manages firewall rules and network connectivity | Teams responsible for their own network access |
| Gateway selection | Platform team links gateways to projects | Teams select from available gateways when configuring features |
Shared Gateway Model (Centralized)
A platform team deploys gateways in shared network zones that can reach common infrastructure (e.g., a central database cluster). Multiple projects link to these shared gateways, reducing deployment overhead and centralizing network management.
This pattern works well when:
Team-Owned Gateway Model (Self-Service)
Each team deploys gateways within their own network boundaries (e.g., per-team VPCs or Kubernetes namespaces). Teams manage the full lifecycle of their gateways, including the machine identities that authenticate them.
This pattern works well when:
Hybrid Model
Platform team deploys and registers gateways, but application teams independently select which gateway to use when configuring dynamic secrets or rotation. This provides central oversight of infrastructure while giving teams flexibility in how they use it.
For Kubernetes environments, gateways can also serve as token reviewers for Kubernetes Auth, eliminating the need for long-lived service account tokens. In this scenario, the gateway deployment often aligns with whoever manages the Kubernetes cluster.
Visibility into secrets access and changes is critical for security and compliance. Infisical provides audit capabilities at both organization and project levels.
Audit logs capture all platform activity including secret access, modifications, and administrative actions.
| Level | Scope | Typical Access |
|---|---|---|
| Organization | All activity across all projects | Security team, compliance officers |
| Project | Activity within a specific project | Project admins, team leads |
| Approach | Centralized | Self-Service |
|---|---|---|
| Log access | Security team has organization-wide visibility | Teams access only their project logs |
| Log retention | Centrally managed retention policies | Platform-defined retention |
| Compliance reporting | Platform team generates reports | Teams may generate their own project reports |
Audit log streaming exports logs to external systems for long-term retention and analysis.
Supported destinations include:
| Approach | Centralized | Self-Service |
|---|---|---|
| Stream configuration | Platform team manages all log streams | N/A (organization-level feature) |
| SIEM integration | Centralized security monitoring | Teams may not have direct SIEM access |
Beyond access control, Infisical offers additional security settings.
Organization-level security policies allow you to enforce:
Restrict API and dashboard access to specific IP ranges, useful for:
| Feature | Description | Governance Consideration |
|---|---|---|
| External KMS | Integrate with AWS KMS, GCP KMS, or Azure Key Vault | Centralized key management |
| BYOK | Bring your own encryption keys | Enterprise key management policies |
| KMIP | Connect to KMIP-compatible HSMs | Hardware-backed security requirements |
These features are typically managed centrally regardless of overall governance model, as encryption infrastructure requires specialized expertise.
A few factors tend to push organizations toward one end of the spectrum or the other:
Most organizations benefit from a hybrid model that combines central guardrails with team autonomy:
Platform team responsibilities:
Application team responsibilities:
This balances compliance requirements with team velocity—central teams handle the infrastructure and guardrails, while application teams own their day-to-day secrets operations.
Organizations often begin with centralized control and gradually extend autonomy as teams demonstrate security maturity:
Organizations scaling from startup to enterprise may need to add centralization:
Regardless of model, invest in:
Here's a quick reference for how key Infisical features map to each governance model:
| Feature | Centralized Use | Self-Service Use |
|---|---|---|
| Project Templates | Enforce standards | Provide starting points |
| SCIM | Automate user lifecycle | Supplement direct invitations |
| Groups | IdP-synced membership | Local team management |
| Custom Roles | Define organization-wide | Create project-specific |
| Approval Workflows | Require for all changes | Apply selectively |
| App Connections | Org-level connections distributed to projects | Teams create project-level connections |
| Secret Syncs | Platform-managed syncs to approved destinations | Teams configure their own syncs |
| Gateways | Shared infrastructure for private access | Team-deployed per network zone |
| Audit Logs | Centralized monitoring | Project-level visibility |
Most organizations land somewhere in between—central control over identity, policies, and infrastructure with team ownership of secrets and integrations. You can start at either end of the spectrum and adjust as your needs change.