skip to content

Which `helm repo add` flags reach a private chart repository behind basic auth and an internal CA, and where do the credentials land?

level: seniorimportance: should knowfreq 50%

answer

  1. Two problems: who you are, whom you trust
  2. One flag for the server CA, two for client certs
  3. Ask where the password is written afterwards
  4. Cleartext in repositories.yaml, per user per machine
  5. --repo on install avoids persisting anything

basics

~20 s

Use --username and --password for basic auth, --ca-file to trust an internal CA, and --cert-file/--key-file for client certificates. Helm writes those credentials in plaintext into repositories.yaml, so on shared or CI machines pass them per-command with --repo instead of persisting them.

solid answer

~50 s

`helm repo add monitoring https://charts.example.internal/monitoring --username "$U" --password "$P" --ca-file /etc/ssl/internal/corp-root-ca.pem` covers the usual private setup: basic auth plus a server certificate signed by a CA the system trust store does not know. For mutual TLS add `--cert-file` and `--key-file`; `--insecure-skip-tls-verify` exists but disables verification entirely and should not survive review. The important operational fact is persistence: the username and password are written **in cleartext** into `repositories.yaml` under `HELM_REPOSITORY_CONFIG`, alongside the paths to the certificate files. That file is per-user machine state, so it must never be committed, baked into an image, or left on a shared box. On CI, either treat the runner's Helm home as ephemeral and inject the secret from the CI secret store each run, or skip persistence completely: `helm install`, `helm upgrade` and `helm pull` all accept `--repo` with the same auth flags, so nothing is written to disk.

code

bash · 5 lines
bash
helm repo add monitoring https://charts.example.internal/monitoring \
  --username "$CHART_REPO_USER" \
  --password "$CHART_REPO_TOKEN" \
  --ca-file /etc/ssl/internal/corp-root-ca.pem
helm repo update monitoring

go deeper

for a junior

Know the four flags by name - username, password, ca-file, and the cert/key pair for mutual TLS - and that adding a private repository is a client-side action on your own machine.

for a middle

Explain what each flag verifies or proves, and be precise that the credentials are persisted in cleartext in the repository config rather than held only for the session.

for a senior

Diagnose the real failures: an unknown CA versus a rejected credential versus a cross-host package fetch that silently drops auth, and reach for the correct flag instead of disabling verification.

for a principal

Own credential design across the estate - read-only service identities for consumption, secrets injected per run instead of persisted, an answer for rotation across every machine that ever added the repository, and the separation between repository access and chart authenticity.

