This article is based on reporting originally published at searchitoperations.techtarget.com. All quotes are attributed to Jason Harris, VP of Cloud Architecture at Aptos, as reported in that source.
From Container Scanning to Kubernetes-Wide Security
For enterprises deploying microservices in production, the security conversation has moved decisively upward in the stack. Where early container security tooling concentrated on scanning individual container images inside the CI/CD pipeline, the industry has shifted toward securing the entire Kubernetes platform — network policies, cluster configuration, runtime behaviour, and all.
Early specialists such as Aqua, Twistlock, and StackRox began with image scanning, then added host-agent-based runtime scanning for live workloads. More recently those products have expanded to include network-based security controls and policy-driven enforcement mechanisms that operate at the Kubernetes cluster level rather than the individual container level. Newer entrants such as Octarine took a different approach, plugging directly into the network service mesh layer to provide deeper traffic visibility.
This evolution mirrors growing maturity among enterprise adopters who are grappling with the security implications of running dozens — or hundreds — of microservices across dynamic Kubernetes clusters.
Aptos: A Retail Software Vendor’s Kubernetes Journey
Atlanta-based Aptos, which builds software for retail clients, first deployed container-based microservices to support customer point-of-sale (POS) systems in late 2018. By the second half of 2019, the team recognised they needed a dedicated tool to automate and enforce Kubernetes security at scale.
“With microservices and containers in general, there’s opportunity to multiply your security risk exponentially, and they multiply the number of points [in the infrastructure] that need to be analyzed. Kubernetes is our means of delivering microservices, and we’re looking at it as a way to deploy applications securely as well.”
— Jason Harris, VP of Cloud Architecture, Aptos
Aptos evaluated products from Aqua, Twistlock, Qualys, and StackRox before selecting StackRox. The deciding factor was StackRox’s emphasis on container runtime security in the context of the Kubernetes platform, rather than treating containers as isolated units to be scanned independently.
Why Kubernetes Context Matters for Runtime Security
Harris described microservices as “layers of containers that deliver a service,” which may incorporate open-source components or potentially rogue containers. In a Kubernetes environment, workloads move — pods are rescheduled, nodes are replaced, clusters scale up and down. This dynamism makes static, host-centric security models increasingly inadequate.
“[Within] Kubernetes in general, [resources] move, and that’s where StackRox adds value: looking into Kubernetes in addition to the containers.”
— Jason Harris, VP of Cloud Architecture, Aptos
This distinction — security visibility scoped to the Kubernetes control plane rather than just the container runtime — is increasingly important as clusters grow in size and complexity.
DaemonSet Deployment: Simpler Cluster-Wide Coverage
A key architectural selling point for Aptos was how StackRox deploys within Kubernetes clusters. StackRox runs as a privileged DaemonSet — a Kubernetes workload type that automatically runs a copy of a pod on every node in the cluster, including any nodes added later.
This approach has practical operational benefits:
- Automatic coverage of new nodes: When Aptos provisions a new cluster or scales an existing one, the DaemonSet ensures the security agent is present on every node without manual intervention.
- Simplified onboarding: Rather than running a separate deployment step per host, the DaemonSet setup is wrapped into the cluster provisioning process itself.
- Consistency: Every node runs identical agent configuration, reducing configuration drift.
“When we deploy a new cluster, it’s just wrapped into that process. Once you establish that DaemonSet in the cluster, any new nodes are going to inherit the daemon automatically.”
— Jason Harris, VP of Cloud Architecture, Aptos
The alternative — deploying a privileged security container on each individual host — requires more orchestration overhead and is more error-prone in fast-moving environments.
Kubernetes Security Visibility as a Compliance Tool
Teams that use host-agent-based Kubernetes security tools typically automate agent deployment through infrastructure-as-code (IaC) tools such as Terraform. StackRox supplemented this with strong visibility into Kubernetes cluster configuration itself — a feature Aptos found unexpectedly valuable for regulatory compliance reporting.
“StackRox recently added a configuration management app that we’ve gotten far more value out of than we expected, because it’s turning into a good reporting tool on our Kubernetes ecosystem. It’s hard to have visibility into just even simple things like the number of clusters [in production] and the number of nodes [within them], and what’s my Kubernetes version on all those clusters?”
— Jason Harris, VP of Cloud Architecture, Aptos
Being able to present auditors with a comprehensive, accurate view of the Kubernetes environment — including cluster count, node count, and Kubernetes version across all clusters — is a practical compliance requirement that often gets overlooked in security tool evaluations.
Remaining Challenges and Future Priorities
Kubernetes security is not a solved problem, and Aptos faces ongoing challenges as the retail industry demands richer microservices-based mobile applications. Supporting publicly hosted mobile app store APIs and handling customer payment data will raise the stakes further, introducing additional attack surface that must be secured at the Kubernetes platform level.
Harris acknowledged that container image scanning within registries remained an area where StackRox lagged behind some competitors and dedicated registry tools such as Red Hat Quay. The specific capability he described needing:
“The view we needed was, ‘OK, show me this vulnerability across all my images, and if I flip to an image, show me any vulnerabilities above a certain level.'”
— Jason Harris, VP of Cloud Architecture, Aptos
According to a StackRox spokesperson cited in the original reporting, a feature providing cross-registry vulnerability views with severity filtering was previewed at KubeCon in November 2019 and was expected to reach general availability in February 2020.
Key Takeaways for DevOps and Platform Engineering Teams
- Evaluate security tools at the platform level, not just the container level. Container image scanning is necessary but insufficient; Kubernetes-aware runtime security that understands pod scheduling, network policies, and cluster configuration provides meaningfully better coverage.
- Consider deployment architecture in your tool evaluation. A DaemonSet-based deployment model reduces operational overhead compared to per-host agent installation, especially in clusters that scale frequently.
- Security tooling can double as a compliance reporting asset. Cluster configuration visibility — versions, node counts, policy state — is genuinely useful for audit purposes and is worth weighting in tool selection.
- Infrastructure-as-code and policy-based security automation compound each other’s benefits. Consistent, automated cluster provisioning paired with automated security enforcement reduces configuration drift and improves overall security posture.
- No single tool covers every layer equally well. Aptos found StackRox strong on runtime and Kubernetes-context security, but weaker on registry image scanning — a reminder to assess tools against your specific priority stack.
“The visibility and the control we have in this world far outweighs the drift that you had in the older world. I’ll take the problems in the new world any day over our legacy challenges.”
— Jason Harris, VP of Cloud Architecture, Aptos