Redis provisioning inconsistency: firewall allowlist not enforced on new instances

On April 3, 2026, a connection timeout was reported on a newly provisioned Redis instance in the Norway region. The IP address had been correctly added to the firewall allowlist through the dashboard, but the connection could not be established.

Investigation revealed a multi-layer inconsistency between the control plane database, the host-level firewall agent, and the runtime enforcement layer. The firewall synchronization script used strict error handling that caused it to terminate silently when processing a new instance with no pre-existing rules. The agent layer did not validate the script outcome and returned a success response regardless. The control plane committed the database change despite the failed enforcement, resulting in a silent divergence between the recorded configuration and the actual network state.

The issue was scoped to the provisioning and firewall enforcement pipeline for newly created instances. Existing established connections were not disrupted. There was no data exposure, no unauthorized access, and no integrity impact.

Newly provisioned Redis instances where custom firewall rules were applied during or after creation were affected. The allowlist appeared correctly configured in the dashboard, but was not enforced at the network level, preventing any connection from being established. Instances without custom allowlist entries and previously established connections were not affected. No data was exposed and no unauthorized access occurred.

The firewall synchronization script was corrected to handle the edge case that caused early termination. The host agent was updated to validate execution results and surface failures explicitly. The control plane API was modified to roll back database changes when downstream enforcement fails, ensuring the recorded state and actual network state remain consistent at all times.

Firewall rules were verified consistent across the database, the agent state, and the live enforcement layer for all active instances.

Silent failure paths have been eliminated across all three layers of the provisioning stack. Database transactions are now atomically tied to successful downstream enforcement — if any layer fails, the entire operation is rolled back and the failure is surfaced to the caller.

Boot persistence has been hardened with a dedicated service that restores firewall rules from the persisted state on every system restart, with correct service ordering dependencies. The provisioning pipeline now applies the same enforcement guarantees to all firewall operations, for both new and existing instances.