Auto-sync .kiro/ from master (post-checkout hook)

.kiro/steering/firewall-request-template.md

@@ -0,0 +1,111 @@
+---
+inclusion: manual
+---
+
+# Firewall Exception Request Template
+
+When the user needs to generate a Red/Blue Firewall Exception Request (LNE > Lab Network Request ticket), use this template structure. Adapt the content based on the specific service requiring network access.
+
+## Template Structure
+
+Every firewall request document must include these sections in order:
+
+### 1. Title and Purpose
+
+```
+# <Service Name> Firewall Exception Request — <Application Name>
+
+Reference material for the LNE > Lab Network Request ticket required by
+<reason for the block / policy reference>. All targets are <source of truth
+for the destination list>.
+```
+
+### 2. Destinations Table
+
+| Cluster/Service | Destination IP/Host | Port(s) | Protocol | Encryption |
+|---|---|---|---|---|
+| *Name of the service* | *IP or hostname* | *port(s)* | TCP/UDP | *TLS, PLAINTEXT, etc.* |
+
+Include notes about connection type: stateful TCP, client-initiated outbound, ephemeral source port, etc.
+
+### 3. Source
+
+- Source host: `<hostname>`
+- Source IP: `<IP address>`
+- Source port: `ephemeral / 1024-65535`
+
+### 4. Requested Firewall Rules
+
+Provide both per-IP rules and summary rules (if LNE accepts them):
+
+```
+Rule N
+  Source:      <source IP>/32   ephemeral
+  Destination: <dest IP>/32     tcp/<port>
+  Protocol:    TCP
+  Action:      allow
+```
+
+### 5. Suggested Ticket Text
+
+Follow the LNE template fields exactly:
+
+> **Summary:** Red/Blue FW Request: <Source App> → <Destination Service> (<brief description>)
+>
+> 1. **Reason:** What the application does and why it needs this access.
+> 2. **Drivers:** Operational, compliance, or business justification. State explicitly: no PCI, no CPNI if applicable.
+> 3. **Application purpose:** What the app does with the data it gets from the destination. Mention rate limits, compliance with API policies, etc.
+> 4. **Source/destination IPs and ports:** Summary of flows (count, protocol, direction).
+> 5. **Impact if denied:** What breaks, what the fallback is, and why the fallback is worse.
+>
+> **Environment Overview**
+> 1. Data: What data flows over this connection. Explicitly state no PII/PCI/CPNI if true.
+> 2. OS: Operating system on the source host.
+> 3. OS compliance / risk acceptance: Fill in if applicable.
+> 4. Architecture: Brief description of the application architecture.
+>
+> **External access:** State whether the source host is internet-exposed or internal-only.
+>
+> **Mitigation controls:** How access to the source host is controlled, how credentials are stored, what security measures are in place.
+
+### 6. Evidence to Attach
+
+Describe what test script to run and what log files to attach. The log should provide timestamped proof of the connection behavior (success or failure) from the source host.
+
+### 7. Notes
+
+Any additional context: auth methods, TLS settings, environment differences between UAT and production, etc.
+
+---
+
+## Key Principles
+
+- Be specific about IPs, ports, and protocols. Avoid vague descriptions.
+- Explicitly state what data does NOT flow (no PII, no PCI, no CPNI) to speed risk assessment.
+- Reference test evidence that proves the current behavior without speculation.
+- If a test script exists, reference it and describe its output format.
+- Use `/32` for single-host rules. Only use CIDR aggregates if you explain what extra IPs are included.
+- State whether TLS is used. If PLAINTEXT, explain why (e.g., internal Kafka brokers with no client auth).
+- Mention rate limiting and compliance with any API usage policies if applicable.
+
+---
+
+## Existing Firewall Request Documents
+
+Reference these for examples of completed requests:
+
+- `docs/kafka-firewall-request.md` — ZBL Impairment Map → Charter Kafka telemetry feeds (STAMP + DAA RPHY Prod). TCP PLAINTEXT to specific broker IPs on non-standard ports.
+- The Jira request (generated in chat) — STEAM Dashboard → jira.charter.com:443. Single HTTPS flow with Basic Auth service account.
+
+---
+
+## Checklist Before Submitting
+
+- [ ] All destination IPs/hostnames and ports are listed
+- [ ] Source host IP is filled in (not placeholder)
+- [ ] Protocol and encryption are specified for each flow
+- [ ] Ticket text follows the LNE template fields
+- [ ] Data classification is stated (PII/PCI/CPNI or lack thereof)
+- [ ] Test evidence is attached or referenced
+- [ ] Impact-if-denied section explains the operational consequence
+- [ ] Mitigation controls describe how the source host is secured