Environment policies¶

Edition: Community and Enterprise Offering: Self-managed

A policy says, for one environment, who approves a fix, what the fix must carry, and when it may run. Every target uses the policy of its environment.

sealfix.yaml

policies:
  prod:
    approvals: [dba_reviewer, business_approver]
    ticket_required: true
    signed_approvals: required
    windows:
      timezone: Africa/Cairo
      allow:
        - { days: [sun, mon, tue, wed, thu], start: "22:00", end: "05:00" }
      blackout:
        - { name: month-end, days_of_month: [-1, 1] }
    emergency:
      enabled: true
      review_within_h: 24
  non_prod:
    approvals: [dba_reviewer]

What a policy controls¶

Setting	Controls	Read more
`approvals`	Which roles approve, how many approvals each gives, in which order	Approvals
`ticket_required`	A ticket reference is needed to submit
`signed_approvals`	Every approval is signed with the approver's passkey	Signed approvals
`risk_rules`	More approvals, or a row cap, for fixes that match	Risk rules
`checks`	The level of each check here: error, warning or off	Checks
`windows`	When fixes may run, and blackout days	below
`promotion`	A template must first run on another target, such as UAT	below
`capture`	How triggers and side effects are handled	Rollback
`emergency`	Emergency changes allowed, and how soon their review is due	Emergencies

Execution windows¶

gantt
    title Production window, Africa/Cairo
    dateFormat HH:mm
    axisFormat %H:%M
    section Sunday to Thursday
    Fixes may run :active, 22:00, 7h
    section Month end
    Blackout, no fixes :crit, 00:00, 24h

An execution starts only if the window stays open for the whole execution time limit. An emergency change may run outside the windows, but not in a blackout unless that blackout says allow_emergency: true.

Promotion¶

policies:
  prod:
    promotion:
      sources:
        core-banking-prod: core-banking-uat

A template runs on core-banking-prod only after the same template ran on core-banking-uat and was not rolled back.

Emergency changes¶

Off on every environment until you set emergency.enabled: true in its policy. Then a requester on that environment may declare a request an emergency, with a reason. It runs on one technical approval; the approvals it skipped are owed after it ran.

Setting	Default	Meaning
`emergency.enabled`	`false`	Emergencies may be declared on this environment
`emergency.review_within_h`	`24`	Hours after the execution within which the owed approvals are due, 1 to 72
`windows.blackout[].allow_emergency`	`false`	An emergency may run during this blackout

The DBA reviewers and business approvers are told when one is declared. When it ran, they and the auditors are told that its review is owed. The approver roles are reminded once at half of the time. An overdue or rejected review reaches the administrators too.
The alert SealfixEmergencyReviewOverdue fires while a review is overdue.
A rejected review rolls nothing back. An administrator acknowledges it on the request's page with "Acknowledge the rejection"; until then its requester cannot declare another emergency.
On production, any change to emergency is a sensitive change (next section).

See Emergency changes.

Changing a policy¶

Policies are part of the configuration. Every change is a new version, with its diff, recorded in the audit log. Loosening a production policy (fewer approvals, no ticket, a lower count, a changed order) is a sensitive change: every administrator and auditor is told, and the event goes to your SIEM.

Troubleshooting¶

A target cannot submit

Its environment has no policy. A policies section replaces the built-in defaults; it is not merged with them. Add a policy for every environment your targets use.

An approved fix does not start

It is outside its window, in a blackout, or waiting for promotion. "Before execution" on the request page names which.