RBAC, secrets, and hardening

Envoy combines application role checks with encrypted secret storage and deployment isolation. Production security still depends on TLS, network policy, host controls, identity-provider policy, and operational discipline.

Role-based access

Envoy has three built-in roles:

• superadmin — manages admins and viewers and has full product mutation access;
• admin — operates product resources and can manage viewers;
• viewer — read-oriented product access.

Admins and superadmins can create and run tasks and jobs, manage connectors and triggers, edit dashboards, configure metrics, and use write-capable Data Explorer methods. Viewers can inspect supported resources and use read paths.

Do not use the viewer role as a substitute for data-source authorization. If a viewer can query a connector through an allowed read path, the connector credential determines what the upstream service returns.

Authentication

For local accounts, require TOTP unless the deployment has an equivalent approved identity-provider policy. OAuth sign-in supports Microsoft Entra ID and Google and delegates MFA to that provider.

Use HTTPS and set secure cookies in production. Restrict CORS to the actual application origin. Place the control plane behind a trusted reverse proxy and ensure forwarded-client headers cannot be spoofed by untrusted direct clients.

See Users, settings, and authentication.

What is stored as a secret

The secret layer covers:

• connector configuration JSON;
• user TOTP secrets;
• provider keys stored through supported settings;
• values referenced from Azure Key Vault where configured.

Passwords are stored as password hashes, not recoverable passwords. Product API keys are stored as hashes and shown only once.

Task and job YAML are not secret stores. Neither are dashboard definitions, arguments, job configuration, log messages, or AI conversations.

Secret providers

Envoy uses a provider registry for encrypted values. New values are written through the configured default provider:

• SQLite-backed state;
• MSSQL-backed state;
• PostgreSQL-backed state;
• Azure Key Vault.

Database-backed providers use envelope encryption. Azure Key Vault stores the value in the vault and keeps provider metadata in Envoy state.

An Azure-managed deployment can use the control plane's managed identity rather than a vault client secret. Grant only the Key Vault data-plane permissions needed to list, read, create, update, and delete the deployment's secrets.

Server configuration can reference a vault value:

mssql:
  password: ${secret://azure_key_vault/envoy-mssql-password}

The provider must be registered before startup configuration is resolved.

Encryption key

ENVOY_ENCRYPTION_KEY protects database-backed secret values. Treat it as part of the backup:

• generate it with a cryptographically secure method;
• store it outside the state database;
• provide the same value after restart or restore;
• restrict read access to the control-plane process;
• never print it in logs or commit it.

Losing the key makes encrypted connector and TOTP material unrecoverable. Rotating it is a migration procedure, not an environment-variable edit. Follow the release-specific key-rotation procedure supplied with the deployment.

Control plane and executor

Remote executors authenticate with a shared executor key. Generate a high-entropy value, keep it separate from the encryption key, and rotate both sides together.

Network policy should:

• expose the control plane only through the HTTPS ingress;
• make executor HTTP reachable only from authorized control planes;
• restrict executor egress to required databases, APIs, object stores, and the control-plane callback;
• block metadata endpoints and internal management networks unless explicitly required.

Executor labels are routing metadata, not an authorization mechanism.

Container hardening

The remote Docker topology applies a stricter profile to the executor because it runs task pipelines:

• no privilege escalation;
• all Linux capabilities dropped;
• read-only root filesystem;
• bounded process and memory resources;
• temporary scratch space;
• explicit writable mounts for state, data, and connector databases.

Keep the default seccomp profile or an approved stricter profile. Run a patched container runtime, limit access to the Docker socket, and never mount the socket into Envoy containers.

Read-only root filesystems require absolute file-connector paths under approved writable mounts such as /app/data or /app/dbs.

Data and logs

• Use separate source and destination service accounts.
• Restrict database schemas, API scopes, and object-storage prefixes.
• Encrypt disks, managed databases, object storage, and backups.
• Treat debug and per-run logs as potentially sensitive.
• Apply retention and access controls to exports.
• Keep public dashboard queries narrowly scoped.
• Leave public input and action switches disabled unless reviewed.

Production review

Before go-live:

1. terminate TLS at an approved ingress;
2. restrict CORS and enable secure cookies;
3. enforce MFA;
4. verify role assignments;
5. inventory connector scopes;
6. test executor network allowlists;
7. verify backup encryption and restore access to the encryption key;
8. inspect public dashboard exposure;
9. test API-key revocation;
10. record key-rotation and administrator-recovery procedures.