Overview
Niro includes a built-in policy engine that checks your deployments against Kubernetes best practices. Findings are advisory only — they never block a deployment or PR merge — but they surface common misconfigurations before they become production incidents.The Security Posture page combines these standards checks with external policy engine violations from OPA Gatekeeper and Kyverno, plus image vulnerability scanning — all in one view.
Build time
Inline warnings in the Visual Builder as you fill in the form.
PR time
Comment and check run posted to GitHub when a PR is opened against a linked repo.
Runtime
Findings on the deployment detail page, updated continuously from live cluster state.
Severity levels
Some rules escalate severity based on the cluster’s environment — a single replica is informational on a dev cluster and high severity on a production cluster.
Rules
Missing resource requests
Missing resource requests
Default severity: MediumA container doesn’t have CPU or memory
requests set.Without requests, the Kubernetes scheduler can’t make an informed placement decision. The pod may be scheduled onto a node that can’t support its workload, leading to OOM kills or CPU throttling.Fix: Set resources.requests.cpu and resources.requests.memory on every container. A safe starting point: 100m CPU and 128Mi memory.Missing resource limits
Missing resource limits
Default severity: MediumA container doesn’t have CPU or memory
limits set.Without limits, a misbehaving container can consume all available resources on a node, starving other workloads.Fix: Set resources.limits.cpu and resources.limits.memory on every container.Missing health probes
Missing health probes
Default severity: MediumA container doesn’t have a readiness or liveness probe configured.Without a readiness probe, Kubernetes routes traffic to a pod before it’s ready. Without a liveness probe, a stuck pod won’t be automatically restarted.Fix: Add at least a readiness probe. Liveness probes are recommended for long-running workloads.
Privileged container
Privileged container
Default severity: High (all environments)A container runs with
securityContext.privileged: true or securityContext.allowPrivilegeEscalation: true.Privileged containers have full access to the host kernel and can escape the container boundary. This is rarely needed for application workloads.Fix: Remove the privileged flag. If you need specific elevated capabilities (e.g. CAP_NET_ADMIN), use securityContext.capabilities.add to grant only what’s needed.Mutable image tag (latest)
Mutable image tag (latest)
Default severity: Low (non-production) · High (production)The container image uses a mutable tag such as
:latest, making deployments non-reproducible.Mutable tags mean the image that runs in production can change without a code change, making rollbacks harder and debugging more difficult.Fix: Pin to an explicit version tag (e.g. v1.2.3) or a digest. Use Image Automation to automate image bumps via PRs.Single replica
Single replica
Default severity: Info (non-production) · High (production)The Deployment has only one replica, providing zero redundancy.A single replica means any pod eviction, node reboot, or node failure will cause downtime.Fix: Set
replicas: 2 or more for production workloads. Consider adding a Pod Disruption Budget to prevent simultaneous eviction.Private registry without credentials
Private registry without credentials
Default severity: MediumA manifest references an image from a registry that requires authentication (GHCR, ECR, GCR, Quay.io) but no
imagePullSecret is configured.Without credentials, the agent will fail to pull the image, resulting in ImagePullBackOff.Fix: Add credentials in Registries. Niro injects the imagePullSecret automatically in generated manifests.Namespace mismatch
Namespace mismatch
Default severity: MediumThe deployment is being applied to a different namespace than the one specified in the manifests.This usually indicates a misconfiguration — either the manifests have the wrong namespace, or the deployment is targeting the wrong cluster.Fix: Ensure the target namespace in the deployment settings matches the namespace in the manifest files.
No rollback history
No rollback history
Default severity: Low (non-production) · Medium (production)The deployment has never had a successful apply, so there’s no previous version to roll back to.This is informational for newly created deployments. It resolves automatically after the first successful apply.
Environment escalation
Clusters tagged asproduction trigger stricter severity on risk-relevant rules:
Set the environment on a cluster in its Settings tab. See Environments for details.
Disabling findings
Individual findings can’t be suppressed per-deployment — the engine evaluates all rules. Use the severity filter in the dashboard to focus on what matters. Findings on non-production clusters for rules likesingle-replica are kept at Info severity specifically to reduce noise.
Related
Security Posture
The unified security view — built-in standards, external policy engine violations, and image scanning.
Visual Builder
See policy findings inline as you build — before deploying.
Set Up GitOps
Findings posted as PR comments on every manifest change.
Environments
How environment tagging affects severity escalation.