Container and Kubernetes security: least privilege, RBAC and image scanning

A container bundles an application with its libraries and settings so it runs the same way everywhere. Docker made containers mainstream; Kubernetes became the common way to run many of them across many machines. Both change security in useful ways, because containers are small, disposable and defined in code. They also introduce new risks, because containers share the host’s kernel, images are often pulled from public registries, and orchestration platforms hold enormous power over everything they run.

NIST SP 800-190, the Application Container Security Guide, groups container risks into five areas: images, registries, the orchestrator, the containers themselves and the host operating system. The controls below follow that structure.

Images: know what you run

• Start from small, maintained base images from trusted publishers; fewer packages means fewer vulnerabilities.
• Scan images for known vulnerable packages in the pipeline and again in the registry, because new vulnerabilities are published after an image is built.
• Never bake secrets into images: anyone who can pull the image can extract them.
• Sign images and verify signatures before deployment, as covered in the previous lesson.
• Rebuild regularly rather than patching running containers.

Containers: least privilege

By default, many containers run as root inside the container. If an attacker breaks out, or the container is misconfigured to share host resources, that root access can become root on the host. Docker’s security documentation recommends reducing privileges, and its rootless mode runs the Docker daemon and containers as an unprivileged user, which limits the damage of a breakout.

Kubernetes: RBAC and Pod Security Standards

Kubernetes role-based access control (RBAC) decides who and what can do which actions on which resources. Roles and ClusterRoles define permissions; RoleBindings and ClusterRoleBindings grant them to users, groups or service accounts. The common mistakes are granting cluster-wide admin rights for convenience, and giving application service accounts permissions they never use. The rule is the same as everywhere else: the smallest set of permissions, in the narrowest scope, for each identity.

Kubernetes also defines three Pod Security Standards: Privileged (unrestricted), Baseline (prevents known privilege escalations) and Restricted (follows current hardening best practice). The built-in Pod Security Admission controller can enforce a standard per namespace, so a workload that asks for dangerous settings is rejected before it runs.

• Enforce Baseline everywhere and Restricted wherever the workload allows it.
• Use network policies so pods can only talk to what they need.
• Keep the control plane and nodes patched, and restrict access to the Kubernetes API.
• Store secrets in a proper secrets store and enable encryption for them at rest.
• Collect audit logs from the cluster and watch for unexpected permission changes.

Where FireAI fits

FireAI does not secure clusters or scan images; those controls live in your pipeline and platform. On a developer’s Mac, it works per app: it shows and controls the connections of the container tooling like any other app, and its rules follow that app’s verified code signature.