### The flags, and what each actually does A private chart repository is an ordinary HTTPS server with two extra requirements: it wants to know who you are, and its certificate may be issued by a CA the machine does not already trust. `helm repo add` carries flags for both. - **`--username` / `--password`** supply HTTP basic auth. These are sent on the index request and, by default, on the chart download requests to the same host. - **`--ca-file`** points at a PEM bundle used to verify the *server's* certificate. This is the flag for an internally issued certificate; it adds trust for this repository without touching the system trust store. - **`--cert-file` / `--key-file`** supply a *client* certificate and key, i.e. mutual TLS, where the server authenticates you by certificate rather than (or in addition to) a password. - **`--insecure-skip-tls-verify`** turns certificate verification off. It makes a broken setup "work" and makes an interception undetectable. Treat its appearance in a runbook as a defect to fix with `--ca-file`. - **`--pass-credentials`** is the subtle one. By default Helm sends your credentials only to the repository's own host; if the `index.yaml` lists chart download URLs on a *different* domain - a CDN, an object store, a separate download host - Helm deliberately drops the credentials rather than leaking them to a third party. When the repository genuinely requires the same credentials at that other host, this flag restores the old permissive behaviour. Enable it knowingly, never by reflex, and only for a host you control. ### Where the credentials end up This is the part interviews are really testing. `helm repo add` does not stash the password in a keyring, encrypt it, or hold it in memory for the session. It writes it, **in cleartext**, into the `repositories.yaml` under `HELM_REPOSITORY_CONFIG` - the same file that holds the name and URL - together with the file paths you gave for the CA and client certificate. `helm env` will tell you exactly where that file is on any host. So three practical rules follow: 1. **Never commit or bake it.** A `repositories.yaml` copied into a container image, a dotfiles repo, or a shared build image is a leaked credential with a long tail. The same applies to a home directory snapshot restored across jobs. 2. **Watch the command line.** The password also passes through your shell history and, on a multi-user host, through the process table while the command runs. Read it from an environment variable populated by your secret store rather than typing the literal. 3. **Prefer not persisting at all in automation.** `helm install`, `helm upgrade`, `helm pull`, `helm template` and `helm show` all accept `--repo <url>` together with the same `--username`, `--password`, `--ca-file`, `--cert-file` and `--key-file` flags. Using those, a pipeline fetches the chart it needs with a credential that exists only for the duration of the process, and nothing lands in a config file at all. The cost is that you lose the alias and the cached index, so every command carries the full URL and re-fetches - a trade that is usually right in CI and usually wrong on a laptop. ### A worked failure A delivery pipeline for a PDF-signing service installs a monitoring-stack chart, version 4.11.2, from an internal repository. It works on the maintainer's laptop and fails on the runner with a certificate error. Three candidates, distinguished by reading the error rather than guessing: - *Unknown authority* means the runner image lacks the internal CA - fix with `--ca-file` pointing at a bundle mounted into the runner, not with `--insecure-skip-tls-verify`. - *401/403 on the index* means the credential never arrived: an empty environment variable, or a `helm repo add` step that was skipped because a cached home directory already had the repo entry (with a rotated password in it). - *The index downloads fine but the `.tgz` returns 401* is the giveaway for the cross-host case: the index is served by the repository host while the packages live on a different domain, and Helm dropped the credentials on the second request by design. That one is diagnosed by looking at the `urls` entries in the cached index, and resolved with `--pass-credentials` if the two hosts really are the same trust domain. ### Rotation and blast radius Because the credential is persisted per user per machine, rotating it is not one action - it is one action per place someone ran `helm repo add`. That argues for a service account credential injected into automation and short-lived or SSO-backed access for humans, rather than one shared read token pasted into every engineer's config. It also argues for read-only credentials on consumption paths: a machine that installs charts has no business holding a token that can publish them. And note the scope of what you are protecting: this is repository *access*, not chart *authenticity* - proving a chart is the one its author packaged is a separate mechanism entirely.

  • The index downloads successfully but the chart tarball returns 401 from the same repository. What is happening?
    The index lists chart download URLs on a different host from the repository itself - a CDN or object store. Helm deliberately withholds the credentials on a cross-host request so they are not leaked to a third party, so the package fetch arrives unauthenticated. Confirm by reading the `urls` entries in the cached index. If both hosts are genuinely yours, `--pass-credentials` restores the permissive behaviour; otherwise the repository should be serving packages from its own host.
  • How would you keep repository credentials out of CI runners' persisted state entirely?
    Skip `helm repo add` and use `--repo <url>` on `helm pull`, `helm template`, `helm install` or `helm upgrade` with the auth flags supplied from the CI secret store. Nothing is written to `repositories.yaml`, so a cached or leaked runner home holds no credential. Treat the runner's Helm home as ephemeral either way, and use a read-only service credential so a compromised consumer cannot publish.
  • A teammate fixes a TLS failure by adding `--insecure-skip-tls-verify`. What do you say in review?
    That it does not fix anything - it removes the check that detected the problem, so an intercepted or substituted repository becomes indistinguishable from the real one. The actual causes are a server certificate signed by an internal CA the machine does not trust, an incomplete chain, or an expired certificate. Mount the CA bundle and pass `--ca-file`, and fix the chain on the server if that is what the error is really reporting.

saying these in an interview costs you the question

  • Says Helm stores repository passwords encrypted
  • Fixes TLS errors with --insecure-skip-tls-verify
  • Commits repositories.yaml or bakes it into an image
  • Thinks repository auth proves the chart is authentic
  • Cannot explain why credentials are dropped across hosts
  • Uses one shared publish-capable token for all consumers

context

resolving links…