Oracle 19c: apply static (pending-reboot) hardened params on modify — reboot after parameter-group changes

[wz-gsa]

Part of the Oracle 19c epic (#519). Raised in PR #537 review (@cweibel): how do we handle pending-reboot parameter-group settings, since several hardened Oracle params are static? Related to #292 ("RDS broker should reboot databases on some configuration changes").

Problem

The born-hardened Oracle SE2 parameter group includes STATIC (apply_method=pending-reboot) STIG params: audit_trail, audit_sys_operations, remote_login_passwordfile, sql92_security. When a static param is changed on an existing instance (the cf update-service / modify path), RDS marks it pending-reboot and it does not take effect — and the corresponding STIG check fails — until the instance is rebooted. The broker does not reboot: RebootDBInstance is absent from RDSClientInterface (services/rds/types.go) and production code; today the broker only surfaces pending-reboot and defers reboots to cloud.gov support.

Findings (verified against AWS docs + code)

• New instances are fine (no chicken/egg). The hardened group is bound at CreateDBInstance (services/rds/create_worker.go); RDS applies a newly-associated group's static+dynamic params on the instance's first boot, and RDS auto-reboots on start when a custom parameter group is used. So a newly provisioned born-hardened instance has the static params in effect once available. (Strongly supported by AWS docs; recommend one empirical DescribeDBInstances confirmation that ParameterApplyStatus: in-sync with no pending-reboot.)
• The gap is the MODIFY path. Changing a static param on a live instance ⇒ pending-reboot; no automatic maintenance-window reboot; manual reboot required. USER_RebootInstance
• Reboot is NOT console/CLI-only. RebootDBInstance is a first-class RDS API in AWS SDK for Go v2 (the SDK this broker uses), so the broker can reboot programmatically. API_RebootDBInstance

Options

• (a) Keep relying on create-time binding for new instances — already correct; document it.
• (b) On modify, when static hardened params change, the broker issues RebootDBInstance (add to RDSClientInterface + mock; wire into the async modify worker; gate on available state; account for the brief outage). Closes the compliance-latency gap without a support ticket. Aligns with RDS Broker should reboot databases on some configuration changes #292.
• (c) Status quo: surface pending-reboot, manual reboot via support (safe interim, but not "compliant immediately" after a change).

Recommendation

Confirm (a) empirically + document; implement (b) for the modify path; keep (c) as manual fallback.

Acceptance criteria

• Empirically confirm a newly created born-hardened instance reports ParameterApplyStatus: in-sync (no pending-reboot) once available; document in docs/oracle19c/hardening-baseline.md.
• RebootDBInstance added to RDSClientInterface + mock; unit-tested.
• Async modify worker detects pending-reboot on hardened static params and reboots (only when available); outage documented.
• STIG overlay passes for the four static params after a modify-triggered change with no manual support step.
• Docs updated (overview self-service matrix, ops runbook).

Related: #292 (reboot-on-config-change; this is the Oracle-hardening-specific slice).