# Official sources

Use this reference only when grounding Contabo security behavior, API authentication flows, or secret management patterns.

## Contabo documentation

Use these as starting points, not as proof of the user's live instance configuration:

- https://api.contabo.com/ — Contabo OpenAPI reference (authentication, secret management, firewall endpoints)
- https://docs.contabo.com/ — Contabo user documentation (SSH keys, Cloud-Init, firewall, Private Networking)
- https://github.com/contabo/cntb — cntb CLI tool (secret management commands, instance operations)
- https://api.contabo.com/#tag/Instances — Instance operations API (Cloud-Init userData, SSH key secret IDs)

## Grounding rule

Official Contabo documentation describes platform security capabilities and API authentication patterns. It does not prove the user's current firewall rules, SSH configuration, running services, or OAuth2 token state. Prefer user-provided sanitized evidence or live read-only API responses for current-state claims. Label any claim sourced only from documentation as `documentation-based`. Documentation alone never replaces a live firewall rule dump or actual sshd_config output.

# Safety checklist

Use this reference before making hardening recommendations that touch SSH access paths, firewall rules, user accounts, or credential configuration on live Contabo instances.

## Non-negotiables

- Never ask users to paste OAuth2 tokens, client secrets, API passwords, SSH private keys, or any raw credentials into chat.
- SSH keys must always be referenced by Contabo secret IDs — never include raw private key material in recommendations, scripts, or API payloads.
- Do not recommend disabling SSH password login or root login unless an alternative access path (SSH key, console access) is confirmed to be working first.
- Do not recommend opening firewall rules broader than the minimum required port and source range.
- Do not invent firewall rule IDs, instance IDs, secret IDs, or current configuration state. Label any unconfirmed claim.
- Require explicit user acknowledgment before recommending changes to the only active SSH access path.
- OAuth2 token values must never appear in recommendation output, logs, or script echo statements.
- Cloud-Init userData must be reviewed for embedded secrets, curl-pipe-sh patterns, or commands that disable audit logging before inclusion in any API payload.

## Stress checks

- Does this change remove or weaken the only SSH or console access path? → Stop until alternative is confirmed.
- Does this firewall change open a management port (22, 3389, 443-admin) to 0.0.0.0/0? → Require justification and scope limitation.
- Does this Cloud-Init fragment contain raw credentials, hardcoded secrets, or unauthenticated remote execution? → Refuse to pass as userData.
- Are OAuth2 token refresh patterns logging token values? → Flag and replace with sanitized patterns.
- Is the current firewall or user configuration based on inference rather than evidence? → Label and request evidence before recommending changes.
- What is the blast radius if this hardening change locks out all administrative access?

## Evidence labels

Use `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`. Hardening recommendations made on inference alone must be flagged as provisional and subject to evidence confirmation before implementation.

# Workflow and output contract

Use this reference only when performing a full security posture review, generating hardening recommendations, or producing a structured audit report for a Contabo environment.

## Review domains

Check these areas before giving a verdict:

- SSH key strategy: Contabo secret IDs used vs. raw private key material in scripts or API payloads
- Default user policy: root login disabled, admin user configured via Cloud-Init, password login disabled
- Firewall posture: open inbound ports, 0.0.0.0/0 rules, management port exposure
- OAuth2 credential hygiene: token TTL awareness (~5 min), environment variable storage, absence of logged token values
- API traceability: x-request-id (UUIDv4) included in all REST calls
- Secret scanning: hardcoded credentials in automation scripts, CI/CD pipelines, or userData
- Network isolation: Private Networking add-on usage, Additional IP exposure, unnecessary public-facing services

## Safe workflow

1. **Frame scope**
   - Instance(s) or environment under review:
   - Business criticality and owner:
   - Data classification or compliance driver:
   - Required outcome (gap report, remediation plan, hardening script):
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer user-provided sanitized configuration evidence (firewall rules, sshd_config, Cloud-Init fragments).
   - Use read-only Contabo API calls if live access is available.
   - Otherwise ground in official Contabo docs and label accordingly.
   - Label each finding as `live evidence`, `user-provided sanitized evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What SSH or authentication path can expose root access?
   - What firewall rule allows lateral movement or unrestricted inbound?
   - What credentials or secrets are hardcoded or logged?
   - What OAuth2 token handling creates a replay or leakage window?
   - What evidence is missing that would change the risk assessment?
4. **Recommend the smallest safe hardening action**
   - Prefer targeted, reversible changes with a validation step.
   - If the safest action is to gather evidence before recommending changes, say that plainly.
   - Never suggest disabling the only SSH access path without confirming an alternative.

## Output contract

Return this structure:

```markdown
# Contabo Security Hardening Review: <scope>
## Executive verdict
- Status: HARDENED / HARDENED WITH GAPS / AT RISK / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```