Skip to content

Commit

Permalink
automated commit
Browse files Browse the repository at this point in the history 
Signed-off-by: Public copy <41898282+github-actions[bot]@users.noreply.github.com>
  • Loading branch information
@github-actions
github-actions[bot] committed Oct 28, 2024
1 parent 0641463 commit 6d3eb4f
Show file tree
Hide file tree
Showing 3 changed files with 174 additions and 92 deletions.
142 changes: 101 additions & 41 deletions images/cosign/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -32,49 +32,41 @@ Be sure to replace the `ORGANIZATION` placeholder with the name used for your or
<!--getting:end-->

<!--body:start-->
## Compatibility Notes
Like most other Chainguard Images, the Cosign image has few-to-zero CVEs and does not run as the root user.

## Getting Started
You can use the Cosign image to sign and verify container images via Docker or through automated workflows such as GitHub Actions.

### Verifying a container image signature
To verify an image signature, use the image to run Cosign's `verify` command. As of Cosign 2.0, Cosign defaults to using Sigstore's keyless mode, you'll need to also specify the OIDC issuer and signer identity to tell Cosign who you trust for the verification process.

## Image Variants

Our `latest` tag uses the most recent build of the [Wolfi Cosign](https://github.com/wolfi-dev/os/blob/main/cosign.yaml) package. The following tagged variant is available without authentication:

- `latest`: This is an image for running `cosign` commands. It does not include a shell or other applications.

### Cosign Version
This will automatically pull the image to your local system and execute the command `cosign version`:
For convenience, you can export those values as environment variables in your shell, and then tell Docker to pass those environment variables into the running Cosign container:

```shell
docker run --rm cgr.dev/chainguard/cosign version
export COSIGN_CERTIFICATE_OIDC_ISSUER=https://token.actions.githubusercontent.com
export COSIGN_CERTIFICATE_IDENTITY=https://github.com/chainguard-images/images/.github/workflows/release.yaml@refs/heads/main
```

You should see output similar to this:
The following example uses the Cosign image to verify the signature of the Cosign image itself:

```
______ ______ _______. __ _______ .__ __.
/ | / __ \ / || | / _____|| \ | |
| ,----'| | | | | (----`| | | | __ | \| |
| | | | | | \ \ | | | | |_ | | . ` |
| `----.| `--' | .----) | | | | |__| | | |\ |
\______| \______/ |_______/ |__| \______| |__| \__|
cosign: A tool for Container Signing, Verification and Storage in an OCI registry.
...
Platform: linux/arm64
docker run --rm \
-e COSIGN_CERTIFICATE_OIDC_ISSUER \
-e COSIGN_CERTIFICATE_IDENTITY \
cgr.dev/chainguard/cosign \
verify cgr.dev/chainguard/cosign
```



## Usage

### Signing a container image

For example, from GitHub Actions:
The following GitHub Action will log into the registry, push an image, and then sign it with Cosign:


```yaml
on:
push:
workflow_dispatch:

env:
IMAGE: ghcr.io/${{ github.repository }}
DOCKER_CONFIG: .docker-tmp
Expand All @@ -85,7 +77,7 @@ jobs:
id-token: write
packages: write
steps:
- name: Login to registry
- name: Log in to registry
run: |
set -x
mkdir -p "${DOCKER_CONFIG}"
Expand All @@ -96,8 +88,8 @@ jobs:
- name: Push image with docker
run: |
set -x
docker pull alpine:latest
docker tag alpine:latest "${IMAGE}"
docker pull cgr.dev/chainguard/wolfi-base
docker tag cgr.dev/chainguard/wolfi-base "${IMAGE}"
docker push "${IMAGE}"
- name: Sign image with cosign
run: |
Expand All @@ -112,35 +104,103 @@ jobs:
-a sha=${{ github.sha }} \
-a run_id=${{ github.run_id }} \
-a run_attempt=${{ github.run_attempt }}
```
### Attesting to an image's SBOM
Another common use case for Cosign is attesting to an image's SBOM (software bill of materials). The following command creates an attestation of type `spdxjson` for an image based on the provided SBOM file and image digest:

```shell
docker run --rm cgr.dev/chainguard/cosign attest --type spdxjson \
--predicate example-image.spdx.json \
sha256:7f95c5aa7e789ad51737e03021586949346f38ced1533ecdcb2ef2b9104137ac
```

### Verifying a container image signature
A detailed guide on how to sign an SBOM with Cosign is available on [Chainguard Academy](https://edu.chainguard.dev/open-source/sigstore/cosign/how-to-sign-an-sbom-with-cosign/).

To verify an image signature, use the image to run Cosign's `verify` command. Since as of Cosign 2.0, Cosign defaults to using Sigstore's keyless mode, you'll need to also specify the OIDC issuer and signer identity to tell Cosign who you trust for the verification process.

For convenience, you can export those values as environment variables in your shell, and then tell Docker to pass those environment variables into the running Cosign container.
### Verifying an Attestation

For example, to use the Cosign image to verify the signature of the Cosign image itself:
Cosign can also be used to verify the identity of the person or entity issuing an attestation. To verify that an attestation was issued by a specific entity, we use the `cosign verify-attestation` command, specifying the email address of the issuer:

```shell
export COSIGN_CERTIFICATE_OIDC_ISSUER=https://token.actions.githubusercontent.com
export COSIGN_CERTIFICATE_IDENTITY=https://github.com/chainguard-images/images/.github/workflows/release.yaml@refs/heads/main
cosign verify-attestation \
--certificate-oidc-issuer=https://github.com/login/oauth \
--type https://spdx.dev/Document \
[email protected] \
sha256:7f95c5aa7e789ad51737e03021586949346f38ced1533ecdcb2ef2b9104137ac
```

docker run --rm \
-e COSIGN_CERTIFICATE_OIDC_ISSUER \
-e COSIGN_CERTIFICATE_IDENTITY \
cgr.dev/chainguard/cosign \
verify cgr.dev/chainguard/cosign
If the identity is successfully verified, an initial message similar to the following is printed to stderr:

```shell
Verification for user/example-image@sha256:545a731e803b917daf44e292b03b427427f8090c4e6c4a704e4c18d56c38539f --
The following checks were performed on each of these signatures:
- The cosign claims were validated
- Existence of the claims in the transparency log was verified offline
- The code-signing certificate was verified using trusted certificate authority certificates
Certificate subject: <[email protected]>
Certificate issuer URL: https://github.com/login/oauth
```

## Detailed Environment Information
## Configuration

The following environment variables are required when verifying a container image signature:

- `COSIGN_CERTIFICATE_OIDC_ISSUER`: Trusted OIDC issuer, example: `https://token.actions.githubusercontent.com`
- `COSIGN_CERTIFICATE_IDENTITY`: Trusted certificate identity, example: `https://github.com/chainguard-images/images/.github/workflows/release.yaml@refs/heads/main`

### Detailed Environment Information

To obtain detailed information about the environment, you can run the `cosign env` command:

```shell
docker run --rm cgr.dev/chainguard/cosign env --show-descriptions=false
```

You'll get output similar to this, containing the environment variables used to configure Cosign:

```shell
ACTIONS_ID_TOKEN_REQUEST_TOKEN=
ACTIONS_ID_TOKEN_REQUEST_URL=
BUILDKITE_AGENT_ACCESS_TOKEN=
BUILDKITE_AGENT_ENDPOINT=
BUILDKITE_AGENT_LOG_LEVEL=
BUILDKITE_JOB_ID=
COSIGN_DOCKER_MEDIA_TYPES=
COSIGN_EXPERIMENTAL=
COSIGN_MAX_ATTACHMENT_SIZE=
COSIGN_PASSWORD=
COSIGN_PKCS11_IGNORE_CERTIFICATE=
COSIGN_PKCS11_MODULE_PATH=
COSIGN_PKCS11_PIN=
COSIGN_REPOSITORY=
GITHUB_HOST=
GITHUB_TOKEN=
GITLAB_HOST=
GITLAB_TOKEN=
GOOGLE_SERVICE_ACCOUNT_NAME=
SIGSTORE_CT_LOG_PUBLIC_KEY_FILE=
SIGSTORE_ID_TOKEN=
SIGSTORE_REKOR_PUBLIC_KEY=
SIGSTORE_ROOT_FILE=
SIGSTORE_TSA_CERTIFICATE_FILE=
SOURCE_DATE_EPOCH=
SPIFFE_ENDPOINT_SOCKET=
COSIGN_CERTIFICATE_OIDC_ISSUER=******
COSIGN_CERTIFICATE_IDENTITY=******
```

## Documentation and Resources

- [Chainguard Academy: An Introduction to Cosign](https://edu.chainguard.dev/open-source/sigstore/cosign/an-introduction-to-cosign/)
- [Blog Post: Chainguard announces new Sigstore Images to bring critical software supply chain tooling to enterprises](https://www.chainguard.dev/unchained/chainguard-announces-new-sigstore-images-to-bring-critical-software-supply-chain-tooling-to-enterprises)
- [Chainguard Academy: How to Sign an SBOM with Cosign](https://edu.chainguard.dev/open-source/sigstore/cosign/how-to-sign-an-sbom-with-cosign/)
- [Chainguard Academy: Verifying Chainguard Images and Metadata Signatures with Cosign](https://edu.chainguard.dev/chainguard/chainguard-images/verifying-chainguard-images-and-metadata-signatures-with-cosign/)

- [Video: Signing and Verifying Container Images With Sigstore Cosign and Kyverno ](https://www.youtube.com/watch?v=HLb1Q086u6M)

<!--body:end-->

## Contact Support
Expand Down
121 changes: 71 additions & 50 deletions images/redis/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@
<!--overview:start-->
# Chainguard Image for redis

Minimalist Wolfi-based [Redis](https://github.com/redis/redis) image.
Chainguard image for [Redis](https://github.com/redis/redis), an in-memory database that persists on disk. Redis is a key-value store, supporting an array of different values, including Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs, and Bitmaps.

Chainguard Images are regularly-updated, minimal container images with low-to-zero CVEs.
<!--overview:end-->
Expand All @@ -32,87 +32,108 @@ Be sure to replace the `ORGANIZATION` placeholder with the name used for your or
<!--getting:end-->

<!--body:start-->
## Compatibility Notes

## Important - license update
The Chainguard Redis image is comparable to [the official Redis image on Docker Hub](https://hub.docker.com/_/redis).

Redis version 7.4 and subsequent releases are no longer licensed under
BSD-3-Clause. A dual licensing model has been adopted, of which users have the
choice to adopt either RSALv2 or SSPLv1.
Unlike many other Chainguard images, the Redis image includes a shell, allowing you to interact with the Redis database using the Redis command-line interface, `redis-cli`.

Please give careful consideration to the licensing conditions when consuming
redis. For more information, refer to the [upstream license information](https://github.com/redis/redis/blob/unstable/LICENSE.txt).
By default this image runs as a non-root user named `redis` with a uid of `65532`. Typically, Redis does not have a default data directory and instead defaults to whatever the working directory is for the Redis process. The Chainguard Redis image provides a default working directory of `/data` that is writeable by the `redis` user.

## Overview
### Important license update

Redis is an in-memory database that persists on disk.
Redis version 7.4 and subsequent releases are no longer licensed under BSD-3-Clause; instead, the Redis project has adopted a dual licensing model. This means users have the choice to adopt either the Redis Source Available License v2 (RSALv2) or the Server Side Public License v1 (SSPLv1).

The data model is key-value, but many different kind of values are supported: Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs, Bitmaps.
Please give careful consideration to these licensing conditions when using Redis. For more details, refer to the [upstream license information](https://github.com/redis/redis/blob/unstable/LICENSE.txt).

- [Documentation](https://edu.chainguard.dev/chainguard/chainguard-images/reference/redis)
- [Provenance Information](https://edu.chainguard.dev/chainguard/chainguard-images/reference/redis/provenance_info/)
## Getting Started

## Image Variants
To run the Chainguard Redis image with Docker using default configuration you could run the following command:

Our `latest` tag use the most recent build of the [Wolfi Redis](https://github.com/wolfi-dev/os/blob/main/redis.yaml) package.
The `latest` tagged variant is a distroless image for running Redis.
```sh
docker run -p 6379:6379 --rm cgr.dev/chainguard/redis
```

## Redis Version
This will automatically pull the image to your local system and execute the command `redis --version`:
This command forwards port `6379` (the default port for Redis) on the host machine to port `6379` on the container:

```shell
docker run --rm cgr.dev/chainguard/redis --version
```
1:C 25 Oct 2024 17:12:32.419 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:C 25 Oct 2024 17:12:32.419 * Redis version=7.4.1, bits=64, commit=74b289a0, modified=1, pid=1, just started
1:C 25 Oct 2024 17:12:32.419 # Warning: no config file specified, using the default config. In order to specify a config file use /usr/bin/redis-server /path/to/redis.conf
1:M 25 Oct 2024 17:12:32.420 * monotonic clock: POSIX clock_gettime
1:M 25 Oct 2024 17:12:32.420 * Running mode=standalone, port=6379.
1:M 25 Oct 2024 17:12:32.421 * Server initialized
1:M 25 Oct 2024 17:12:32.421 * Ready to accept connections tcp
```

You should see output similar to this:
Following that, you can open another terminal and use `redis-cli` locally. Any commands you run through it will be forwarded to the `redis` process in the container:

```
Redis server v=7.0.8 sha=00000000:0 malloc=libc bits=64 build=736cb94cbb0b299
$ redis-cli set test 10
OK
$ redis-cli get test
"10"
$ redis-cli
127.0.0.1:6379>
```

## Using Redis

The default redis port is 6379.
To run with Docker using default configuration:
Alternatively, to test out Redis within the container, you can run the following command to access the container's shell:

```sh
docker run -p 6379:6379 --rm cgr.dev/chainguard/redis
1:C 27 Dec 2022 16:42:20.647 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:C 27 Dec 2022 16:42:20.647 # Redis version=7.0.7, bits=64, commit=00000000, modified=0, pid=1, just started
1:C 27 Dec 2022 16:42:20.647 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
1:M 27 Dec 2022 16:42:20.648 * monotonic clock: POSIX clock_gettime
1:M 27 Dec 2022 16:42:20.648 * Running mode=standalone, port=6379.
1:M 27 Dec 2022 16:42:20.648 # Server initialized
1:M 27 Dec 2022 16:42:20.650 * Ready to accept connections
docker run -it --entrypoint sh cgr.dev/chainguard/redis
```

Then run the `redis-server` command to start the `redis` process, and include the `--daemonize yes` option to prevent it from taking over the terminal:

```
/data $ redis-server --daemonize yes
```

Following that, you can run `redis-cli`, the Redis command-line interface, and begin testing the database:

```
/data $ redis-cli
127.0.0.1:6379> set test 20
OK
127.0.0.1:6379> get test
"20"
```

## Users and Directories
## Configuration

By default this image runs as a non-root user named `redis` with a uid of 65532.
Redis does not have a default data directory, it defaults to whatever the working directory is for the process.
We provide a default `WORKDIR` of `/data` that is writeable by the `redis` user.
If you supply a different configuration file or change the user, UID, or `WORKDIR` instruction, you'll need to ensure the user running the `redis` process has permissions to access the relevant `redis.conf` and `dumb.rb` files.

If you supply a different configuration file or change the user, UID, or `WORKDIR`, you'll need to ensure the user running the redis
process has permissions to write to that directory.
When running in Docker using a volume, the Chainguard Redis image will automatically use a custom configuration instead of the default one. Here's an example that mounts a host volume containing a custom Redis configuration to the `/data` directory in the container:

When running in Docker using a volume, that should also be taken care of automatically.
Here's an example of using a host volume:
```sh
docker run -d -v $(pwd):/data -p 6379:6379 cgr.dev/chainguard/redis
```

Again, this example forwards the local port `6379` to the container's port `6379`, the `redis` process's default port.

Following that, you can run `redis-cli` commands from your local machine which are then forwarded to the container:

```
% docker run -d -v $(pwd):/data -p 6379:6379 redis
d029bfb291c7a00618342ab26702dc3788cfda24b85208de04464ccb06681797
$ redis-cli set foo bar
OK
$ redis-cli save
OK
$ redis-cli get foo
"bar"
$ docker kill d029bfb291c7a00618342ab26702dc3788cfda24b85208de04464ccb06681797
d029bfb291c7a00618342ab26702dc3788cfda24b85208de04464ccb06681797
$ docker run -d -v $(pwd):/data -p 6379:6379 redis
29845f88b862d8e337cf8183e8fb6ac1bd9b43c4ec2de37111bfe08b227e1caa
$ redis-cli get foo
```

You can also open the `redis-cli` prompt locally and forward commands to the container from there:

```
$ redis-cli
127.0.0.1:6379> get foo
"bar"
```

## Documentation and Resources

* [Official Redis Documentation](https://redis.io/docs/latest/)
* (eBook) [How To Manage a Redis Database](https://www.digitalocean.com/community/books/how-to-manage-a-redis-database-ebook)
* (Tutorial) [How to Port a Sample Application to Chainguard Images](https://edu.chainguard.dev/chainguard/migration/porting-apps-to-chainguard/) — this article works through porting a small but complete application (built on NodeJS and Redis) to use Chainguard Images
* [Vulnerability Comparison: redis](https://edu.chainguard.dev/chainguard/chainguard-images/vuln-comparison/redis/)
<!--body:end-->

## Contact Support
Expand Down
3 changes: 2 additions & 1 deletion images/redis/metadata.yaml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,11 +3,12 @@ image: cgr.dev/chainguard/redis
logo: https://storage.googleapis.com/chainguard-academy/logos/redis.svg
endoflife: ""
console_summary: ""
short_description: Minimalist Wolfi-based [Redis](https://github.com/redis/redis) image.
short_description: Chainguard image for [Redis](https://github.com/redis/redis), an in-memory database that persists on disk. Redis is a key-value store, supporting an array of different values, including Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs, and Bitmaps.
compatibility_notes: ""
readme_file: README.md
upstream_url: https://github.com/redis/redis
keywords:
- application
tier: APPLICATION
aliases:
- redis:latest

0 comments on commit 6d3eb4f

Please sign in to comment.