Chainguard Container for kubernetes-reflector-fips

Kubernetes controller for reflecting ConfigMaps, Secrets, and Certificates across namespaces

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/kubernetes-reflector-fips:latest

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

Compatibility Notes

This image is compatible with the emberstack/kubernetes-reflector image. The main differences are:

• Our entrypoint is /usr/bin/kubernetes-reflector instead of dotnet ES.Kubernetes.Reflector.dll
• Our image includes a compatibility layer to ensure it works with the same environment variables and paths
• Our image runs a self-contained binary and does not have dotnet or aspnet packages installed

These changes should not affect normal operation, and the image should be a drop-in replacement for the upstream image in most configurations.

Overview

Kubernetes Reflector is a Kubernetes controller created by Emberstack that can be used to automatically replicate resources across namespaces. This tool is particularly useful for:

• Replicating ConfigMaps and Secrets to multiple namespaces
• Working with cert-manager certificates and automatically reflecting the generated TLS Secrets to other namespaces
• Sharing common configuration across multiple namespaces

Getting Started

The reflector can be deployed using the Helm chart from the Emberstack repository:

# Add the Emberstack Helm repository
helm repo add emberstack https://emberstack.github.io/helm-charts

# Update the Helm repositories
helm repo update

# Install the Helm chart with Chainguard's image
helm upgrade --install reflector emberstack/reflector \
  --namespace reflector \
  --create-namespace \
  --set image.repository=cgr.dev/ORGANIZATION/kubernetes-reflector-fips \
  --set image.tag=latest

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

Usage Examples

Configuring Resources for Reflection

To reflect a resource, add the appropriate annotations to the source resource:

Reflect a ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
  annotations:
    reflector.v1.k8s.emberstack.com/reflection-allowed: "true"
    reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "namespace-1,namespace-2"
    reflector.v1.k8s.emberstack.com/reflection-auto-enabled: "true"
data:
  key1: value1

Reflect a Secret

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  annotations:
    reflector.v1.k8s.emberstack.com/reflection-allowed: "true"
    reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "namespace-1,namespace-2"
    reflector.v1.k8s.emberstack.com/reflection-auto-enabled: "true"
type: Opaque
data:
  username: dXNlcm5hbWU=  # username
  password: cGFzc3dvcmQ=  # password

Configuration

Environment Variables

The kubernetes-reflector image supports several environment variables to configure its behavior:

• ASPNETCORE_HTTP_PORTS: The port to listen on (default: 8080)
• ES_Serilog__MinimumLevel__Default: Log level (Verbose, Debug, Information, etc.)
• ES_KubernetesClientConfiguration__VerifyConnection: Whether to verify connection to Kubernetes API (true/false)
• ES_KubernetesClientConfiguration__SkipTlsVerify: Whether to skip TLS verification (true/false)
• ES_KubernetesClientConfiguration__WatchReconnectTimeoutSeconds: Timeout for reconnecting watches
• ES_KubernetesClientConfiguration__ConnectionRetryIntervalMs: Retry interval for connections

Example helm value overrides:

env:
  - name: ES_Serilog__MinimumLevel__Default
    value: "Information"
  - name: ES_KubernetesClientConfiguration__SkipTlsVerify
    value: "false"

Documentation and Resources

For more detailed information about kubernetes-reflector, please refer to:

• GitHub Repository
• Helm Chart Repository

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.