Comments (24)
The CVE-2023-5363 is also appeared in the 1.23.0 release. As I see a fix is already merged, what is the proposed date for the next release? Thank you!
from dns.
@BenTheElder any objections or considerations on using debian:latest instead of manual bumping?
Normally our base images are hosted at registry.k8s.io which doesn't have this, and we encourage image pinning (digests) for security + reproducibility reasons. In e.g. core kuebrnetes we avoid having releases depend directly on third party hosts.
from dns.
We are also finding the following in our security scans:
If they could be patched as well, that would be appreciated.
from dns.
Reusing this issue because even it's for version 1.23.0, it's the same issue.
Name: libc6, Version: 2.36-9+deb12u3
CVE-2023-6246, Severity: HIGH, Source: https://security-tracker.debian.org/tracker/CVE-2023-6246
CVSS score: 7.8, CVSS exploitability score: 1.8
🩹 Fixed version: 2.36-9+deb12u4
💥 Has public exploit
CVE-2023-6779, Severity: HIGH, Source: https://security-tracker.debian.org/tracker/CVE-2023-6779
CVSS score: 7.5, CVSS exploitability score: 3.9
🩹 Fixed version: 2.36-9+deb12u4
Name: libssl3, Version: 3.0.11-1~deb12u1
CVE-2023-5363, Severity: HIGH, Source: https://security-tracker.debian.org/tracker/CVE-2023-5363
CVSS score: 7.5, CVSS exploitability score: 3.9
🩹 Fixed version: 3.0.11-1~deb12u2
When a new versions is released we are not using the latest base image, neither running apt-get dist-upgrade
. I assume, because it's a distroless, that apt-get/dpkg commands are not available there, so we need to update the base image SHA when new versions are released, so when this repository has a new releases published the container image is built on top of latest distroless base image version with, presumably, latest security patches. As of today we are building on top of a base image released on Oct 31st 2023.
@DamianSawicki @irLinja tagging you here because I saw your last commit on upgrading dnsmasq to version 2.90 AND also bumping the debian BASEIMAGE, even though it looks like the node-local-cache image uses the IPTIMAGE
instead.
How can we make sure every new releases uses the latest version of gcr.io/distroless/base-debian11
and registry.k8s.io/build-image/distroless-iptables
respectively with the engineer in charge of releasing the new versions not having to remember that?
I see we use a dependabot config here but it looks like because the container image SHA is in the makefile and not in the Dockerfile
as a string dependabot is not catching it and not updating it.
I'm willing to try spend some time on this area, but I'd appreciate some feedback on this topic from upstream maintainers before getting hands-on.
from dns.
How can we make sure every new releases uses the latest version of
gcr.io/distroless/base-debian11
andregistry.k8s.io/build-image/distroless-iptables
respectively with the engineer in charge of releasing the new versions not having to remember that?I see we use a dependabot config here but it looks like because the container image SHA is in the makefile and not in the
Dockerfile
as a string dependabot is not catching it and not updating it.
@saschagrunert @cpanato @BenTheElder do we have some kind of automation for this?
from dns.
Using dependabot makes sense. We can manually update the image hash or remove it and use the latest tag (I know it's not the best solution) then find a proper solution to automate this.
I'm willing to work on the automation as well.
from dns.
How can we make sure every new releases uses the latest version of gcr.io/distroless/base-debian11 and registry.k8s.io/build-image/distroless-iptables respectively with the engineer in charge of releasing the new versions not having to remember that?
This shouldn't be waiting for releases, the project maintainers should be updating these regularly.
I don't know if dependabot can support our images.
We can manually update the image hash or remove it and use the latest tag (I know it's not the best solution) then find a proper solution to automate this.
there is no :latest tag for registry.k8s.io images, tags are immutable. if there is a :latest tag it is an old mistake and is not accurate. If you mean "latest" as in "most recent" then yes, using the most recent tag is reasonable, but you should really prefer to pin the digest for security reasons (this protects against the registry being compromised)
from dns.
There was this suggestion #610 from @jingyuanliang to use latest
for BASEIMAGE
(gcr.io
), but it hasn't been merged so far. Of course, this solution comes with the limitations and issues mentioned by @BenTheElder, so we should consider the pros and cons and decide.
How can we make sure every new releases uses the latest version of
gcr.io/distroless/base-debian11
andregistry.k8s.io/build-image/distroless-iptables
respectively with the engineer in charge of releasing the new versions not having to remember that?
Not a perfect solution, but for start, we can add a point about bumping base images to the release process instructions in the readme.
from dns.
Guys! thanks for taking up this discussion. As mentioned in this comment, our scanners are now reporting critical
vulnerability CVE-2024-2961
for package libc6 - 2.36-9+deb12u3
for both dns cache version 1.22.28
and 1.23.0
.
Would really appreciate if IPTIMAGE can be bumped to the latest version. Do we have any upcoming plans for this?
![Screenshot 2024-05-07 at 9 45 43 PM](https://private-user-images.githubusercontent.com/8899827/328726384-1893b272-1c26-42b9-a744-c9a6bf544429.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjEyOTc2ODQsIm5iZiI6MTcyMTI5NzM4NCwicGF0aCI6Ii84ODk5ODI3LzMyODcyNjM4NC0xODkzYjI3Mi0xYzI2LTQyYjktYTc0NC1jOWE2YmY1NDQ0MjkucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDcxOCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA3MThUMTAwOTQ0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9Y2Q1ODM0NzM1MjM0NjlhNzAzYTgwZTMxYmQ5YjA5OTFjYjdiNmM1YzA3YTY5NjIzYjE4M2NhZjdjMDZhMWRmMyZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.SY1U7uCc2CXQ0Y7NmIRTiyhmHzwOC_o8tCvdmyycgUk)
from dns.
Is there a reason to keep the base image on Debian 11? Debian 12 is the stable version, released almost a year ago.
from dns.
these are community images, everybody is welcome to send a PR
from dns.
I created #629 to bump images to the latest available as a temporary measure.
I looked into dependabot configurations, and unlike renovatebot, it's incapable of generic package upgrades.
from dns.
Thanks for PR-629. When can we expect a new release with these changes?
from dns.
There was this suggestion #610 from @jingyuanliang to use latest for BASEIMAGE (gcr.io), but it hasn't been merged so far.
@BenTheElder any objections or considerations on using debian:latest instead of manual bumping?
Looking at #610, it was ready to merge with no objections.
from dns.
This issue can be closed then.
Vulnerability fixes will be shipped with the next release.
from dns.
This issue can be closed then. Vulnerability fixes will be shipped with the next release.
/close
Thanks
from dns.
@aojea: Closing this issue.
In response to this:
This issue can be closed then. Vulnerability fixes will be shipped with the next release.
/close
Thanks
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
from dns.
@irLinja Thanks for the fix. Do we know when will be the next release/image, where this fix will be?
from dns.
@irLinja Thanks for the fix. Do we know when will be the next release/image, where this fix will be?
@golibali I've just cut a new release: https://github.com/kubernetes/dns/releases/tag/1.23.1.
from dns.
@DamianSawicki Awesome, thanks! One more thing, what is the process for creating a docker image from this release.
$> docker pull registry.k8s.io/dns/k8s-dns-node-cache:1.23.1
Error response from daemon: manifest for registry.k8s.io/dns/k8s-dns-node-cache:1.23.1 not found: manifest unknown: Failed to fetch "1.23.1"
from dns.
@DamianSawicki Awesome, thanks! One more thing, what is the process for creating a docker image from this release.
$> docker pull registry.k8s.io/dns/k8s-dns-node-cache:1.23.1 Error response from daemon: manifest for registry.k8s.io/dns/k8s-dns-node-cache:1.23.1 not found: manifest unknown: Failed to fetch "1.23.1"
@golibali Thanks for flagging this! Currently, the images are in gcr.io/k8s-staging-dns, and they will be promoted to registry.k8s.io/dns after kubernetes/k8s.io#6861 is merged.
from dns.
@DamianSawicki Awesome, thanks! One more thing, what is the process for creating a docker image from this release.
$> docker pull registry.k8s.io/dns/k8s-dns-node-cache:1.23.1 Error response from daemon: manifest for registry.k8s.io/dns/k8s-dns-node-cache:1.23.1 not found: manifest unknown: Failed to fetch "1.23.1"
@golibali Thanks for flagging this! Currently, the images are in gcr.io/k8s-staging-dns, and they will be promoted to registry.k8s.io/dns after kubernetes/k8s.io#6861 is merged.
Thanks for the info!
from dns.
@golibali The images are already in registry.k8s.io
(in the end, kubernetes/k8s.io#6861 was closed as a duplicate of an identical yet earlier PR).
from dns.
@golibali The images are already in
registry.k8s.io
(in the end, kubernetes/k8s.io#6861 was closed as a duplicate of an identical yet earlier PR).
Yes, thanks @DamianSawicki for the work!
from dns.
Related Issues (20)
- Output log as json HOT 3
- Using coredns daemonset instead of nodelocal dns HOT 20
- [Improvement] Add value compatibility for -upstreamsvc HOT 5
- [node-local dns] DNS requests intermittently receive refused response errors HOT 4
- Intermittent timed out accessing nodelocaldns HOT 2
- [NodeLocal DNS Cache] DNS requests not directed to the local cache HOT 2
- pull-kubernetes-dns-test broken at head HOT 2
- Several old CVE's still present on the latest k8s-dns-node-cache versions HOT 4
- Image for 1.22.27 missing HOT 3
- [node-local-dns] Query loss HOT 5
- k8s node-local-dns high slab memory consumption leading to OOM HOT 1
- 1.23.0 is missing from registry.k8s.io/dns/k8s-dns-node-cache HOT 2
- node-local-dns-cache DNS i/o timeout errors HOT 1
- "make build-amd64" got an error HOT 1
- LocalDNS support for CoreDNS file plugin HOT 1
- NodeLocal DNS Cache Intercepts all dns queiris HOT 7
- kube-dns doesn't expose service scoped dns names for pod IPs
- Getting UnkownHostException from SpringBoot Microservice running on top of kubernetes HOT 2
- Latency/timeout from Kube DNS
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dns.