Infrastructure checks (K8s / CIS / hardening)

Even when definition files are written safely, a deployed cluster drifts over time as its settings loosen. Infrastructure checks measure the security settings of your running infrastructure in place. Where IaC analysis looks at the code (definition files), infrastructure checks look at the actually deployed state. It is used in the Server / Host service.

한눈에 보기

Analysis

Security settings of running clusters / nodes (K8s / CIS / hardening)

What you need

Host registration plus kubeconfig (or a service account token)

Results

Findings by bucket, plus mapping to compliance standards

Three buckets

• K8s cluster: security setting flaws in cluster resources
• CIS benchmark: CIS compliance of nodes/clusters
• Container hardening: image/runtime hardening best practices

Each bucket runs and is queried independently, and alerts are separated by bucket.

Prerequisites

• The target server must be registered as a Server / Host.
• Kubernetes checks require a kubeconfig (or a service account token).
• A private cluster is connected over an SSH tunnel or a VPN.

Handling results

• CIS results can have many items, so they are grouped by resource so you can review them in priority order.
• Use the KEV and group badges to quickly find important items.
• Mark settings that are intended by organizational policy as accepted risk to reduce noise.

Namespace scoping

Enumerating an entire large cluster can take a long time, so checks are narrowed in scope per namespace.

Next steps

Vulnerability management→Review findings, accepted riskCompliance→Standard mapping and coverageIaC analysis→Infrastructure setting flaws at the code stageServer / Host overview→Registration and private cluster connection