Tag: Helm chart

  • Using Sealed Secrets with ArgoCD and Helm Charts

    When managing Kubernetes applications with ArgoCD and Helm, securing sensitive data such as passwords, API keys, and other secrets is crucial. Bitnami Sealed Secrets provides a powerful way to encrypt secrets that can be safely stored in Git and used within your ArgoCD and Helm workflows.

    This guide will cover how to integrate Sealed Secrets with ArgoCD and Helm to securely manage secrets in your values.yaml files for Helm charts.

    Overview

    ArgoCD allows you to deploy and manage applications in Kubernetes using GitOps principles, where the desired state of your applications is stored in Git repositories. Helm, on the other hand, is a package manager for Kubernetes that simplifies application deployment through reusable templates (Helm charts).

    Bitnami Sealed Secrets provides a way to encrypt your Kubernetes secrets using a public key, which can only be decrypted by the Sealed Secrets controller running in your Kubernetes cluster. This allows you to safely store and version-control encrypted secrets.

    1. Prerequisites

    Before you begin, ensure you have the following set up:

    1. Kubernetes Cluster: A running Kubernetes cluster.
    2. ArgoCD: Installed and configured in your Kubernetes cluster.
    3. Helm: Installed on your local machine.
    4. Sealed Secrets: The Sealed Secrets controller installed in your Kubernetes cluster.
    5. kubeseal: The Sealed Secrets CLI tool installed on your local machine.

    2. Setting Up Sealed Secrets

    If you haven’t already installed the Sealed Secrets controller, follow these steps:

    Install the Sealed Secrets Controller

    Using Helm:

    helm repo add bitnami https://charts.bitnami.com/bitnami
    helm install sealed-secrets-controller bitnami/sealed-secrets

    Or using kubectl:

    kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.20.2/controller.yaml

    3. Encrypting Helm Values Using Sealed Secrets

    In this section, we’ll demonstrate how to encrypt sensitive values in a Helm values.yaml file using Sealed Secrets, ensuring they are securely managed and version-controlled.

    Step 1: Identify Sensitive Data in values.yaml

    Suppose you have a Helm chart with a values.yaml file that contains sensitive information:

    # values.yaml
    database:
      username: admin
      password: my-secret-password  # Sensitive data
      host: db.example.com

    Step 2: Create a Kubernetes Secret Manifest

    First, create a Kubernetes Secret manifest for the sensitive data:

    # my-secret.yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: my-database-secret
      namespace: default
    type: Opaque
    data:
      password: bXktc2VjcmV0LXBhc3N3b3Jk  # base64 encoded 'my-secret-password'

    Step 3: Encrypt the Secret Using kubeseal

    Use the kubeseal CLI to encrypt the secret using the public key from the Sealed Secrets controller:

    kubeseal --format yaml < my-secret.yaml > my-sealedsecret.yaml

    This command generates a SealedSecret resource that is safe to store in your Git repository:

    # my-sealedsecret.yaml
    apiVersion: bitnami.com/v1alpha1
    kind: SealedSecret
    metadata:
      name: my-database-secret
      namespace: default
    spec:
      encryptedData:
        password: AgA7SyR4l5URRXg...  # Encrypted data

    Step 4: Modify the Helm Chart to Use the SealedSecret

    In your Helm chart, modify the values.yaml file to reference the Kubernetes Secret instead of directly embedding sensitive values:

    # values.yaml
    database:
      username: admin
      secretName: my-database-secret
      host: db.example.com

    In the deployment.yaml template of your Helm chart, reference the secret:

    # templates/deployment.yaml
    env:
      - name: DB_USERNAME
        value: {{ .Values.database.username }}
      - name: DB_PASSWORD
        valueFrom:
          secretKeyRef:
            name: {{ .Values.database.secretName }}
            key: password

    This approach keeps the sensitive data out of the values.yaml file, instead storing it securely in a SealedSecret.

    Step 5: Apply the SealedSecret to Your Kubernetes Cluster

    Apply the SealedSecret to your cluster:

    kubectl apply -f my-sealedsecret.yaml

    The Sealed Secrets controller will decrypt the SealedSecret and create the corresponding Kubernetes Secret.

    4. Deploying the Helm Chart with ArgoCD

    Step 1: Create an ArgoCD Application

    You can create an ArgoCD application either via the ArgoCD UI or using the argocd CLI. Here’s how to do it with the CLI:

    argocd app create my-app \
      --repo https://github.com/your-org/your-repo.git \
      --path helm/my-app \
      --dest-server https://kubernetes.default.svc \
      --dest-namespace default

    In this command:

    • --repo: The URL of the Git repository where your Helm chart is stored.
    • --path: The path to the Helm chart within the repository.
    • --dest-server: The Kubernetes API server.
    • --dest-namespace: The namespace where the application will be deployed.

    Step 2: Sync the Application

    Once the ArgoCD application is created, ArgoCD will monitor the Git repository for changes and automatically synchronize the Kubernetes cluster with the desired state.

    • Auto-Sync: If auto-sync is enabled, ArgoCD will automatically deploy the application whenever changes are detected in the Git repository.
    • Manual Sync: You can manually trigger a sync using the ArgoCD UI or CLI:
      argocd app sync my-app

    5. Example: Encrypting and Using Multiple Secrets

    In more complex scenarios, you might have multiple sensitive values to encrypt. Here’s how you can manage multiple secrets:

    Step 1: Create Multiple Kubernetes Secrets

    # db-secret.yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: db-secret
      namespace: default
    type: Opaque
    data:
      username: YWRtaW4= # base64 encoded 'admin'
      password: c2VjcmV0cGFzcw== # base64 encoded 'secretpass'
    
    # api-key-secret.yaml
    apiVersion: v1
    kind: Secret
    metadata:
      name: api-key-secret
      namespace: default
    type: Opaque
    data:
      apiKey: c2VjcmV0YXBpa2V5 # base64 encoded 'secretapikey'

    Step 2: Encrypt the Secrets Using kubeseal

    Encrypt each secret using kubeseal:

    kubeseal --format yaml < db-secret.yaml > db-sealedsecret.yaml
    kubeseal --format yaml < api-key-secret.yaml > api-key-sealedsecret.yaml

    Step 3: Apply the SealedSecrets

    Apply the SealedSecrets to your Kubernetes cluster:

    kubectl apply -f db-sealedsecret.yaml
    kubectl apply -f api-key-sealedsecret.yaml

    Step 4: Reference Secrets in Helm Values

    Modify your Helm values.yaml file to reference these secrets:

    # values.yaml
    database:
      secretName: db-secret
    api:
      secretName: api-key-secret

    In your Helm chart templates, use the secrets:

    # templates/deployment.yaml
    env:
      - name: DB_USERNAME
        valueFrom:
          secretKeyRef:
            name: {{ .Values.database.secretName }}
            key: username
      - name: DB_PASSWORD
        valueFrom:
          secretKeyRef:
            name: {{ .Values.database.secretName }}
            key: password
      - name: API_KEY
        valueFrom:
          secretKeyRef:
            name: {{ .Values.api.secretName }}
            key: apiKey

    6. Best Practices

    • Environment-Specific Secrets: Use different SealedSecrets for different environments (e.g., staging, production). Encrypt and store these separately.
    • Backup and Rotation: Regularly back up the SealedSecrets and rotate the keys used by the Sealed Secrets controller.
    • Audit and Monitor: Enable logging and monitoring in your Kubernetes cluster to track the use of SealedSecrets.

    When creating a Kubernetes Secret, the data must be base64 encoded before you can encrypt it with Sealed Secrets. This is because Kubernetes Secrets expect the values to be base64 encoded, and Sealed Secrets operates on the same principle since it wraps around Kubernetes Secrets.

    Why Base64 Encoding?

    Kubernetes Secrets require data to be stored as base64-encoded strings. This encoding is necessary because it allows binary data (like certificates, keys, or complex strings) to be stored as plain text in YAML files.

    Steps for Using Sealed Secrets with Base64 Encoding

    Here’s how you typically work with base64 encoding in the context of Sealed Secrets:

    1. Base64 Encode Your Secret Data

    Before creating a Kubernetes Secret, you need to base64 encode your sensitive data. For example, if your secret is a password like my-password, you would encode it:

    echo -n 'my-password' | base64

    This command outputs the base64-encoded version of my-password:

    bXktcGFzc3dvcmQ=

    2. Create the Kubernetes Secret Manifest

    Create a Kubernetes Secret YAML file with the base64-encoded value:

    apiVersion: v1
    kind: Secret
    metadata:
      name: my-secret
      namespace: default
    type: Opaque
    data:
      password: bXktcGFzc3dvcmQ=  # base64 encoded 'my-password'

    3. Encrypt the Secret Using kubeseal

    Once the Kubernetes Secret manifest is ready, encrypt it using the kubeseal command:

    kubeseal --format yaml < my-secret.yaml > my-sealedsecret.yaml

    This command creates a SealedSecret, which can safely be committed to version control.

    4. Apply the SealedSecret

    Finally, apply the SealedSecret to your Kubernetes cluster:

    kubectl apply -f my-sealedsecret.yaml

    The Sealed Secrets controller in your cluster will decrypt the SealedSecret and create the corresponding Kubernetes Secret with the base64-encoded data.

    Summary

    • Base64 Encoding: You must base64 encode your secret data before creating a Kubernetes Secret manifest because Kubernetes expects the data to be in this format.
    • Encrypting with Sealed Secrets: After creating the Kubernetes Secret manifest with base64-encoded data, use Sealed Secrets to encrypt the entire manifest.
    • Applying SealedSecrets: The Sealed Secrets controller will decrypt the SealedSecret and create the Kubernetes Secret with the correctly encoded data.

    Conclusion

    By combining ArgoCD, Helm, and Sealed Secrets, you can securely manage and deploy Kubernetes applications in a GitOps workflow. Sealed Secrets ensure that sensitive data remains encrypted and safe, even when stored in a version control system, while Helm provides the flexibility to manage complex applications. Following the steps outlined in this guide, you can confidently manage secrets in your Kubernetes deployments, ensuring both security and efficiency.

  • Using ArgoCD, Helm, and SOPS for Secure Kubernetes Deployments

    As Kubernetes becomes the standard for container orchestration, managing and securing your Kubernetes deployments is critical. ArgoCD, Helm, and SOPS (Secret Operations) can be combined to provide a powerful, secure, and automated solution for managing Kubernetes applications.

    This guide provides a detailed overview of how to integrate ArgoCD, Helm, and SOPS to achieve secure GitOps workflows in Kubernetes.

    1. Overview of the Tools

    ArgoCD

    ArgoCD is a declarative GitOps continuous delivery tool for Kubernetes. It allows you to automatically synchronize your Kubernetes cluster with the desired state defined in a Git repository. ArgoCD monitors this repository for changes and ensures that the live state in the cluster matches the desired state specified in the repository.

    Helm

    Helm is a package manager for Kubernetes, similar to apt or yum for Linux. It simplifies the deployment and management of applications by using “charts” that define an application’s Kubernetes resources. Helm charts can include templates for Kubernetes manifests, allowing you to reuse and customize deployments across different environments.

    SOPS (Secret Operations)

    SOPS is an open-source tool created by Mozilla that helps securely manage secrets by encrypting them before storing them in a Git repository. It integrates with cloud KMS (Key Management Services) like AWS KMS, GCP KMS, and Azure Key Vault, as well as PGP and age, to encrypt secrets at rest.

    2. Integrating ArgoCD, Helm, and SOPS

    When combined, ArgoCD, Helm, and SOPS allow you to automate and secure Kubernetes deployments as follows:

    1. ArgoCD monitors your Git repository and applies changes to your Kubernetes cluster.
    2. Helm packages and templatizes your Kubernetes manifests, making it easy to deploy complex applications.
    3. SOPS encrypts sensitive data, such as secrets and configuration files, ensuring that these are securely stored in your Git repository.

    3. Setting Up Helm with ArgoCD

    Step 1: Store Your Helm Charts in Git

    • Create a Helm Chart: If you haven’t already, create a Helm chart for your application using the helm create <chart-name> command. This command generates a basic chart structure with Kubernetes manifests and a values.yaml file.
    • Push to Git: Store the Helm chart in a Git repository that ArgoCD will monitor. Organize your repository to include directories for different environments (e.g., dev, staging, prod) with corresponding values.yaml files for each.

    Step 2: Configure ArgoCD to Use Helm

    • Create an ArgoCD Application: You can do this via the ArgoCD UI or CLI. Specify the Git repository URL, the path to the Helm chart, and the target Kubernetes cluster and namespace.
      argocd app create my-app \
        --repo https://github.com/your-org/your-repo.git \
        --path helm/my-app \
        --dest-server https://kubernetes.default.svc \
        --dest-namespace my-namespace \
        --helm-set key1=value1 \
        --helm-set key2=value2
    • Sync Policy: Choose whether to sync automatically or manually. Auto-sync will automatically apply changes from the Git repository to the Kubernetes cluster whenever there’s a commit.

    Step 3: Manage Helm Values with SOPS

    One of the challenges in managing Kubernetes deployments is handling sensitive data such as API keys, passwords, and other secrets. SOPS helps by encrypting this data, allowing you to safely store it in your Git repository.

    4. Encrypting Helm Values with SOPS

    Step 1: Install SOPS

    Install SOPS on your local machine:

    • macOS: brew install sops
    • Linux: sudo apt-get install sops
    • Windows: Download the binary from the SOPS releases page.

    Step 2: Encrypt the values.yaml File

    • Generate a Key: You can use a cloud KMS, PGP, or age key to encrypt your secrets. For example, if you’re using AWS KMS, create a KMS key in AWS and note the key ID.
    • Encrypt with SOPS: Use SOPS to encrypt the values.yaml file containing your sensitive data.
      sops -e --kms "arn:aws:kms:your-region:your-account-id:key/your-kms-key-id" values.yaml > values.enc.yaml

    This command encrypts values.yaml and saves the encrypted version as values.enc.yaml.

    Step 3: Store the Encrypted Values in Git

    • Commit the Encrypted File: Commit and push the values.enc.yaml file to your Git repository.
      git add values.enc.yaml
      git commit -m "Add encrypted Helm values"
      git push origin main

    5. Deploying with ArgoCD and SOPS

    To deploy the application using ArgoCD and the encrypted values file:

    Step 1: Configure ArgoCD to Decrypt Values

    ArgoCD needs to decrypt the values.enc.yaml file before it can apply the Helm chart. You can use a custom ArgoCD plugin or a Kubernetes init container to handle the decryption.

    • Custom ArgoCD Plugin: Define a custom ArgoCD plugin in the argocd-cm ConfigMap that uses SOPS to decrypt the file before applying the Helm chart.
      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: argocd-cm
        namespace: argocd
      data:
        configManagementPlugins: |
          - name: helm-with-sops
            generate:
              command: ["sh", "-c"]
              args: ["sops -d values.enc.yaml > values.yaml && helm template ."]

    This plugin decrypts the values.enc.yaml file and passes the decrypted values to Helm for rendering.

    Step 2: Sync the Application

    After configuring the plugin, you can sync the application in ArgoCD:

    • Automatic Sync: If auto-sync is enabled, ArgoCD will automatically decrypt the values and deploy the application whenever changes are detected in the Git repository.
    • Manual Sync: Trigger a manual sync in the ArgoCD UI or CLI:
      argocd app sync my-app

    6. Advanced Use Cases

    Multi-Environment Configurations

    • Environment-Specific Values: Store environment-specific values in separate encrypted files (e.g., values.dev.enc.yaml, values.prod.enc.yaml). Configure ArgoCD to select the appropriate file based on the target environment.

    Handling Complex Helm Deployments

    • Helm Hooks: Use Helm hooks to define lifecycle events, such as pre-install or post-install tasks, that need to run during specific phases of the deployment process. Hooks can be useful for running custom scripts or initializing resources.
    • Dependencies: Manage complex applications with multiple dependencies by defining these dependencies in the Chart.yaml file. ArgoCD will handle these dependencies during deployment.

    7. Monitoring and Auditing

    ArgoCD UI

    • Monitoring Deployments: Use the ArgoCD web UI to monitor the status of your deployments. The UI provides detailed information about sync status, health checks, and any issues that arise.
    • Rollback: If a deployment fails, you can easily roll back to a previous state using the ArgoCD UI or CLI. This ensures that you can recover quickly from errors.

    Audit Logging

    • Security Audits: Enable audit logging in ArgoCD to track who made changes, what changes were made, and when they were applied. This is crucial for maintaining security and compliance.

    Conclusion

    Combining ArgoCD, Helm, and SOPS provides a robust and secure way to manage Kubernetes deployments. ArgoCD automates the deployment process, Helm simplifies the management of complex applications, and SOPS ensures that sensitive data remains secure throughout the process. By following the steps outlined in this guide, you can set up a secure, automated, and auditable GitOps workflow that leverages the strengths of each tool. This integration not only improves the reliability and security of your deployments but also enhances the overall efficiency of your DevOps practices.

  • ArgoCD: GitOps Continuous Delivery


    In the world of Kubernetes and cloud-native technologies, continuous delivery and automation are key to maintaining agility and efficiency. ArgoCD has emerged as a powerful tool that embodies the principles of GitOps, providing a declarative, Git-based continuous delivery solution for Kubernetes. This article delves into what ArgoCD is, how it works, and why it’s become a cornerstone in the modern DevOps toolkit.

    What is ArgoCD?

    ArgoCD is an open-source, declarative GitOps continuous delivery tool specifically designed for Kubernetes. It allows developers and DevOps teams to manage application deployments and lifecycle management in a Kubernetes cluster, ensuring that the desired state of applications, as defined in a Git repository, is consistently synchronized with the actual state in the cluster.

    ArgoCD automates the process of synchronizing application definitions stored in Git with their corresponding deployments in Kubernetes, providing visibility, control, and compliance across the deployment pipeline.

    Key Features of ArgoCD

    ArgoCD offers a rich set of features that make it a powerful tool for continuous delivery in Kubernetes environments:

    1. Declarative GitOps:
    • ArgoCD follows the GitOps paradigm, where the desired state of the application is defined declaratively in a Git repository. This ensures that the actual state in the Kubernetes cluster always reflects the versioned configuration in Git.
    1. Multi-Cluster Management:
    • ArgoCD supports managing deployments across multiple Kubernetes clusters from a single ArgoCD instance. This is particularly useful for organizations operating in multi-cloud or hybrid-cloud environments.
    1. Application Rollbacks:
    • With ArgoCD, rolling back to a previous state is straightforward. Since all configurations are stored in Git, users can easily revert to a previous commit if something goes wrong during deployment.
    1. Sync and Drift Detection:
    • ArgoCD continuously monitors the live state of applications and compares it with the desired state stored in Git. If a drift is detected, ArgoCD can automatically synchronize the live state to match the desired state, ensuring consistency.
    1. Granular RBAC (Role-Based Access Control):
    • ArgoCD provides fine-grained access control, allowing administrators to define who can access and modify applications, and under what circumstances. This helps maintain security and compliance within the deployment process.
    1. Web UI and CLI:
    • ArgoCD comes with a user-friendly web interface that provides real-time monitoring of applications, deployment history, and easy access to logs and debugging tools. It also offers a powerful command-line interface (CLI) for those who prefer working from the terminal.
    1. Integration with CI/CD Pipelines:
    • While ArgoCD is primarily a CD tool, it integrates seamlessly with existing CI/CD pipelines, allowing teams to build, test, and deploy applications in an automated and consistent manner.
    1. Helm and Kustomize Support:
    • ArgoCD supports popular Kubernetes configuration management tools like Helm and Kustomize, enabling users to manage and deploy complex applications with ease.

    How ArgoCD Works

    ArgoCD works by continuously monitoring a Git repository that contains Kubernetes manifests, Helm charts, or Kustomize configurations. It watches for changes in the repository and automatically applies them to the corresponding Kubernetes cluster(s), ensuring that the actual state of the application matches the desired state defined in Git.

    Workflow Overview:

    1. Define Applications in Git:
    • Application configurations are defined in a Git repository using Kubernetes manifests, Helm charts, or Kustomize overlays. These files describe the desired state of the application, including its deployment, services, configuration, and other Kubernetes resources.
    1. ArgoCD Monitors Git Repository:
    • ArgoCD continuously monitors the Git repository for any changes to the application configuration. It detects changes as soon as they are committed to the repository.
    1. Syncing the Desired State:
    • When ArgoCD detects a change, it automatically syncs the live state of the application in the Kubernetes cluster with the desired state defined in Git. This includes creating, updating, or deleting Kubernetes resources as needed.
    1. Handling Drift:
    • If the actual state of the application drifts from the desired state (e.g., due to manual changes in the cluster), ArgoCD can automatically or manually bring the live state back in line with the Git-defined state.
    1. Monitoring and Rollbacks:
    • ArgoCD provides real-time monitoring of application deployments, allowing users to see the status of their applications at a glance. If an issue is detected, users can easily roll back to a previous state using the Git history.

    Why Use ArgoCD?

    ArgoCD brings several benefits to teams managing Kubernetes-based applications:

    1. Improved Consistency and Reliability:
    • By using Git as the single source of truth, ArgoCD ensures that all deployments are consistent with what has been tested and approved. This reduces the risk of configuration drift and deployment errors.
    1. Faster and Safer Deployments:
    • With ArgoCD, deployments are automated and can be rolled back quickly if something goes wrong. This reduces downtime and makes it easier to deploy changes with confidence.
    1. Enhanced Security and Compliance:
    • ArgoCD’s integration with Git provides a clear audit trail for all changes, making it easier to comply with security policies and regulatory requirements.
    1. Ease of Use and Flexibility:
    • The intuitive web UI and CLI make it easy for teams to manage applications, whether they prefer graphical interfaces or command-line tools. Support for Helm and Kustomize also adds flexibility in managing complex applications.
    1. Scalability:
    • ArgoCD’s ability to manage multiple clusters and environments from a single instance makes it a scalable solution for organizations of all sizes, from small startups to large enterprises.

    Getting Started with ArgoCD

    To get started with ArgoCD, follow these steps:

    1. Install ArgoCD:
    • ArgoCD can be installed on any Kubernetes cluster using Helm or kubectl. The official documentation provides detailed instructions for installation.
    1. Connect Your Git Repository:
    • After installing ArgoCD, connect it to your Git repository containing the application manifests. You can do this via the ArgoCD web UI or CLI.
    1. Define and Deploy Applications:
    • Define your applications in the Git repository and let ArgoCD handle the deployment. You can monitor the deployment process in real-time through the ArgoCD dashboard.
    1. Manage and Monitor Applications:
    • Use the ArgoCD web UI or CLI to manage, monitor, and roll back applications as needed. You can also set up alerts and notifications to stay informed of any issues.

    Conclusion

    ArgoCD is a powerful tool that brings the benefits of GitOps to Kubernetes environments, enabling teams to automate and manage application deployments with ease. Its integration with Git, support for multiple clusters, and intuitive user interface make it an ideal choice for organizations looking to enhance their continuous delivery pipelines.

    By adopting ArgoCD, teams can achieve greater consistency, reliability, and security in their deployment processes, ultimately delivering software faster and with greater confidence. Whether you’re managing a single Kubernetes cluster or a complex multi-cloud environment, ArgoCD provides the tools and capabilities needed to succeed in today’s fast-paced, cloud-native world.