Security Overview

Security in SPG99 is built on several practical principles that matter both to users and to integrators.

1. Separation of secrets by role

SPG99 has two different classes of secrets:

• API key — for the Control Plane, Console, and automation;
• pg_user / pg_password — for PostgreSQL connections through Gateway.

They are not interchangeable and should not be stored “in one pile.”

2. TLS on external entry points

The user works with the platform through:

• HTTPS for Console and the Control Plane;
• TLS for PostgreSQL connections to Gateway.

This means the normal working path is already built around secure protocols.

3. Compact public surface

Only the necessary user-facing domains are published externally:

• landing;
• Console;
• Control Plane API;
• Gateway;
• Grafana.

Internal storage services and service routes remain inside the platform.

4. No hidden backend superuser on the hot path

The database access model is not based on a “magic shared root login.” The platform uses managed client credentials and certificates, which makes the scheme more transparent and secure.

5. Secrets must not live in git

For both user-facing and infrastructure layers, the same rule applies: keys, passwords, and TLS materials must be stored in a protected secrets system, not in open repositories or “remembered” configuration files.

Practical summary

For the user, this boils down to several clear rules:

• store the API key separately from the DSN;
• connect only through TLS;
• use the platform’s public domains, not internal addresses;
• rotate tokens and handle tenant credentials carefully.