Centralized vs. Self-Service Governance

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.

​

Understanding the Spectrum

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.

​

Organizational Structure

Project and environment structure is where governance decisions start to take shape.

​

Project Ownership

​

Project Templates

Project Templates allow you to define standard environments, roles, and settings that are applied when creating new projects. This feature supports both governance models:

• Centralized: Require all projects to use approved templates, ensuring consistent environment structures and role definitions across the organization
• Self-Service: Provide templates as a starting point that teams can build upon, reducing setup time while allowing customization

​

Environment Strategy

Environments define the deployment stages where secrets are managed.

• Standardized environments (e.g., dev, staging, prod) provide consistency and simplify cross-team collaboration
• Custom environments allow teams to model their specific deployment pipelines (e.g., qa, 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.

​

Authentication and Identity

How you manage identity—both for users and machines—significantly affects your governance strategy.

​

User Authentication

Infisical supports multiple authentication methods that can be configured based on your requirements:

• SAML SSO with providers like Okta, Azure AD, Google Workspace, and JumpCloud
• OIDC SSO for standards-based authentication
• LDAP for directory-based authentication

​

User Provisioning

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 Identity Management

Machine identities authenticate applications, services, and automated systems with Infisical. Your governance model shapes how these identities are managed: Infisical supports multiple machine identity authentication methods:

• Universal Auth — Client ID/secret authentication for any environment
• Kubernetes Auth — Native authentication using Kubernetes service accounts
• AWS Auth — Authentication using AWS IAM roles
• Azure Auth — Authentication using Azure managed identities
• GCP Auth — Authentication using GCP service accounts
• OIDC Auth — Authentication using OIDC identity tokens

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.

​

Access Control

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-Level Roles

Organization roles govern access to organization-wide resources like billing, member management, and identity provider configuration.

​

Project-Level Roles

Project roles control what users and machine identities can do within a specific project. Built-in project roles include:

• Admin: Full access to all environments, folders, secrets, and project settings
• Developer: Standard access with restrictions on project administration and policy management
• Viewer: Read-only access to secrets and project resources

Custom roles let you define granular permissions for specific environments, folder paths, and actions—useful for implementing least-privilege access.

​

Groups

Groups simplify access management by allowing you to assign roles to collections of users rather than individuals. Key behaviors:

• Adding a group to a project grants all group members access with the assigned role(s)
• Users inherit composite permissions from all groups they belong to
• Group membership can be managed locally or synced from your identity provider via SCIM

​

Temporary and Just-in-Time Access

For sensitive environments, both governance models benefit from time-limited access:

• Temporary access grants permissions that automatically expire after a defined period
• Additional privileges allow temporary elevation beyond a user’s base role

Centralized organizations typically require temporary access for production environments, while self-service models may use it selectively for high-risk operations.

​

Approval Workflows

Approval workflows add oversight to sensitive operations, supporting compliance requirements and change management practices.

​

Change Policies

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.

​

Access Requests

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.

​

Notifications

Approval workflows integrate with Slack and Microsoft Teams to notify approvers in real-time, reducing delays in the approval process.

​

Secret Lifecycle

Who creates, rotates, and retires secrets—and how—depends on your governance model.

​

App Connections

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.

​

Secret Creation and Ownership

​

Secret Rotation

Secret rotation automates credential lifecycle management, reducing the risk of long-lived secrets.

​

Dynamic Secrets

Dynamic secrets generate short-lived credentials on demand, eliminating standing access to sensitive systems.

​

Secret Referencing Within Projects

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.

​

Integrations and Secret Delivery

Infisical offers multiple methods for delivering secrets to applications and infrastructure.

​

Secret Syncs

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.

​

Kubernetes Integration

For Kubernetes environments, two primary integration patterns are available:

• Infisical Kubernetes Operator — Syncs secrets to Kubernetes Secrets resources
• Infisical Secrets Injector — Injects secrets directly into pods at runtime

​

Agent and CLI

The Infisical Agent and CLI provide flexible secret consumption patterns:

​

Gateways

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:

• Dynamic secrets for databases in private networks
• Secret rotation for credentials stored in isolated systems
• Kubernetes Auth token review for private clusters

​

Gateway Architecture

Gateways operate at two levels within Infisical:

1. Organization-level registration: Gateways are registered and visible in Organization Settings → Access Control → Gateways. This provides central visibility into all gateway infrastructure.
2. 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.

​

Governance Considerations

​

Common Patterns

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:

• Multiple applications share common database infrastructure
• Network access is controlled by a central team
• You want to minimize the number of gateway deployments to manage

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:

• Teams have isolated network environments
• Teams have infrastructure expertise to deploy and maintain gateways
• Strict network segmentation requires dedicated gateways per team

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.

​

Audit and Compliance

Visibility into secrets access and changes is critical for security and compliance. Infisical provides audit capabilities at both organization and project levels.

​

Audit Logs

Audit logs capture all platform activity including secret access, modifications, and administrative actions.

​

Audit Log Streaming

Audit log streaming exports logs to external systems for long-term retention and analysis. Supported destinations include:

• SIEM platforms (Splunk, Datadog, Elastic)
• Cloud storage (AWS S3, Azure Blob Storage)
• Log aggregators (Better Stack, generic HTTP endpoints)

​

Security Controls

Beyond access control, Infisical offers additional security settings.

​

Security Policies

Organization-level security policies allow you to enforce:

• MFA requirements for all users
• Session duration limits
• Login restrictions

​

IP Access Controls

Restrict API and dashboard access to specific IP ranges, useful for:

• Limiting production access to corporate networks or VPNs
• Restricting machine identity authentication to known infrastructure IPs

​

Encryption and Key Management

These features are typically managed centrally regardless of overall governance model, as encryption infrastructure requires specialized expertise.

​

Choosing Your Model

A few factors tend to push organizations toward one end of the spectrum or the other:

​

Factors Favoring Centralized Control

• Regulatory requirements: SOC 2, HIPAA, PCI-DSS, and similar frameworks often require demonstrated control over secrets management
• Limited security expertise: When application teams lack security experience, central management reduces risk
• Consistency requirements: Large organizations benefit from standardized patterns across teams
• High-risk environments: Financial services, healthcare, and government contexts often require strict oversight

​

Factors Favoring Self-Service

• Mature DevOps culture: Teams with strong security awareness can manage their own secrets responsibly
• Speed of delivery: Self-service reduces bottlenecks and accelerates development cycles
• Diverse technology stacks: Teams using different platforms benefit from flexibility in integration choices
• Distributed organizations: Global teams may need autonomy to operate across time zones

​

The Hybrid Approach

Most organizations benefit from a hybrid model that combines central guardrails with team autonomy: Platform team responsibilities:

• SSO and SCIM configuration
• Project template creation and maintenance
• Organization-wide security policies
• Audit log streaming and compliance reporting
• Approval workflow policies for production environments
• Shared infrastructure secrets (databases, external APIs)

Application team responsibilities:

• Project creation (from approved templates)
• Application-specific secret management
• Integration configuration within their projects
• Team-level access control within policy bounds
• Secret rotation for team-owned credentials

This balances compliance requirements with team velocity—central teams handle the infrastructure and guardrails, while application teams own their day-to-day secrets operations.

​

Implementation Considerations

​

Starting Centralized, Moving to Self-Service

Organizations often begin with centralized control and gradually extend autonomy as teams demonstrate security maturity:

1. Phase 1: Platform team manages all aspects; teams consume secrets via provided integrations
2. Phase 2: Teams gain ability to manage secrets within their projects; platform team controls project creation and policies
3. Phase 3: Teams can create projects from templates and configure integrations; platform team focuses on guardrails and compliance

​

Starting Self-Service, Adding Controls

Organizations scaling from startup to enterprise may need to add centralization:

1. Phase 1: Establish SSO and basic security policies
2. Phase 2: Introduce project templates and approval workflows for production
3. Phase 3: Implement SCIM provisioning and comprehensive audit streaming

​

Documentation and Training

Regardless of model, invest in:

• Clear documentation of secrets management standards and processes
• Training for teams on Infisical features and security best practices
• Runbooks for common operations (secret rotation, access requests, incident response)

​

Summary

Here’s a quick reference for how key Infisical features map to each governance model: 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.