Fixing Helm Chart Port Issue For Non-Root Users

Nov 30, 2025 by Alex Johnson 48 views

Helm Chart Installation Issue: Running Apache Answer on Non-Privileged Port as Non-Root User

Introduction

In this comprehensive guide, we will address a common issue encountered when deploying the Apache Answer application using Helm charts on Kubernetes with a non-privileged port and a non-root user. Specifically, we'll tackle the problem where the application writes an incorrect port configuration to its configuration file, leading to a crash loop. This article provides a detailed walkthrough of the problem, the steps to reproduce it, the actual and expected behaviors, and a solution to ensure Apache Answer is configured correctly and starts properly.

Understanding the Problem: Why Port Configuration Matters

When deploying applications in Kubernetes, it's a common security practice to run them as non-root users and to use non-privileged ports (ports above 1024). This approach minimizes the potential impact of security vulnerabilities. However, misconfiguration can occur when deploying applications like Apache Answer, where the application's configuration file is not correctly updated with the specified non-privileged port. This misconfiguration can lead to the application attempting to bind to the wrong port, resulting in a crash loop and preventing the application from starting correctly.

In the case of Apache Answer, the application's configuration file (config.yaml) needs to accurately reflect the port on which the application is intended to serve traffic. When the Helm chart deployment fails to update this configuration correctly, the application may attempt to use the default port (80), which requires root privileges and is inaccessible to a non-root user. This mismatch between the intended port and the configured port is the root cause of the issue we will address.

Reproducing the Bug: Step-by-Step Guide

To effectively troubleshoot and resolve this issue, it's crucial to understand how to reproduce it consistently. By following these steps, you can replicate the problem in your own environment and verify the effectiveness of the solution.

Deploy a MySQL Database: Begin by setting up a MySQL database server. This database will be used by Apache Answer to store its data. Create a new database and a dedicated database user for Apache Answer.
Create a Kubernetes Secret: Create a Kubernetes secret named answer-secrets to store sensitive information such as database credentials and admin user credentials. This secret will be used by the Helm chart to configure Apache Answer.
```
kubectl create secret generic answer-secrets \
  --from-literal=db-user=apacheanswer \
  --from-literal=db-password=... \
  --from-literal=admin-user=... \
  --from-literal=admin-password=... \
  --from-literal=admin-email=...
```

Prepare values.yaml: Create a values.yaml file to customize the Helm chart deployment. This file will contain the configuration for the non-privileged port (8080), database settings, and other necessary parameters.

# Overridden values for https://github.com/apache/answer/tree/main/charts

replicaCount: 1

# Environment variables
# Configure environment variables below
# https://answer.apache.org/docs/env
env:
  - name: INSTALL_PORT
    value: "8080"
  - name: LOG_LEVEL
    # [DEBUG INFO WARN ERROR]
    value: "INFO"
  # uncomment the below values to use AUTO_INSTALL and not have to go through the setup process.
  # Once used to do the initial setup, these variables won't be used moving forward.
  # You must at a minimum comment AUTO_INSTALL after initial setup to prevent an error about the database already being initiated.
  - name: AUTO_INSTALL
    value: "true"
  - name: DB_TYPE
    value: "mysql"
  - name: DB_HOST
    value: mysql
  - name: DB_NAME
    value: apacheanswer
  - name: DB_USERNAME
    valueFrom:
      secretKeyRef:
        name: answer-secrets
        key: db-user
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: answer-secrets
        key: db-password
  - name: LANGUAGE
    value: "en-US"
  - name: SITE_NAME
    value: "The Unhandled Exception"
  - name: SITE_URL
    value: "https://example.org"
  - name: ADMIN_NAME
    valueFrom:
      secretKeyRef:
        name: answer-secrets
        key: admin-user
  - name: ADMIN_PASSWORD
    valueFrom:
      secretKeyRef:
        name: answer-secrets
        key: admin-password
  - name: ADMIN_EMAIL
    valueFrom:
      secretKeyRef:
        name: answer-secrets
        key: admin-email

# Persistence for the /data volume
# Without persistence, your uploads and config.yaml will not be remembered between restarts.
persistence:
  enabled: true
  accessMode: ReadWriteMany
  size: 50Gi

podSecurityContext: fsGroup: 1000

securityContext:
  capabilities:
    drop:
    - ALL
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 1000
  runAsGroup: 1000

service:
  # Switch to port 8080 as we are running with as non-root
  port: 8080

ingress:
  enabled: true
  className: "haproxy"
  hosts:
    - host: example.org
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls: []

