K-Shield (Security)

Where This Fits in Karios

Karios is the unified infrastructure platform described in Getting Started. K-Shield covers the operational scanning, remediation, monitoring, and compliance workflows used inside Control Center to assess managed nodes and VMs.

If you landed here directly, use Glossary for shared terms and keep Getting Started as the platform-level reference.

What K-Shield Is

Purpose:

This section covers K-Shield security scanning, managed-node monitoring, VM scan execution, compliance evidence, and supporting hardening practices.

Expected Security Outcome

After this section, a new operator should be able to:

  • Run node-level and VM-level security scans consistently

  • Triage CAT I/CAT II findings with clear priority

  • Apply role/network/certificate controls with documented rationale

  • Produce an audit-ready evidence package for security incidents

Task-First Entry

When to Use:

Use this first when you need a fast execution path.

Purpose:

Start with high-frequency security tasks before reading full reference details.

Steps:

  1. Open K-Shield Quick Tasks for task-first workflows.

  2. Use Full K-Shield workflow when you need the full scan, readiness, and remediation runbook.

Expected Outcome:

  • You can execute first scan, triage, remediation verification, and escalation quickly.

If this fails:

  1. Open the full workflow included below under K-Shield Workflow.

Important

VM scanning has OS-specific prerequisites before the first scan:

  • Ubuntu VMs must be provisioned with Ubuntu VM Scan user data.

  • Windows VMs must have QEMU Guest Agent installed and running.

Use Full K-Shield workflow for the first-scan readiness check and the detailed OS-specific enablement steps.

RBAC Hardening (Identity and Access)

When to Use:

Use this during user/role access reviews and hardening checks.

Purpose:

Reduce privilege risk using role hygiene in User Management.

Use User Management to enforce role hygiene:

  • Assign minimum required permissions per job function

  • Avoid stacking multiple high-privilege roles without explicit need

  • Review inactive/stale privileged accounts regularly

  • Require stronger controls (2FA/approval) for high-risk operations

Steps:

  1. Open User Management and list users with admin-level roles.

  2. Confirm each privileged account has a named owner and business justification.

  3. Validate at least one non-admin test user cannot access admin-only modules.

  4. Record review date and reviewer in your security change log.

Expected Outcome:

  • Privileged access is justified and least-privilege controls are enforced.

If this fails:

  1. Re-audit admin-role assignments.

  2. Remove unnecessary elevated roles.

  3. Escalate unresolved privilege concerns to your security owner.

Network Security Baseline

When to Use:

Use this when reviewing network exposure and segmentation posture.

Purpose:

Reduce attack surface using network isolation and rule hygiene.

Use Networking to reduce attack surface:

  • Keep management and storage traffic isolated from guest/public paths

  • Expose public ingress only where workloads require it

  • Review firewall/port-forwarding rules for least exposure

  • Avoid ad-hoc CIDR changes without impact review

Steps:

  1. Open Networking and list active public-facing guest networks.

  2. Validate each exposed service has documented owner, purpose, and allowed source scope.

  3. Confirm unused port-forward/firewall rules are removed.

  4. Re-test critical application paths after security-rule changes.

Expected Outcome:

  • Public exposure is intentional and minimum required.

If this fails:

  1. Roll back unvalidated network rule changes.

  2. Re-test application paths and adjust rules.

Audit Logging and Evidence

When to Use:

Use this for incident investigation and compliance evidence preparation.

Purpose:

Capture reliable operational evidence from observability timelines.

For incident investigation and compliance evidence:

  • Use Observability as first-line audit timeline.

  • Capture timestamp, actor, resource ID, and action outcome for each security event.

  • Export or snapshot evidence early during active incidents to avoid retention surprises.

  • Align retention/export expectations with your deployment policy and support agreement.

Steps:

  1. Trigger a controlled admin action (for example role update in test scope).

  2. Confirm the event appears in Observability.

  3. Verify you can capture/export evidence with timestamp and actor metadata.

  4. Store the sample evidence in your incident/change record location.

Expected Outcome:

  • Security events are traceable by actor, action, resource, and timestamp.

If this fails:

  1. Verify events are visible in Observability.

  2. Reproduce a controlled action and re-check log capture.

Vulnerability and Patch Workflow

When to Use:

Use this immediately after K-Shield reports findings.

Purpose:

Prioritize remediation by severity and verify closure.

Steps:

  1. Prioritize by severity and exploitability (Critical/High first).

  2. Confirm affected node/VM scope and business impact.

  3. Apply config recommendation and re-run scan to validate closure and record residual risk.

Expected Outcome:

  • Critical/high findings are prioritized and tracked to closure.

If this fails:

  1. Confirm findings belong to the selected node/VM scope.

  2. Re-open recommendation guidance and retry remediation.

Compliance Mapping (Operational, Not Certification Claim)

When to Use:

Use this when aligning operations to internal security policy controls.

Purpose:

Map Karios operational controls to your organization compliance workflows.

Steps:

Karios operational controls can support common frameworks when implemented with policy:

  • NIST/CIS style hardening through role restrictions and configuration baselines

Expected Outcome:

  • Operational controls are mapped for policy and audit review.

If this fails:

  1. Review control ownership with your compliance team.

  2. Capture mapping decisions in your governance documentation.

Note

Compliance certification status depends on your organization controls and scope, not documentation alone.

Control Center TLS and Certificate Operations

When to Use:

Use this when validating certificate inventory or planning certificate rotation.

Purpose:

Direct users to certificate workflows required for secure service trust.

Steps:

For certificate lifecycle tasks, use:

Always validate dependent service trust after certificate changes.

Expected Outcome:

  • Certificate operations are performed from the correct pages.

  • Dependent service trust is verified after certificate updates.

If this fails:

  1. Confirm certificate state and validity in TLS Certificates page.

  2. Re-check affected service connectivity after rotation.

K-Shield Workflow

Use Full K-Shield workflow only when you need the complete scan, readiness, and remediation runbook.

→ Next: Kubernetes