Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add service images #34

Merged
merged 22 commits into from
Jan 31, 2025
Merged

Add service images #34

merged 22 commits into from
Jan 31, 2025

Conversation

lloeki
Copy link
Member

@lloeki lloeki commented Nov 26, 2024

Fixes: #15

@@ -0,0 +1 @@
FROM datadog/agent

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟠 Code Quality Violation

always pin version to an image spec (...read more)

This rule dictates that Docker images should always be tagged with a specific version number. In Docker, an image tag represents a particular version of an image. The use of tags allows developers to have better control over which versions of an image are being used in their projects.

This is crucial because it ensures the consistency and reliability of the Docker environment. If an image is not tagged, Docker defaults to using the 'latest' version of the image. However, the 'latest' tag does not guarantee that the same version of an image will be used every time, which can lead to unexpected behavior or compatibility issues.

To comply with this rule, always specify a version number when pulling a Docker image. Instead of FROM debian, write FROM debian:unstable or FROM debian:10.3. This ensures that you are using a specific version of the image, providing a more predictable and stable environment for your project.

View in Datadog  Leave us feedback  Documentation

@lloeki lloeki force-pushed the lloeki/add-mirror-images branch from 092bf3d to 173abea Compare November 26, 2024 14:49
Rationale is:

- mirror: provide 1:1 images, ideally automatically synced from their
  source registry; solves locality but not necessarily fitness for usage
- service: provide "ready-to-use" images, possibly modified; solves both
  locality and fitness for usage
@lloeki lloeki force-pushed the lloeki/add-mirror-images branch from 173abea to c6c0fa0 Compare January 21, 2025 10:13
@lloeki lloeki changed the title Add mirror images Add service images Jan 30, 2025
@lloeki lloeki force-pushed the lloeki/add-mirror-images branch from c58b089 to 4dfafeb Compare January 31, 2025 11:47
@lloeki lloeki force-pushed the lloeki/add-mirror-images branch from 4dfafeb to 0fc5208 Compare January 31, 2025 11:48
@lloeki lloeki force-pushed the lloeki/add-mirror-images branch from 0589b32 to ad01502 Compare January 31, 2025 11:59
}
}
- name: Set up Ruby
uses: actions/setup-ruby@v1

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟠 Code Vulnerability

Workflow depends on a GitHub actions pinned by tag (...read more)

When using a third party action, one needs to provide its GitHub path (owner/project) and can eventually pin it to a Git ref (a branch name, a Git tag, or a commit hash).

No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.

Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.

Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.

View in Datadog  Leave us feedback  Documentation

@lloeki lloeki force-pushed the lloeki/add-mirror-images branch from 167eb28 to 37b9fc3 Compare January 31, 2025 12:04
@lloeki lloeki marked this pull request as ready for review January 31, 2025 12:35
@lloeki lloeki requested a review from a team as a code owner January 31, 2025 12:35
@lloeki lloeki merged commit e96b91e into main Jan 31, 2025
60 checks passed
@lloeki lloeki deleted the lloeki/add-mirror-images branch January 31, 2025 13:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Publish images for service container
1 participant