add hardened (Wolfi) images documentation for ECK#6822
Conversation
Elastic Docs AI PR menuCheck the box to run an AI review for this pull request.
Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team. |
4564b65 to
641ea30
Compare
🔍 Preview links for changed docs |
✅ Elastic Docs Style Checker (Vale)No issues found on modified lines! The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale. |
|
Adding some context from: https://docs.google.com/document/d/1beldfKbkAJAJsnyiTuW5-aWZwqa0BIKRSOdNs4kdUzI/edit?tab=t.0 |
There was a problem hiding this comment.
Docs review summary
Focus areas
- Style and clarity: Generally clear and well-structured. No Vale findings. The prose follows Elastic style conventions.
- Jargon: Appropriate use of ECK-specific terminology with sufficient context. Acronyms are expanded on first use.
- Frontmatter and applies_to: Missing required
descriptionfield. Theapplies_toandproductsfields are correctly structured per the cumulative docs reference. - Content type fit: The page functions as an overview/reference explaining the Wolfi images feature. Structure is appropriate with clear sections for the operator vs. Stack images.
- Parent issue satisfaction: Not applicable (PR mentions "issue number TBD" with no linked issue).
Notes
- The warning admonition about EPR and EMS is helpful and appropriately placed—it addresses a real operational issue users will encounter when setting
container-suffix. - The frontmatter uses correct
applies_tosyntax withdeployment.eck: allper the cumulative docs reference. - Consider whether version numbers like "v8.16.0" and "v8.15.0" in line 30 could become stale quickly. If these versions are subject to change, consider linking to release notes or using more general guidance.
Generated by Docs review agent for issue #6822 · ● 841.1K
Adds a new page `deploy-manage/deploy/cloud-on-k8s/hardened-images.md` documenting Wolfi-based (hardened) images in ECK: - The ECK Operator image is Wolfi by default since v2.15.0 - Stack images (ES, Kibana, Agent, Beats, APM Server, Logstash) can be pulled as Wolfi variants via the `container-suffix: -wolfi` operator flag - EPR and Elastic Maps Server images are already natively Wolfi and require an explicit `.spec.image:` override to avoid pull failures when `container-suffix` is set Also adds an entry for the new page in `manage-deployments.md`. 1. Did you use a generative AI (GenAI) tool to assist in creating this contribution? - [x] Yes Tool(s) and model(s) used: Claude Code (claude-sonnet-4-6)
7748229 to
af14154
Compare
shainaraskas
left a comment
There was a problem hiding this comment.
thanks for writing this up.
overall, wondering if we want people to use wolfi images over other types of images.
if so, we should be surfacing this content (using links or other means) on a few other pages, to raise awareness at the decision point:
https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6822/deploy-manage/deploy/cloud-on-k8s/install-using-yaml-manifest-quickstart
https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6822/deploy-manage/deploy/cloud-on-k8s/configure-eck
https://docs-v3-preview.elastic.dev/elastic/cloud-on-k8s/tree/main/reference/eck-configuration-flags (cloud-on-k8s repo)
https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6822/deploy-manage/deploy/cloud-on-k8s/air-gapped-install
and to help people to do the right thing, we might need to explain how to do this with helm, and warn of the incompatibiity with wolfi on the maps/epr-specific pages. let me know what you think.
I'll also put an item in our backlog to try to surface the wolfi story a little higher up (we don't do as good of a job with this in our vanilla self-managed docs)
| - file: deploy/cloud-on-k8s/hardened-images.md | ||
| - file: deploy/cloud-on-k8s/create-custom-images.md |
There was a problem hiding this comment.
because this applies to both the orchestrator and the stack images (and both the "core" stack and the more optional applications), I don't think this placement is exactly right. I'd move it up a level (pull it out of the Orchestrate other Elastic applications section)
| - file: deploy/cloud-on-k8s/hardened-images.md | |
| - file: deploy/cloud-on-k8s/create-custom-images.md | |
| - file: deploy/cloud-on-k8s/hardened-images.md | |
| - file: deploy/cloud-on-k8s/create-custom-images.md |
| - [**Apply updates to your deployments**](./update-deployments.md): Modify existing deployments, scale clusters, and update configurations, while ensuring minimal disruption. | ||
| - [**Configure access to your deployments**](./accessing-services.md): Use and adapt Kubernetes services to your needs. | ||
| - [**Advanced configuration**](./configure-deployments.md): Explore available settings for {{es}} and {{kib}}, including storage, networking, security, and scaling options. | ||
| - [**Hardened (Wolfi) images**](./hardened-images.md): Learn how the ECK Operator and the {{stack}} components managed by ECK use Wolfi-based images to reduce CVE exposure, and what this means in practice. |
There was a problem hiding this comment.
this page is not nested under this section, so the xlink needs to not be under this section but instead under "Other references for managing deployments:"
this should also probably be linked from the following pages:
| - id: logstash | ||
| --- | ||
|
|
||
| # Hardened (Wolfi) images in {{eck}} [k8s-hardened-images] |
There was a problem hiding this comment.
we try to avoid brackets in titles. would either go with "Hardened Wolfi images" "Wolfi-hardened images" (I've seen both of these) or "Hardened images"
to decide between these: do our users care more about the hardening or the technology used to do the hardening? if the former, skip "Wolfi" in the title
There was a problem hiding this comment.
@jeanfabrice wdyt we say "Wolfi-based Hardened Docker images"
Wolfi-based appeared in the blog - link we are referring to.
Hardened Docker images appeared in the ES docs - link too.
Also, IMHO,
- "Hardened docker image" is a thing, means more secure docker image
- "Wolfi-based" is a thing (more of a modifier), to explain the technology of how to achieve the "hardened docker image", which is wolfi-based.
| Only images distributed via `docker.elastic.co` are officially supported by Elastic. Third-party hardened image sources, such as Docker Hardened Images (DHI) on Docker Hub, are not maintained by Elastic and fall outside the scope of Elastic support. | ||
| :::: | ||
|
|
||
| ## The ECK Operator image [k8s-hardened-images-operator] |
There was a problem hiding this comment.
| ## The ECK Operator image [k8s-hardened-images-operator] | |
| ## The ECK operator image [k8s-hardened-images-operator] |
|
|
||
| ## The ECK Operator image [k8s-hardened-images-operator] | ||
|
|
||
| Since ECK **v2.15.0**, the ECK Operator image is built on Wolfi by default. No additional configuration is required — pulling the standard operator image from `docker.elastic.co` already provides a hardened, Wolfi-based container. |
There was a problem hiding this comment.
| Since ECK **v2.15.0**, the ECK Operator image is built on Wolfi by default. No additional configuration is required — pulling the standard operator image from `docker.elastic.co` already provides a hardened, Wolfi-based container. | |
| Since ECK 2.15, the ECK operator image is built on Wolfi by default. No additional configuration is required —pulling the standard operator image from `docker.elastic.co` already provides a hardened, Wolfi-based container. |
There was a problem hiding this comment.
Do we want to also refer to our code base?
I can see in the blog - link, we refer to the code base.
I guess it might be friendly to user if we can show them the codebase - https://github.com/elastic/cloud-on-k8s/blob/v2.15.0/build/Dockerfile#L30, like we do in blog.
But I don't have strong opinion, and will leave the decision to you. :)
There was a problem hiding this comment.
@jeanfabrice @shainaraskas one more thing, do we want to say ECK operator ubi image also uses wolfi, per https://github.com/elastic/cloud-on-k8s/blob/v2.15.0/build/Dockerfile-ubi?
(Because @jeanfabrice we have "This flag cannot be combined with the --ubi-only flag." for stack images, my personal feeling is, logically thinking, users may want to know how ECK is handling ubi images, with wolfi or not).
There was a problem hiding this comment.
the ubi thing makes sense to me
referring to the code base might not be necessary because the updates under the hood are more of an implementation detail. users should be able to trust that we are keeping our dependencies up to date without us calling it out specifically.
There was a problem hiding this comment.
Chiming in here
@jeanfabrice @shainaraskas one more thing, do we want to say ECK operator ubi image also uses wolfi, per https://github.com/elastic/cloud-on-k8s/blob/v2.15.0/build/Dockerfile-ubi?
the above statement doesn't feel right. Looking here. Sure there is an intermediate builder image step that just builds the operator binary. Then for the final ubi we copy just the binary and uses the ubi base image. The end result is an ubi-based image that has nothing to do with wolfi.
There was a problem hiding this comment.
@pkoutsovasilis thanks. Is it a bug in ECK that we say it defaults to wolfi, but actually for ubi flavor, it is not?
There was a problem hiding this comment.
I am not sure I follow 😆 The default is the static target in the Dockerfile, linked above, which is indeed Wolfi-based, so what's the bug?! Additionally, in the same Dockerfile we define the target for ubi. To this end, replying to your previous point this doesn't make the ubi image use wolfi, these are separate images with different base
|
|
||
| # Hardened (Wolfi) images in {{eck}} [k8s-hardened-images] | ||
|
|
||
| Elastic has partnered with [Chainguard](https://www.chainguard.dev/) to provide hardened container images based on [Wolfi](https://github.com/wolfi-dev/os), a minimal, security-focused Linux distribution designed for containerized environments. These images significantly reduce the CVE footprint of Elastic containers by including only the application and its necessary runtime dependencies. For background on this initiative, refer to the blog post [Reducing CVEs in Elastic container images](https://www.elastic.co/blog/reducing-cves-in-elastic-container-images). |
There was a problem hiding this comment.
our other wolfi docs use this link
| Elastic has partnered with [Chainguard](https://www.chainguard.dev/) to provide hardened container images based on [Wolfi](https://github.com/wolfi-dev/os), a minimal, security-focused Linux distribution designed for containerized environments. These images significantly reduce the CVE footprint of Elastic containers by including only the application and its necessary runtime dependencies. For background on this initiative, refer to the blog post [Reducing CVEs in Elastic container images](https://www.elastic.co/blog/reducing-cves-in-elastic-container-images). | |
| Elastic has partnered with [Chainguard](https://www.chainguard.dev/) to provide hardened container images based on [Wolfi](https://wolfi.dev), a minimal, security-focused Linux distribution designed for containerized environments. These images significantly reduce the CVE footprint of Elastic containers by including only the application and its necessary runtime dependencies. For background on this initiative, refer to the blog post [Reducing CVEs in Elastic container images](https://www.elastic.co/blog/reducing-cves-in-elastic-container-images). |
There was a problem hiding this comment.
Is Elastic has partnered with Chainguard an official statement?
| Elastic has partnered with [Chainguard](https://www.chainguard.dev/) to provide hardened container images based on [Wolfi](https://github.com/wolfi-dev/os), a minimal, security-focused Linux distribution designed for containerized environments. These images significantly reduce the CVE footprint of Elastic containers by including only the application and its necessary runtime dependencies. For background on this initiative, refer to the blog post [Reducing CVEs in Elastic container images](https://www.elastic.co/blog/reducing-cves-in-elastic-container-images). | ||
|
|
||
| ::::{note} | ||
| Only images distributed via `docker.elastic.co` are officially supported by Elastic. Third-party hardened image sources, such as Docker Hardened Images (DHI) on Docker Hub, are not maintained by Elastic and fall outside the scope of Elastic support. |
There was a problem hiding this comment.
| Only images distributed via `docker.elastic.co` are officially supported by Elastic. Third-party hardened image sources, such as Docker Hardened Images (DHI) on Docker Hub, are not maintained by Elastic and fall outside the scope of Elastic support. | |
| Only images distributed through `docker.elastic.co` are officially supported by Elastic. Third-party hardened image sources, such as Docker Hardened Images (DHI) on Docker Hub, are not maintained by Elastic and fall outside the scope of Elastic support. |
| eck.yaml: |- | ||
| container-suffix: -wolfi |
There was a problem hiding this comment.
how is this done with helm?
| container-suffix: -wolfi | ||
| ``` | ||
|
|
||
| ::::{warning} |
There was a problem hiding this comment.
do EPR and maps-server install pages need a warning about this?
There was a problem hiding this comment.
++ on having a section in those two pages about wolfi, mention "wolfi image enabled by default for the two products", and when use in ECK, if user specify container-suffix: -wolfi to run wolfi on other stack images, they need to pay addition attention to follow what @jeanfabrice wrote in the warning block.
|
|
||
| Since ECK **v2.15.0**, the ECK Operator image is built on Wolfi by default. No additional configuration is required — pulling the standard operator image from `docker.elastic.co` already provides a hardened, Wolfi-based container. | ||
|
|
||
| ## {{stack}} images managed by {{eck}} [k8s-hardened-images-stack] |
There was a problem hiding this comment.
| ## {{stack}} images managed by {{eck}} [k8s-hardened-images-stack] | |
| ## {{stack}} images managed by ECK [k8s-hardened-images-stack] |
kunisen
left a comment
There was a problem hiding this comment.
Overall, it looks super nice and thanks for drafting @jeanfabrice.
From support perspective, I left some comments about some pointers I feel we might want to consider. A few of them are more cosmetic changes, where I would also leave it to your decision to see if we want to make the change or not.
=> Once you can confirm and provide your updates, I think we should be good to go.
Furthermore, I would also suggest we collaborate with ECK dev to take a look. I see there's no ECK dev review yet. Please feel free to let me know if you prefer me to bridge this to ECK dev for review too.
Also per a previous conversation with @\eedugon, I understand docs team (@shainaraskas) also has the authority to review it from admin point of view, which is on behalf of ECK dev. So if Shaina is happy with the content (without ECK dev review), then we can skip that step.
| - id: logstash | ||
| --- | ||
|
|
||
| # Hardened (Wolfi) images in {{eck}} [k8s-hardened-images] |
There was a problem hiding this comment.
@jeanfabrice wdyt we say "Wolfi-based Hardened Docker images"
Wolfi-based appeared in the blog - link we are referring to.
Hardened Docker images appeared in the ES docs - link too.
Also, IMHO,
- "Hardened docker image" is a thing, means more secure docker image
- "Wolfi-based" is a thing (more of a modifier), to explain the technology of how to achieve the "hardened docker image", which is wolfi-based.
|
|
||
| ## The ECK Operator image [k8s-hardened-images-operator] | ||
|
|
||
| Since ECK **v2.15.0**, the ECK Operator image is built on Wolfi by default. No additional configuration is required — pulling the standard operator image from `docker.elastic.co` already provides a hardened, Wolfi-based container. |
There was a problem hiding this comment.
Do we want to also refer to our code base?
I can see in the blog - link, we refer to the code base.
I guess it might be friendly to user if we can show them the codebase - https://github.com/elastic/cloud-on-k8s/blob/v2.15.0/build/Dockerfile#L30, like we do in blog.
But I don't have strong opinion, and will leave the decision to you. :)
|
|
||
| ## {{stack}} images managed by {{eck}} [k8s-hardened-images-stack] | ||
|
|
||
| Wolfi-based variants of the {{stack}} images ({{es}}, {{kib}}, {{agent}}, {{beats}}) are available from v8.16.0 onwards (v8.15.0 for {{apm-server}} and {{ls}}). However, ECK does not pull Wolfi variants by default for {{stack}} components — the standard images are used unless explicitly overridden. |
There was a problem hiding this comment.
@shainaraskas should we do sth like a more human readable list?
It seems like we have many images.
https://github.com/elastic/cloud-on-k8s/blob/main/pkg/controller/common/container/container.go#L55-L70
Also per our (public) KB:
https://support.elastic.co/knowledge/662e34c1
My personal vote would be something like we have in KB:
- APM Server & Logstash: 8.15.0+
- Elasticsearch, Kibana, Elastic Agent, Beats (e.g. Filebeat, Metricbeat, Auditbeat, Packetbeat, Heartbeat, etc.), & Enterprise Search: 8.16.0+
But again, this is just a cosmetic thing and I don't have strong opinion :)
|
|
||
| ## The ECK Operator image [k8s-hardened-images-operator] | ||
|
|
||
| Since ECK **v2.15.0**, the ECK Operator image is built on Wolfi by default. No additional configuration is required — pulling the standard operator image from `docker.elastic.co` already provides a hardened, Wolfi-based container. |
There was a problem hiding this comment.
@jeanfabrice @shainaraskas one more thing, do we want to say ECK operator ubi image also uses wolfi, per https://github.com/elastic/cloud-on-k8s/blob/v2.15.0/build/Dockerfile-ubi?
(Because @jeanfabrice we have "This flag cannot be combined with the --ubi-only flag." for stack images, my personal feeling is, logically thinking, users may want to know how ECK is handling ubi images, with wolfi or not).
| container-suffix: -wolfi | ||
| ``` | ||
|
|
||
| ::::{warning} |
There was a problem hiding this comment.
I get your point @shainaraskas, but my vote is to leave it there as a whole piece, since this is really an important one. Not following this correctly will cause image not being pulled correctly.
This is a product level gap, and if we can have
- ECK operator flag to enable wolfi stack images,
- and inside the operator logic,
- it automatically and smartly understand what images are default to wolfi,
- what are required to add
container-suffix: -wolfito apply wolfi,
- and inside the operator logic,
Then we can significantly simplify this block as a simple sentence - use that flag.
Before we get there, I would prefer we have this warning significant enough to raise good awareness.
| container-suffix: -wolfi | ||
| ``` | ||
|
|
||
| ::::{warning} |
There was a problem hiding this comment.
++ on having a section in those two pages about wolfi, mention "wolfi image enabled by default for the two products", and when use in ECK, if user specify container-suffix: -wolfi to run wolfi on other stack images, they need to pay addition attention to follow what @jeanfabrice wrote in the warning block.
We don't review on behalf of ECK dev per se. Because this is a brand new page, I would want eng to take a look. |
What I meant in our previous conversations is that we have the capacity of determining if we need devs and / or PMs review or not, case by case. In this case I'd say we need it, in alignment with @shainaraskas :)
I agree, as this is a new doc we need alignment with PMs & cloud-on-k8s folks to ensure the doc and message is what we want to provide. Anyway the doc and plan looks good to me, thanks @jeanfabrice for working on this! @pkoutsovasilis , as you have already shared some thoughts, would you please be able to let us know if you agree on adding this doc and if the content is all accurate? Feel free to ping a PM if you think it's needed. |
|
@eedugon 👋 the topic of this PR has been raised to the @elastic/cloud-k8s-operator team and it is already set as an agenda point for discussion in our upcoming team meeting. Thus I would propose to hold off for a little longer until there is an common agreement on how we would like to approach the wolfi variant. |
|
Closing this PR in favor of a different approach. After internal discussion, we've decided to split the two aspects covered here:
A new PR will follow shortly for point 1. |
Summary
Adds a new page
deploy-manage/deploy/cloud-on-k8s/hardened-images.mddocumenting Wolfi-based (hardened) images in ECK:container-suffix: -wolfioperator flag.spec.image:override to avoid pull failures whencontainer-suffixis setAlso adds an entry for the new page in
manage-deployments.md.Closes #(issue number TBD)
Generative AI disclosure
Tool(s) and model(s) used: Claude Code (claude-sonnet-4-6)