It is possible, and the Spark docs warn to be careful. The submitting applications page says credentials can be embedded in the URI of an extra repository, in the form user, colon, password, at the host. That string then appears in command lines, scripts and logs. Prefer a mirror reachable by network policy, or a secret injected at run time.
What the docs describe
The spark-submit options include one for extra repositories, a comma-delimited list for resolving packages listed by Maven coordinates. The docs note you can supply credentials in the URI and add: "Be careful when supplying credentials this way."
That is the entire guidance. The page does not say where the credential will end up, so it is worth thinking through.
Where the string travels
A repository URL with a password in it is not a private value once you pass it as an argument. Think about everywhere a submit command goes:
- Shell history on the machine that ran it.
- Process listings on the host, where other users may read command lines.
- CI job logs, which many people can read and which often live for months.
- Workflow files and orchestrator task definitions stored in Git.
- Application logs and the Spark UI environment page, depending on what is recorded and redacted.
Spark's redaction feature works by matching patterns, and it can miss a value that does not look like a secret to the pattern. See the earlier post on what the redaction regex hides and misses.
Better options
- A mirror inside your network. Point the repository option at an internal artifact repository that workers can reach without a password, with network rules deciding who may connect. This also gives you one place to review what enters.
- Prebuilt jars. Resolve dependencies at build time, publish an assembly jar or a set of jars to your artifact store, and have jobs use the jars option. This removes run-time resolution and the credential together. The docs describe both the assembly approach and the jars option.
- Credentials from a secret store. If the job must authenticate, fetch the credential at run time and inject it through a mechanism that does not echo to logs. Check your orchestrator's masking behavior with a test value.
- Short-lived tokens. Where your repository supports them, use tokens that expire quickly, so a leaked string has a limited life.
If you already did this
- Search your repositories, CI logs and scripts for URLs with a user and password before the host.
- Treat any credential you find as exposed. Rotate it.
- Replace the pattern with one of the options above.
- Add a repository scan rule or review step so it does not return.
Why this belongs in dependency security
Repositories are where your dependencies enter. A leaked repository credential can let someone read your private artifacts, and if it carries publish rights, change them. Give resolvers read-only access, and keep publish credentials in a separate, tightly held place.
Safeguard's SBOM and dependency scanning can show what packages your Spark jobs resolve, and its policies and gates can block builds that add unreviewed ones. The free scan at https://gold.safeguard.sh/scan is a quick starting point.
Quick check
Does the Spark UI hide a password in a repository URL?
Do not assume so. Redaction matches patterns and can miss values. Test with a harmless value before trusting it.
Is a read-only repository account enough?
It limits damage, since it cannot publish. The account can still read private artifacts, so rotate it if it leaks.
Sources
Last reviewed: 19 October 2026.
