Console + RPS Cloud Deployment ADR

Proposal for deploying Console with existing RPS infrastructure (deployment#614).

Contents

• Architectural Decisions
  • 1 Console owns profiles, RPS orchestrates provisioning
  • 2 One database; passwords stay there
  • 3 Vault holds certificates and the app encryption key
  • 4 Console must match the MPS device API, including upsert on POST
  • 5 The trust boundary is the network, not the device API
• Detailed design and diagrams

Architectural Decisions

These are proposals for review, not settled decisions.

See the Component map diagram for how Console and RPS fit together in this proposal.

1 Console owns profiles, RPS orchestrates provisioning

Status: Proposed

Context: In the MPS + RPS deployment, RPS owns profile, CIRA, wireless, 802.1x, domain and proxy configuration. Deploying Console alongside RPS needs one owner for that configuration.

Decision:

• Console is the source of truth for profiles, CIRA, wireless, 802.1x, domain and proxy configs.
• RPS keeps the activation, deactivation and maintenance state machines, and reads the configuration it needs at activation from Console's API. See 1.
• RPS configuration CRUD routes are turned off by RPS_MODE; the health route remains.
• RPS supports both deployments: MPS + RPS as it works today, and Console + RPS. One env setting selects which. See 2.

Consequences: mps stays the default, so existing MPS + RPS deployments are unchanged. Console must add the configuration CRUD and read endpoints RPS depended on.

2 One database; passwords stay there

Status: Proposed

Context: Console and RPS otherwise ship separate databases. Console already stores device and profile passwords (AMT_PASSWORD, MPS_PASSWORD, MEBX_PASSWORD) encrypted in its own database.

Decision: Console owns the only database; RPS needs none, since all its tables are configuration. Device and profile passwords stay in Console's database, as today; RPS writes and reads device credentials through Console's API rather than directly to Vault. Vault API calls are costly, and passwords are read far more often than MPSCerts. See 3.

Consequences: RPS's database connection is dropped, and Console becomes the only writer of configuration data, including passwords. RPS's device-credential writes move from Vault to Console's API, which must support them.

3 Vault holds certificates and the app encryption key

Status: Proposed. The certificate part is not finalized and needs further analysis.

Context: Vault already holds MPSCerts, the CIRA TLS identity. Standalone Console reads APP_ENCRYPTION_KEY, the key that encrypts password columns, from local configuration.

Decision: Vault also holds APP_ENCRYPTION_KEY for the cloud deployment, alongside MPSCerts. Console reads it from Vault at startup instead of local configuration.

Consequences: The key that encrypts passwords in the database is itself Vault-backed, without putting the passwords themselves in Vault.

4 Console must match the MPS device API, including upsert on POST

Status: Proposed

Context: RPS registers the same device more than once per activation.

Decision: Console's device API must behave like MPS's, including upsert on POST. See 4.

Consequences: Without upsert, CIRA provisioning fails on the second POST for the same device.

5 The trust boundary is the network, not the device API

Status: Proposed

Context: As in Cloud 2.x, auth is enforced at the gateway rather than by each service.

Decision: Gateway-enforced auth (AUTH_GATEWAY_ENFORCED=true, AUTH_DISABLED=false) and 8181 internal-only, never published to the host. See 5.

Consequences: The unauthenticated surface behind the gateway is wider than 2.x, since RPS also reads Console's configuration over that same path.