Trust Datadog CA certs in OS and all JDK truststores#174
Trust Datadog CA certs in OS and all JDK truststores#174AlexeyKuznetsov-DD wants to merge 1 commit into
Conversation
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
AlexeyKuznetsov-DD
had a problem deploying
to
ci-build
GitHub Actions
Failure
AlexeyKuznetsov-DD
had a problem deploying
to
ci-build
GitHub Actions
Failure
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d8d22acd15
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| EOT | ||
|
|
||
| # Stage the Datadog CA certs and import script, and trust the certs at the OS level. | ||
| COPY --from=datadog-ca-certs /certs/datadog /usr/local/share/ca-certificates/datadog |
There was a problem hiding this comment.
These certificates are added only in all-jdk-common, but the published base/variant/full images start again from a fresh ubuntu:24.04 stage and later copy only /usr/lib/jvm from default-jdk, so the updated /usr/local/share/ca-certificates and /etc/ssl/certs state is discarded. In those final images, non-Java tools such as curl, git, or datadog-ci still won't trust Datadog-internal TLS endpoints even though this change is intended to add OS-level trust.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch, but we need to support only Gradle (Java tool) so far.
| COPY --from=ibm8-amd64 /opt/ibm/java /usr/lib/jvm/ibm8 | ||
|
|
||
| # Import the Datadog CA certs into the amd64-only ibm8 truststore. | ||
| RUN sudo /usr/local/bin/import-datadog-certs.sh /usr/lib/jvm/ibm8 |
There was a problem hiding this comment.
After all-jdk-common imports certificates, the amd64 stage copies in both the legacy zulu7 JDK and ibm8, but this new import only covers /usr/lib/jvm/ibm8. As a result, the 7/zulu7 image keeps the upstream zulu7 cacerts unchanged and Java 7 jobs still fail to trust Datadog-internal endpoints.
Useful? React with 👍 / 👎.
AlexeyKuznetsov-DD
had a problem deploying
to
ci-build
GitHub Actions
Failure
AlexeyKuznetsov-DD
had a problem deploying
to
ci-build
GitHub Actions
Failure
|
🔄 Datadog auto-retried 1 job - 0 passed on retry 🔗 Commit SHA: d8d22ac | Docs | Datadog PR Page | Give us feedback! |
|
We can not use |
1 participant
What Does This Do
Adds the Datadog CA certificates to the build image so outbound TLS to Datadog-internal endpoints is trusted:
registry.ddbuild.io/images/datadog-ca-certs:standard.update-ca-certificates.scripts/import-datadog-certs.shthat imports the certs into every JDK's owncacertstruststore (including thejre/lib/security/cacertslayout used by JDK 8 and the amd64-onlyibm8JDK).Motivation
Instead of querying MASS like
https://mass-read.us1.ddbuild.io(often failed with503error), use more reliablehttps://mass-read.rapid-dependency-management-mass.all-clusters.local-dc.fabric.dog:8443(recommended by infra team).JDKs ship their own
cacertsand do not consult/etc/ssl/certs/java/cacerts, so trusting the certs at the OS level alone is not enough. Java processes running in the image need the Datadog CAs in each JDK truststore to establish TLS to Datadog-internal services.Additional Notes
The import script runs as
rootviasudobecause the JDKs areCOPY'd from other stages and owned by root. Existingdatadog-*aliases are deleted and re-imported to keep the operation idempotent.