DirectorySecurity Advisories
Sign In
Directory
azuredisk-csi-fips logoFIPS

azuredisk-csi-fips

Last changed

Create your Free Account

Be the first to hear about exciting product updates, critical vulnerability alerts, compare alternative images, and more.

Sign Up
Versions
Overview
Provenance
Specifications
SBOM
Vulnerabilities
Advisories

Chainguard Image for azuredisk-csi-fips

The Azure Disk CSI driver enables the provisioning and management of Azure Disks through Kubernetes.This driver provides an interface for attaching, detaching, and managing persistent disks on Azure, helping applications achieve durable and high-performing storage.

Chainguard Images are regularly-updated, minimal container images with low-to-zero CVEs.

Download this Image

This image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/azuredisk-csi-fips:latest

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

Example Usage with Chainguard Image

This guide outlines steps to test volume provisioning with the Azure Disk CSI driver. The Azure Disk CSI driver enables the provisioning and management of Azure Disks through Kubernetes.

Prerequisites

To test the Azure Disk CSI driver, you need:

  • Azure CLI
  • Access to an Azure account
  • An AKS cluster
  • Proper IAM roles and policies configured for Azure Disk CSI driver, with permissions to create and attach disks to the AKS nodes.

Install the Azure Disk CSI Driver

The Azure Disk CSI driver can be installed via Helm. Ensure you have the Helm repo added:

helm repo add azuredisk-csi-driver https://raw.githubusercontent.com/kubernetes-sigs/azuredisk-csi-driver/master/charts
helm repo update

Then, install the driver with the following command, ensuring appropriate values are set in the configuration file:

helm install azuredisk-csi-driver azuredisk-csi-driver/azuredisk-csi-driver \
--namespace kube-system \
--set image.azuredisk.repository=cgr.dev/chainguard/azuredisk-csi-fips \
--set image.azuredisk.tag=latest \
--set image.azuredisk.pullPolicy=IfNotPresent \
--set serviceAccount.node=new-csi-azuredisk-node-sa \
--set serviceAccount.create=true \
--set rbac.name=new-csi-azuredisk \
--set controller.hostNetwork=false \
--set controller.replicas=1 \
--set linux.hostNetwork=false \
--set linux.dsName=new-csi-azuredisk-node \
--set windows.dsName=new-csi-azuredisk-node-win

If you face any issues with the above helm install, you might have to annotate the below

Annotate and label the CSI driver for Helm management:

kubectl annotate csidriver disk.csi.azure.com \
  meta.helm.sh/release-name=azuredisk-csi-driver \
  meta.helm.sh/release-namespace=kube-system

kubectl label csidriver disk.csi.azure.com \
  app.kubernetes.io/managed-by=Helm

Check that the CSI driver controller and node pods are running:

kubectl get pods -n kube-system -l "app.kubernetes.io/name=azuredisk-csi-driver"

Step 1: Create a StorageClass for Azure Disk

Create a StorageClass to provision disks using the Azure Disk CSI driver. This StorageClass should specify disk.csi.azure.com as the provisioner.

kubectl apply -f -<<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azure-disk
provisioner: disk.csi.azure.com
volumeBindingMode: WaitForFirstConsumer
EOF

Step 2: Create a PersistentVolumeClaim (PVC)

Request a PersistentVolumeClaim using the Azure Disk StorageClass created in Step 1.

kubectl apply -f -<<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-disk-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: azure-disk
  resources:
    requests:
      storage: 5Gi
EOF

Verify the PVC has been created and is bound to a PersistentVolume (PV):

kubectl get pvc azure-disk-pvc

Example output:

NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
azure-disk-pvc   Bound    pvc-1234abcd-56ef-78gh-ijkl-mnopqrstuvwx   5Gi        RWO            azure-disk     10s

Step 3: Create a Pod to Use the PVC

Create a Pod that uses the PVC to test the volume's functionality. This Pod will write a test file to the mounted volume.

