Chainguard Container for knative-eventing

Event-driven application platform for Kubernetes

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/knative-eventing:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

The Chainguard Knative Eventing Images are comparable to the official Knative Eventing Images. However, the Chainguard image contains only the minimum set of tools and dependencies needed to function. This means it doesn't include things like a package manager.

Getting Started

You want to install Knative operator:

helm repo add knative-operator https://knative.github.io/operator
helm install knative-operator \
  --create-namespace \
  --namespace knative-operator \
  knative-operator/knative-operator \
  -f values.yaml

values.yaml

knative_operator:
  knative_operator:
    image: cgr.dev/ORGANIZATION/knative-operator
    tag: latest
  operator_webhook:
    image: cgr.dev/ORGANIZATION/knative-operator-webhook
    tag: latest

Once you have the operator up and running, create the KnativeEventing custom resource:

kubectl create ns knative-eventing

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  registry:
    override:
      eventing-controller/eventing-controller: cgr.dev/ORGANIZATION/knative-eventing-controller 
      eventing-webhook/eventing-webhook: cgr.dev/ORGANIZATION/knative-eventing-webhook 
      imc-controller/controller: cgr.dev/ORGANIZATION/knative-eventing-channel-controller 
      imc-dispatcher/dispatcher: cgr.dev/ORGANIZATION/knative-eventing-channel-dispatcher
      mt-broker-controller/mt-broker-controller: cgr.dev/ORGANIZATION/knative-eventing-mtchannel-broker
      mt-broker-ingress/ingress: cgr.dev/ORGANIZATION/knative-eventing-ingress
      mt-broker-filter/filter: cgr.dev/ORGANIZATION/knative-eventing-filter 
      job-sink/job-sink: cgr.dev/ORGANIZATION/knative-eventing-jobsink

Once the CR is applied, verify that all components (deployments) are up and running in the knative-eventing namespace

kubectl get pods -n knative-eventing

Next, to verify functionality, you can create a broker:

kubectl apply -n "$NAMESPACE" -f - <<EOF
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: $BROKER_NAME
EOF

and create a sink:

kubectl apply -n "$NAMESPACE" -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: $SINK_NAME
  labels:
    app: $SINK_NAME
spec:
  containers:
    - name: $SINK_NAME
      image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display
---
apiVersion: v1
kind: Service
metadata:
  name: $SINK_NAME
spec:
  selector:
    app: $SINK_NAME
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
EOF

next, create trigger:

kubectl apply -n "$NAMESPACE" -f - <<EOF
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
  name: trigger-to-sink
spec:
  broker: $BROKER_NAME
  filter:
    attributes:
      type: dev.knative.sources.ping
  subscriber:
    ref:
      apiVersion: v1
      kind: Service
      name: $SINK_NAME
EOF

Finally, a source:

kubectl apply -n "$NAMESPACE" -f - <<EOF
apiVersion: sources.knative.dev/v1
kind: PingSource
metadata:
  name: $PING_NAME
spec:
  schedule: "*/1 * * * *"
  contentType: "application/json"
  data: '{"message": "$EVENT_MESSAGE"}'
  sink:
    ref:
      apiVersion: eventing.knative.dev/v1
      kind: Broker
      name: $BROKER_NAME
EOF

Check logs in the newly created pod (from the Knative Service) to verify event delivery:

"message": "Hello from PingSource!"

This demonstrates the source to sink pattern working end-to-end.

For more eventing patterns, visit Knative Eventing Patterns

Documentation and Resources

• Knative eventing docs
• Configuring the Eventing Operator custom resource
• Sending an event

What are Chainguard Containers?

Chainguard Containers are minimal container images that are secure by default.

In many cases, the Chainguard Containers tagged as :latest contain only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager. Chainguard Containers are built with Wolfi, our Linux undistro designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a -dev variant.

Although the -dev container image variants have similar security features as their more minimal versions, they feature additional software that is typically not necessary in production environments. We recommend using multi-stage builds to leverage the -dev variants, copying application artifacts into a final minimal container that offers a reduced attack surface that won’t allow package installations or logins.

Learn More

To better understand how to work with Chainguard Containers, please visit Chainguard Academy and Chainguard Courses.

In addition to Containers, Chainguard offers VMs and Libraries. Contact Chainguard to access additional products.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.