Sync .kiro/ from master — v2.2.0 release batch
New specs: archer-template-library, ccp-metrics-view-restructure, compliance-list-stale-after-sidebar-edit, compliance-metric-estimated-resolution-date, compliance-remediation-display-fix, flexible-jira-ticket-creation, forecast-burndown-chart, granite-loader-export, ivanti-queue-clear-completed-fix, multi-item-jira-ticket, queue-collapsible-sections, vendor-issue-type-dropdown New steering: archer-template-gen.md Updated: migration-registration-check hook, remediation-plan-history spec, gitlab-workflow, tech, versioning steering files
This commit is contained in:
Jordan Ramos
83
.kiro/steering/archer-template-gen.md
Normal file
83
.kiro/steering/archer-template-gen.md
Normal file
@@ -0,0 +1,83 @@
|
||||
---
|
||||
inclusion: manual
|
||||
---
|
||||
|
||||
# Archer Template Content Generator
|
||||
|
||||
When this steering file is active, the user will provide a brief, informal description of a network device and its environment. Your job is to expand that into three formal Archer Risk Acceptance sections suitable for direct paste into the Archer application or into the STEAM Dashboard's Archer Template Library.
|
||||
|
||||
## IMPORTANT: Web Search Step
|
||||
|
||||
Before generating content, you MUST use the web search tool to look up the specific vendor and model mentioned by the user. Search for:
|
||||
1. "[Vendor] [Model] datasheet" — to get hardware specs, supported protocols, OS details, and form factor
|
||||
2. "[Vendor] [Model] network security" or "[Vendor] [Model] hardening guide" — to find security-relevant capabilities
|
||||
|
||||
Use the search results to enrich the generated content with accurate, model-specific details such as:
|
||||
- Exact OS name and base (e.g., "Junos OS Evolved" vs "Junos OS", "IOS-XR 7.x", "AOS-W")
|
||||
- Supported interface types and throughput capacity
|
||||
- Built-in security features (MACsec, hardware encryption, TPM, secure boot)
|
||||
- Typical deployment role per vendor documentation
|
||||
- Protocol support relevant to the environment (segment routing, EVPN, VXLAN, etc.)
|
||||
|
||||
If the search returns useful specs, weave them naturally into the Environment Overview. Do NOT just dump raw specs — integrate them into the Archer prose format.
|
||||
|
||||
## Output Sections
|
||||
|
||||
Generate exactly three sections:
|
||||
|
||||
1. **Environment Overview**
|
||||
2. **Segmentation**
|
||||
3. **Mitigating Controls**
|
||||
|
||||
## Rules
|
||||
|
||||
- Infer reasonable technical details from the device type, vendor, and role. If you know the platform OS (Junos for Juniper, IOS-XR for Cisco, EOS for Arista, embedded Linux for RPDs, ADTRAN-specific OS for OLTs), include it.
|
||||
- Fill in standard security posture details based on the environment described (CTEC lab vs production field, internet-facing vs isolated behind VPN, etc.).
|
||||
- Write as continuous prose with paragraph breaks between logical subsections. No bullets, no markdown headers, no formatting — this gets pasted directly into Archer text fields.
|
||||
- If something is unknown from the input, make a reasonable assumption for the device class and state it naturally.
|
||||
- Always include CrowdStrike/SentinelOne status — assume NOT installed on network infrastructure unless told otherwise.
|
||||
- Always end Mitigating Controls with the authentication method (TACACS, ISE, RADIUS, local, etc.).
|
||||
|
||||
## Section Structure
|
||||
|
||||
### Environment Overview must include:
|
||||
- What the device is and its function
|
||||
- Operating system
|
||||
- Typical deployment location
|
||||
- Data categories: processed/transmitted (in transit) and stored (on device)
|
||||
- General data processing flow: ingress, processing, egress, disposition
|
||||
- Application/environment description with service/functionality
|
||||
- Geographic deployment
|
||||
- Applications in use
|
||||
|
||||
### Segmentation must include:
|
||||
- Network segmentation controls (VLANs, VRFs, routing policies, prefix lists, ASN isolation)
|
||||
- Perimeter firewalls/PE ACLs with explicit deny/allow patterns
|
||||
- Private addressing (RFC1918, no NAT to internet)
|
||||
- Transport protection (MPLS, optical, IPsec, MACsec as applicable)
|
||||
- Service hardening (disabled unused services, SSH v2, SNMPv3, TLS)
|
||||
- Access controls restricting communications
|
||||
|
||||
### Mitigating Controls must include:
|
||||
- Internet accessibility posture (not accessible from public internet)
|
||||
- External-facing services (none, or list what's internal-only)
|
||||
- Controls restricting external access (ACL rules with specific allow/deny)
|
||||
- Administrative access isolation (jump host/bastion, MFA, PAM, break-glass, OOB management)
|
||||
- Endpoint security agent status (CrowdStrike Falcon, SentinelOne — typically not installed on network infra)
|
||||
- Authentication method (TACACS+/Cisco ISE, RADIUS, local, etc.)
|
||||
|
||||
## Reference Context
|
||||
|
||||
These are from approved Charter Red Network Archer exceptions for similar device classes:
|
||||
|
||||
- RPDs (Harmonic, Vecima): R-PHY devices in the field, embedded Linux, DOCSIS traffic, not internet-accessible, MPLS transport, TACACS/ISE auth
|
||||
- OLTs (Adtran): PON service devices in CTEC, ADTRAN-specific OS, Blue VPN access only, null-routed external paths, TACACS auth
|
||||
- vCMTS (Harmonic CableOS): Virtual CMTS cores, Linux-based, headend/datacenter, DOCSIS downstream/upstream, private MPLS transport
|
||||
|
||||
## How to Use
|
||||
|
||||
The user will type something informal like:
|
||||
|
||||
> Juniper PTX10003, Hub Core Router in CTEC. Backbone of the lab. Access behind Blue VPN. Routing policies and prefix lists limited to CTEC ASN. Junos.
|
||||
|
||||
You respond with the three generated sections, each clearly labeled, ready to copy into the template library.
|
||||
@@ -28,6 +28,14 @@ When working from a GitLab issue, reference the issue number in:
|
||||
|
||||
- Prefer closing issues via commit message keywords (`Closes`, `Fixes`, `Resolves`) so GitLab auto-closes them when the pipeline succeeds on the default branch.
|
||||
- If a commit was pushed without the keyword, close the issue via the API after confirming the deploy succeeded.
|
||||
- **Always post a brief summary comment** on the issue when closing it. One or two sentences describing what was done is enough — the goal is that anyone reading the issue later understands the resolution without digging through commits. Post the comment via the GitLab API:
|
||||
```bash
|
||||
curl --silent --request POST \
|
||||
--header "PRIVATE-TOKEN: $GITLAB_PAT" \
|
||||
--header "Content-Type: application/json" \
|
||||
--data '{"body": "Fixed in <commit>. <1-2 sentence summary of what changed>."}' \
|
||||
"http://steam-gitlab.charterlab.com/api/v4/projects/13/issues/<N>/notes"
|
||||
```
|
||||
|
||||
## Pipeline Notifications
|
||||
|
||||
|
||||
@@ -80,9 +80,62 @@ Python dependencies: `pandas>=2.0.0`, `openpyxl>=3.0.0` (install via apt or venv
|
||||
- Both `.env` files are gitignored; see `.env.example` files for templates.
|
||||
- React env vars are baked in at **build time** — you must rebuild (`npm run build`) after changing them.
|
||||
|
||||
## Code Style & Lint Rules
|
||||
|
||||
### Unused Variables
|
||||
|
||||
The frontend ESLint config enforces `no-unused-vars` as a warning. The CI pipeline fails if warnings exceed 25. To avoid lint failures:
|
||||
|
||||
- **Prefix intentionally-unused variables with `_`** — this suppresses the warning. The `varsIgnorePattern: "^_"` and `argsIgnorePattern: "^_"` rules are configured in `frontend/package.json`.
|
||||
- Common patterns:
|
||||
- `const [_unused, setFoo] = useState(...)` — destructured value you don't need
|
||||
- `const _legacyRef = useRef(...)` — kept for future use
|
||||
- `function handler(_event) { ... }` — required parameter signature but unused
|
||||
- **Do not leave variables unprefixed if unused.** Either use them, remove them, or prefix with `_`.
|
||||
- This applies to all frontend code written by the agent.
|
||||
|
||||
### Backend
|
||||
|
||||
No ESLint is configured for backend — the pipeline uses `node -c` syntax checking only. Keep code clean but there is no automated unused-var enforcement on the backend side.
|
||||
|
||||
## Ports
|
||||
|
||||
| Environment | URL | Notes |
|
||||
|---|---|---|
|
||||
| Production / Dev server | http://IP:3001 | Express serves API + static frontend build |
|
||||
| Production | http://71.85.90.6:3001 | Express serves API + static frontend build |
|
||||
| Staging | http://71.85.90.9:3100 | Auto-deploy on master push |
|
||||
| Local dev (frontend only) | http://localhost:3000 | React dev server with hot-reload, proxies API to :3001 |
|
||||
|
||||
## CI/CD Pipeline
|
||||
|
||||
### Infrastructure
|
||||
|
||||
| Role | Host | Notes |
|
||||
|---|---|---|
|
||||
| GitLab instance | steam-gitlab.charterlab.com | Self-hosted GitLab |
|
||||
| CI Runner (LXC 108) | 71.85.90.8 | Docker executor, Runner #6, project-locked |
|
||||
| Staging target | 71.85.90.9 | Auto-deploy on master, port 3100 |
|
||||
| Production target | 71.85.90.6 | Manual deploy trigger, port 3001 |
|
||||
|
||||
### Executor: Docker
|
||||
|
||||
The pipeline uses **Docker executor** on Runner #6. Jobs run in isolated containers:
|
||||
|
||||
- **Install / Lint / Test / Build stages**: `node:18` image
|
||||
- **Deploy stages**: `alpine:latest` image (installs `openssh-client` and `rsync` at runtime)
|
||||
|
||||
Deploy jobs SSH from inside the Alpine container to the target hosts using a base64-encoded `$SSH_PRIVATE_KEY` stored as a GitLab CI/CD variable.
|
||||
|
||||
### CI/CD Variables (project-level)
|
||||
|
||||
These are set in GitLab → Settings → CI/CD → Variables:
|
||||
|
||||
| Variable | Purpose |
|
||||
|---|---|
|
||||
| `DATABASE_URL` | PostgreSQL connection string for backend integration tests |
|
||||
| `SSH_PRIVATE_KEY` | Base64-encoded private key for deploy SSH access |
|
||||
| `GITLAB_PAT` | Project access token for issue comments and release creation |
|
||||
|
||||
### Pipeline file
|
||||
|
||||
The pipeline is defined in `.gitlab-ci.yml` at the project root. Stages: install → lint → test → build → deploy → verify.
|
||||
|
||||
@@ -46,13 +46,13 @@ This project uses **Semantic Versioning** (MAJOR.MINOR.PATCH) but with a practic
|
||||
\"name\": \"vX.Y.Z\",
|
||||
\"description\": \"<changelog section in markdown>\"
|
||||
}" \
|
||||
"https://vulcan.apophisnetworking.net/api/v4/projects/jramos%2Fcve-dashboard/releases"
|
||||
"http://steam-gitlab.charterlab.com/api/v4/projects/steam%2Fcve-dashboard/releases"
|
||||
```
|
||||
|
||||
### GitLab Release creation details
|
||||
|
||||
- The GitLab instance is `https://vulcan.apophisnetworking.net`
|
||||
- Project path: `jramos/cve-dashboard` (URL-encoded: `jramos%2Fcve-dashboard`)
|
||||
- The GitLab instance is `http://steam-gitlab.charterlab.com`
|
||||
- Project path: `steam/cve-dashboard` (URL-encoded: `steam%2Fcve-dashboard`)
|
||||
- Auth: `GITLAB_PAT` from `backend/.env`
|
||||
- The `description` field accepts full markdown — paste the relevant `## [vX.Y.Z]` section from `CHANGELOG.md`
|
||||
- The release appears under **Deployments → Releases** in the GitLab sidebar with rendered markdown, download archives, and a badge showing the latest version
|
||||
|
||||
Reference in New Issue
Block a user