Peter Lees told iTWire in response to queries that the whole point of containers was to be able to get new functionality out quickly. "And in modern development that often means gluing together micro-services from many different sources, which in turn could mean that the ultimate source of those functions may not have been vetted," he said.

Container security was in the limelight in April when the credentials of some 190,000 account holders at Docker Hub, the official repository for Docker container images, were exposed due to "a brief moment of unauthorised access".

At the time, Lavi Lazarovitz, Security Research Team Lead at privileged account security firm CyberArk, said the breach could lead to a classic supply chain attack made possible, seemingly, by compromise of privileged tokens.

Lees pointed out that a 2017 paper had shown that up to 80% of the images on DockerHub contained a severe vulnerability. "So the 'quick and dirty' approach to development can end up introducing vulnerabilities into a system," he added.

SUSE, which developed a container-as-a-service offering back in 2017, has some standard processes which would help to mitigate risks when working with containers, Lees said.

He advised the following:

• "use a private registry for 'vetted' containers so that you can be sure what’s inside the components that developers use (SUSE introduced the Portus project a few years ago to give enterprise-level security to the onsite Docker Registry);
• "use an enterprise-supported OS as the base image for the container: that way you know someone is going to be working on security issues (sometimes before they are made public);
• "have a process and tools to review and patch externally-sourced containers (openSUSE and SLE images can be patched with zypper-docker to bring them up to date: other systems require everything to be rebuilt from scratch)'
• "compartmentalise applications within different Kubernetes clusters for different security tiers: don’t mix and match security and risk profiles within a single environment;
• "avoid using privileged containers wherever possible: if the container runtime is essentially 'root', then any break-out from the container could potentially run as root. Never run unknown containers in privileged mode; and
• "constrain what container runtimes can do by using the AppArmor security module or similar; this gives a higher level of auditing and defensive capability within the host node."

Said Lees: "So there’s a lot of operational things that can be done to mitigate the risk of using containers - just as is the case with non-containerised environments. The trick is to enforce these policies in the development environment while still maintaining the ability to make changes and updates at speed. There’s a paper from NIST which probably has one of the most comprehensive set of recommendations.

"Having said all that – container technology is really powerful and effective, especially when combined with the concept of micro-services and agile project methodology."

He said SUSE was retaining the focus on enterprise-class requirements for its software infrastructure layers, to try to make the right tools available in a supported way, and also to set sensible defaults for least-privilege.

"[In other words], creating the best operational experience for our Kubernetes distribution is one way we are trying to make managing all this easier," Lees added.