Avoid the flag that skips TLS certificate checks, and use the flag that passes credentials to all domains only when you control every domain involved. Helm documents both on helm repo add. Skipping verification lets anyone on the network path substitute a chart, and wide credential passing can send a token to hosts you did not intend.
What the command does
The helm repo add command registers a chart repository under a name and URL. The command's documented options include a CA bundle to verify HTTPS servers, a client certificate and key to identify you, a username and a password, a read of the password from standard input, and a timeout for downloading the index, which defaults to two minutes.
Two options stand out for trust: one to skip TLS certificate checks for the repository, and one to pass credentials to all domains.
Skipping TLS verification
The flag name says it directly: skip TLS certificate checks for the repository. With it, Helm will accept a certificate that is expired, self-signed or issued for another name.
Why it is risky: a chart repository delivers code that will run in your cluster. If the connection is not verified, a person who can intercept traffic could swap the index or a chart archive. Helm can verify provenance on charts if you use it, but most teams do not, so TLS is often the only check on where a chart came from.
Why people use it: internal repositories with a private certificate authority, where installing the CA seemed like extra work.
The better route is the CA file option from the same command, which lets Helm verify the server against your own certificate authority bundle. That keeps verification on and still works with private certificates.
Passing credentials to all domains
The option is described as passing credentials to all domains, which implies the default is narrower. It matters when a repository index points to chart archives on another host. Check the current Helm release notes for your version for the exact behavior.
The risk: credentials sent to a different domain, for example a storage service or CDN, are exposed to whoever runs it. If that host is compromised or misconfigured, so is your token.
Safer choices:
- Host index and archives on the same domain, so the option is not needed.
- Use a credential with read only access to that repository, nothing else.
- Prefer short lived tokens from your CI system over stored passwords.
- Read the password from standard input in scripts, so it does not appear in the process list or shell history.
A checklist for repository setup
| Item | Good practice |
|---|---|
| Transport | HTTPS with verification on |
| Private CA | Use the CA file option, not skip verification |
| Credentials | Read only, scoped, short lived |
| Domains | Index and archives on a domain you control |
| Config files | Keep the repository config out of shared images |
The command's inherited options include the repository config file location and the registry config file, which holds registry credentials. Treat those files as secrets, and do not bake them into container images.
Search your pipelines
Grep your scripts, Dockerfiles and CI files for the skip flag. Each hit is a decision someone made for convenience. Replace it with a proper CA file, or document why not. Add a rule in CI that fails new pull requests introducing it.
Where a scanner fits
Misconfigured fetch flags live in scripts, not in dependency files. Safeguard's policy gates can enforce rules on pull requests, and SBOM and dependency scanning cover the charts and images you end up with. Check which script and pipeline files your scanner reads. Free scan: gold.safeguard.sh/scan.
Quick check
Is there a safer alternative to skipping TLS verification for a private CA?
Yes. The helm repo add command has a CA file option to verify HTTPS servers using your own CA bundle, which keeps verification on.
How can I keep a password off the command line?
The command supports reading the password from standard input through its password-stdin option.
Sources
Last reviewed: 19 October 2026.