kubectl apply -f -<<EOF
apiVersion: v1
kind: Pod
metadata:
  name: azure-disk-test-pod
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["/bin/sh", "-c", "echo 'Hello from Azure Disk!' > /mnt/azure/hello.txt && sleep 3600"]
    volumeMounts:
    - mountPath: "/mnt/azure"
      name: azure
  volumes:
  - name: azure
    persistentVolumeClaim:
      claimName: azure-disk-pvc
EOF

Verify that the Pod is created and enters the Running state:

kubectl get pod azure-disk-test-pod

Step 4: Verify Data Written to the Disk

Check that the data written by the Pod to the Azure Disk is successfully stored.

kubectl exec azure-disk-test-pod -- cat /mnt/azure/hello.txt

Expected output:

Hello from Azure Disk!

Step 5: Check Logs of the Azure Disk CSI Driver

Check the logs of the Azure Disk CSI driver's controller and node pods to ensure that there are no errors during the volume provision and attachment process.

Controller Logs

kubectl logs -n kube-system -l "app.kubernetes.io/name=azuredisk-csi-driver" -c csi-provisioner

Node Logs

kubectl logs -n kube-system -l "app.kubernetes.io/name=azuredisk-csi-driver" -c azuredisk

Step 6: Clean Up

Once testing is complete, clean up the resources created:

kubectl delete pod azure-disk-test-pod
kubectl delete pvc azure-disk-pvc
kubectl delete storageclass azure-disk

If you installed the Azure Disk CSI driver with Helm and want to remove it:

helm uninstall azuredisk-csi-driver -n kube-system

Contact Support

If you have a Zendesk account (typically set up for you by your Customer Success Manager) you can reach out to Chainguard's Customer Success team through our Zendesk portal.

What are Chainguard Images?

Chainguard Images are a collection of container images designed for security and minimalism.

Many Chainguard Images are distroless; they contain only an open-source application and its runtime dependencies. These images do not even contain a shell or package manager. Chainguard Images are built with Wolfi, our Linux undistro designed to produce container images that meet the requirements of a secure software supply chain.

The main features of Chainguard Images include:

-dev Variants

As mentioned previously, Chainguard’s distroless Images have no shell or package manager by default. This is great for security, but sometimes you need these things, especially in builder images. For those cases, most (but not all) Chainguard Images come paired with a -dev variant which does include a shell and package manager.

Although the -dev image variants have similar security features as their distroless versions, such as complete SBOMs and signatures, they feature additional software that is typically not necessary in production environments. The general recommendation is to use the -dev variants only to build the application and then copy all application artifacts into a distroless image, which will result in a final container image that has a minimal attack surface and won’t allow package installations or logins.

That being said, it’s worth noting that -dev variants of Chainguard Images are completely fine to run in production environments. After all, the -dev variants are still more secure than many popular container images based on fully-featured operating systems such as Debian and Ubuntu since they carry less software, follow a more frequent patch cadence, and offer attestations for what they include.

Learn More

To better understand how to work with Chainguard Images, we encourage you to visit Chainguard Academy, our documentation and education platform.

Licenses

Chainguard Images contain software packages that are direct or transitive dependencies. The following licenses were found in the "latest" version of this image:

  • Apache-2.0

  • BSD-1-Clause

  • BSD-2-Clause

  • BSD-3-Clause

  • BSD-4-Clause-UC

  • CC-PDDC

  • GCC-exception-3.1

For a complete list of licenses, please refer to this Image's SBOM.

Software license agreement

Compliance

This is a FIPS validated image for FedRAMP compliance.

This image is STIG hardened and scanned against the DISA General Purpose Operating System SRG with reports available.

Learn more about STIGsGet started with STIGs

Related images

Category
FIPS
STIG
application

Safe Source for Open Sourceâ„¢
Media KitContact Us
© 2024 Chainguard. All Rights Reserved.
Private PolicyTerms of Use

Product

Chainguard Images