Infisical access control

let’s go step by step through Infisical access control — how it works, how you can use it to protect secrets per environment, team, and microservice.

🔐 1. Access Control Model Overview

Infisical has a role-based access control (RBAC) system that operates at two levels:

Each member’s access can be finely tuned per project and per environment.

 

👥 2. Core Roles and Permissions

🧠 Pro tip: Always create custom roles for production environments to enforce least privilege.

 

🧩 3. Environment-Based Access

Each Infisical Project (e.g., Beza) has multiple environments (dev, staging, prod, etc.).
You can control who can access which environment.

For example:

✅ Use case: Developers can freely modify dev secrets, but prod secrets are locked down to only admins and CI/CD pipelines.

 

🧰 4. Service Tokens (For CI/CD & Kubernetes)

Instead of giving your GitHub Actions or Kubernetes Operator your personal login, Infisical uses Service Tokens.

They can be scoped by:

• Project → e.g., only for “Beza”

• Environment → e.g., only staging

• Secret path → e.g., only /auth or /order

Example (in Dashboard → Access Control → Service Tokens):

🧱 5. Group & Folder-Based Restrictions

If you use folders or nested paths (like /auth, /order, /sell):

• You can assign specific permissions per path.

• e.g.,

  • /auth → Auth Team

  • /order → Order Team

  • /shared → Global DevOps Team

This lets each team only see secrets relevant to their microservice.

 

 

Here’s how I’d structure access for your My microservices (Beza) (auth, order, sell):