Introducing Helm CEL: A More Expressive Way to Validate Your Helm Charts

If you've worked with Helm charts, you're probably familiar with the challenge of validating values.yaml. While Helm's built-in JSON Schema validation works, it can be cumbersome and limiting. Today, I want to introduce you to Helm CEL, a plugin that brings the power of Google's Common Expression Language (CEL) to Helm chart validation.

What is CEL?

Before diving in, let's quickly cover what CEL is. Common Expression Language (CEL) is a simple expression language created by Google that lets you write concise, powerful validation rules. It's used in Kubernetes CRD validation, Istio configuration, and many other projects in the cloud-native ecosystem.

Why Use CEL Instead of JSON Schema?

1. More Expressive: CEL allows you to write complex validation rules in a more natural and readable way
2. Familiar Syntax: If you're coming from programming languages like Python or JavaScript, CEL's syntax will feel natural
3. Type-Safe: CEL provides strong type checking while remaining flexible
4. Built for Cloud Native: CEL is already used throughout the Kubernetes ecosystem

Getting Started

First, install the plugin:

helm plugin install https://github.com/idsulik/helm-cel

Instead of creating a values.schema.json, you'll create a values.cel.yaml file in your chart directory. Here's a simple example:

rules:
  - expr: "has(values.service) && has(values.service.port)"
    desc: "service port is required"

  - expr: "values.service.port >= 1 && values.service.port <= 65535"
    desc: "service port must be between 1 and 65535"

  - expr: "!(has(values.replicaCount)) || values.replicaCount >= 1"
    desc: "if replicaCount is set, it must be at least 1"

To validate your chart:

helm cel ./mychart

Real-World Examples

Let's look at some common validation patterns and how they're expressed in both JSON Schema and CEL.

1. Required Fields

JSON Schema:

{
  "required": ["service"],
  "properties": {
    "service": {
      "required": ["port"],
      "properties": {
        "port": {
          "type": "integer"
        }
      }
    }
  }
}

CEL:

rules:
  - expr: "has(values.service) && has(values.service.port)"
    desc: "service port is required"

2. Conditional Requirements

JSON Schema:

{
  "if": {
    "properties": {
      "persistence": {
        "const": true
      }
    }
  },
  "then": {
    "required": ["storageClass"]
  }
}

CEL:

rules:
  - expr: "!has(values.persistence) || !values.persistence || has(values.storageClass)"
    desc: "storageClass is required when persistence is enabled"

3. Complex Validations

JSON Schema can become quite verbose for complex validations. Here's a CEL example that would be much more complicated in JSON Schema:

rules:
  - expr: |
      !has(values.resources) || 
      (!has(values.resources.limits) && !has(values.resources.requests)) ||
      (has(values.resources.limits.memory) && has(values.resources.requests.memory) &&
       int(values.resources.requests.memory) <= int(values.resources.limits.memory))
    desc: "If resources are specified, memory request must not exceed memory limit"

Error Messages That Make Sense

One of the best features of Helm CEL is its clear error messages. When validation fails, you get helpful output like this:

❌ Validation failed: replica count must be at least 1
   Rule: values.replicaCount >= 1
   Path: replicaCount
   Current value: 0

Performance Considerations

CEL expressions are compiled and evaluated efficiently. The plugin adds minimal overhead to your Helm workflow, making it suitable for both development and CI/CD pipelines.

Next Steps

1. Install the plugin: helm plugin install https://github.com/idsulik/helm-cel
2. Check out the GitHub repository for more examples
3. Start writing your own validation rules!

Conclusion

Helm CEL brings a more expressive and maintainable way to validate your Helm charts. If you've ever found yourself fighting with JSON Schema or wanting more flexible validation rules, give it a try. The combination of familiar syntax, powerful expressions, and clear error messages makes it a valuable addition to any Helm user's toolkit.

What validation patterns would you like to see? Let me know in the comments below!