resources:
  requests:
    cpu: 1
    memory: 1Gi

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80
```

Deploy the Chart: Use the helm upgrade command to deploy the Apache Answer chart with the prepared values.yaml file.
```
helm upgrade apache-answer chart/ -f values.yaml --install
```
Access the WebUI: Open the Apache Answer WebUI via the configured ingress.

Observing the Actual Behavior: The Crash Loop

After deploying the chart using the steps above, you'll likely encounter the following behavior:

Invalid Configuration: The deployed pod generates an invalid configuration file (config.yaml) that uses port 80 instead of the configured 8080.
Pod Restarts: The pod attempts to restart due to the misconfiguration.
Crash Loop: The pod enters a crash loop, continuously restarting and failing to start properly.

By examining the generated configuration file within the pod, you can confirm that the server.http.addr and swaggerui.address parameters are incorrectly set to port 80.

apache-answer-645c989c98-qv7pm:/# cat /data/conf/config.yaml
debug: false
server:
  http:
    addr: 0.0.0.0:80
data:
  database:
    driver: mysql
    connection: user:password@tcp(mysql:3306)/apacheanswer
  cache:
    file_path: /data/cache/cache.db
i18n:
  bundle_dir: /data/i18n
service_config:
  upload_path: /data/uploads
  clean_up_uploads: true
  clean_orphan_uploads_period_hours: 48
  purge_deleted_files_period_days: 30
swaggerui:
  show: true
  protocol: http
  host: 127.0.0.1
  address: :80
ui:
  base_url: ""
  api_base_url: ""

Expected Behavior: Correct Configuration and Proper Startup

The expected behavior is that the config.yaml file should declare the correct port (8080) for both the server and Swagger UI, allowing Apache Answer to start properly.

server:
  http:
    addr: 0.0.0.0:8080
swaggerui:
  address: :8080

When configured correctly, Apache Answer should start without issues, and you should be able to access the WebUI via the configured ingress on port 8080.

Solution: How to Fix the Port Configuration Issue

To resolve the port configuration issue, you need to ensure that the Helm chart correctly sets the port in the config.yaml file. This can be achieved by modifying the Helm chart templates to properly utilize the INSTALL_PORT environment variable.

Inspect the Helm Chart Templates: Examine the Helm chart templates, specifically the configmap.yaml or any other template responsible for generating the config.yaml file. Identify the section where the port is being configured.
Modify the Templates: Update the templates to use the INSTALL_PORT environment variable when setting the port. This ensures that the port configured in the values.yaml file is correctly reflected in the generated configuration.

For example, if the original template looks like this:
```
server:
  http:
    addr: 0.0.0.0:80
swaggerui:
  address: :80
```
Modify it to use the INSTALL_PORT environment variable:
```
server:
  http:
    addr: "0.0.0.0:{{ .Values.env | getEnv "INSTALL_PORT" }}"
swaggerui:
  address: ":{{ .Values.env | getEnv "INSTALL_PORT" }}"
```
This example assumes that you have a helper function getEnv to retrieve environment variables from the .Values.env map.
Redeploy the Chart: After modifying the templates, redeploy the Helm chart using the helm upgrade command.
```
helm upgrade apache-answer chart/ -f values.yaml --install
```

Detailed Explanation: Template Modifications

The key to fixing this issue lies in correctly utilizing the INSTALL_PORT environment variable within the Helm chart templates. By default, the templates might be hardcoding the port to 80, which is why the configuration file is not reflecting the desired port 8080. To address this, we need to modify the templates to dynamically set the port based on the value provided in the values.yaml file.

The example provided above demonstrates how to use a helper function (e.g., getEnv) to retrieve the value of the INSTALL_PORT environment variable. This function would typically iterate through the env array in values.yaml and return the value associated with the INSTALL_PORT name.

By incorporating this dynamic port configuration into the templates, you ensure that the generated config.yaml file accurately reflects the desired port, resolving the crash loop issue and allowing Apache Answer to start correctly.

Additional Tips for Configuration: Best Practices

Environment Variables: Always prefer using environment variables for configuration, as they provide flexibility and allow you to easily change settings without modifying the application code.
Helm Chart Templates: Familiarize yourself with Helm chart templates and how they are used to generate Kubernetes resources. Understanding templates is crucial for customizing deployments and resolving configuration issues.
Testing: After making changes to the Helm chart, thoroughly test the deployment to ensure that the application starts correctly and functions as expected.

Conclusion

Running Apache Answer on a non-privileged port as a non-root user requires careful configuration to ensure that the application's configuration file is correctly updated. By following the steps outlined in this guide, you can effectively troubleshoot and resolve the port configuration issue, allowing you to deploy Apache Answer securely and reliably on Kubernetes.

Remember, paying close attention to environment variables and Helm chart templates is essential for successful deployments. By understanding these concepts and applying the solutions discussed in this article, you can overcome common challenges and ensure your applications run smoothly in a Kubernetes environment.

For further information on Helm charts and Kubernetes best practices, consider exploring resources like the official Kubernetes Documentation. This documentation provides comprehensive insights into various aspects of Kubernetes and can help you deepen your understanding of container orchestration.