Patterns for secure container base image management
Presentation from SnykCon 2020, all about the people, process and tools needed to manage container base images. Thoughts about team organisation, trade-offs and examples of how to use Snyk to solve this problem.
dependencies for known issues, found 180 issues. Debian 8 is no longer supported by the Debian maintainers. Vulnerability detection may be affected by a lack of security updates. You test an image for vulnerabilities and find LOTS of issues 100s of vulnerabilities! It’s using an out-of-date operating system! Who owns this image? Who is responsible for fixing vulnerabilities? How many other images like this do we have? Help!
software giants It’s common with container images to start building on top of an existing base image that already has software you want. This might be an operating system like ubuntu, alpine or debian or it could be a language like python, ruby, node or really anything else. OK, technically often a parent image but hey. Libraries and underlying software provided by someone else Your software
common hardening or configuration changes or maybe metadata it wants to apply to all images in use by other teams. This is often intended to be common for all images used. Maybe you have myorg/base Libraries and underlying software provided by someone else Hardening, common configuration Common software Your application
common software or middleware. This might be language or framework specific, say a separate image for Java (myorg/java) and another for Python (myorg/python). Libraries and underlying software provided by someone else Hardening, common configuration Common software Your application
whether in source or binary form. And metadata specific to the application. Libraries and underlying software provided by someone else Hardening, common configuration Common software Your application
When considering container vulnerabilities, you want to be able to reason about vulnerabilities in images you’re running, but also understand the overlap and source of those vulnerabilities. Can you address a vulnerability once, and have it resolved everywhere?
else Hardening, common configuration Common software Your application Libraries and underlying software provided by someone else Hardening, common configuration Common software Your application Libraries and underlying software provided by someone else Hardening, common configuration Common software Your application One team to rule them all This could be the case when teams are completely independent, or when you have one central image team. A base image team A team which provides a standard set of approved base images for application teams to consume. Separate base/security teams Larger organizations might have teams with more distinct responsibilities, potentially with even more layers.
Simple to understand responsibilities. CONS Potential for chaos if every team can do their own thing. One central team for ALL images likely to become a bottleneck. A base image team PROS Able to build strong domain expertise in the center, ideally fix/triage issues once. CONS Needs some level of governance in order to ensure applications teams benefit from central expertise. Separate base/security teams PROS Same as having a base image team, with the added advantage of deeper specialisms. CONS Coordination between additional teams can slow down the process.
Introduced by your base image (python:3.6.0-slim) Fixed in: 5.28.1-6+deb10u1 ✗ High severity vulnerability found in gnutls28/libgnutls30 Description: Out-of-bounds Write Info: https://snyk.io/vuln/SNYK-DEBIAN10-GNUTLS28-609778 Introduced through: gnutls28/[email protected]+deb10u4, [email protected] From: gnutls28/[email protected]+deb10u4 From: [email protected] > gnutls28/[email protected]+deb10u4 Introduced by your base image (python:3.6.0-slim) Tested 111 dependencies for known issues, found 178 issues.
--file=base/Dockerfile Updated when new vulnerabilities are disclosed Snyk will send you alerts via email or Slack as well when new vulnerabilities are discovered in the packages you’re using.
--file=middleware/Dockerfile ... Tested 127 dependencies for known issues, found 180 issues. Vulnerabilities from the base image and the new instructions But a different team is responsible for some of these, so let’s reason about those separately.
\ --policy-path=ignores/middleware.snyk We can still see all the vulnerabilities in the image Understand the risk, while acknowledging fixing is someone else’s responsibility.
plays by the rules. There is a useful balance between centrally enforced policies and encouraging best practices. How do you make it as easy as possible for consumers of base images to do the right thing?
Decision (any JSON value) Data (JSON) Policy (Rego) Request, Event, etc. Declarative Express policy in a high-level, declarative language that promotes safe, performant, fine-grained controls. Use a language purpose-built for policy in a world where JSON is pervasive. Context-aware Leverage external information to write the policies you really care about. Write logic that adapts to the world around it and attach that logic to the systems that need it.
input.vulnerabilities[index] issue.severity = "high" msg = sprintf("High severity issue found. package: %v issue: %v", [issue.name, issue.title]) } A Rego example This is the Open Policy Agent language for describing policies. Here we’re saying we want to prohibit any images with known high-severity vulnerabilities. REGO
--json | conftest test - FAIL - Not using a permitted base image: ghcr.io/garethr/snykt/middleware 4 tests, 3 passed, 0 warnings, 1 failure, 0 exceptions
--file=app/Dockerfile --json | conftest test - 4 tests, 4 passed, 0 warnings, 0 failure, 0 exceptions To enforce or not to enforce? Over time it’s best to move towards enforcing policies automatically, but to start with you’ll probably want to roll out slowly and carefully. You might already have these policies written down, but unless you’re automatically checking or enforcing you’ll likely have a long tail of images in breach. The advantage of Snyk is you can help developer test early in the SDLC, on the local machine or in CI, when it’s fast and cheap to fix the problem.
between teams Using Snyk in your CI pipeline allows for automating this or other patterns for managing container images securely. Investing in good practices around CI should help security, build, operations and development teams work more closely together.
Different organizations, and different teams, might manage base images differently. The Snyk API makes it easy to build custom dashboards or use the data about base images for reporting. snyk.docs.apiary.io
garethr
lycorp_recruit_jp
bbqallstars
sinsoku
gumamon
tubone24
salaboy
shonansurvivors
onk
shujisado
smt7174
notwaldorf
sferik
bkeepers
sergeychernyshev
tammyeverts
bermonpainter
ddemaree
thoeni
davidbonilla
garrettdimon
jponch
![Prohibiting high severity issues package main deny[msg] { issue =](https://files.speakerdeck.com/presentations/2639c8888c0d4460b252ebe9a90883f2/slide_32.jpg){kind=link}
![Watching out for crypto issues package main deny[msg] { issue](https://files.speakerdeck.com/presentations/2639c8888c0d4460b252ebe9a90883f2/slide_33.jpg){kind=link}
