Shared read-only account vs per-user server entries for Maven repository credentials

Confirmed facts

Maven reads the <servers> section from settings.xml (global or user) and selects the block whose <id> matches the repository URL’s <id> defined in the POM or distributionManagement. The selected credentials are used for both read and deploy operations unless a different server id is explicitly referenced in the POM (e.g., via <distributionManagement> with a separate repository or snapshotRepository id). Encrypted passwords in settings-security.xml are reversible obfuscation, not strong encryption.

Likely explanation

For least‑privilege access the goal is to limit each credential’s scope to what a principal actually needs. A shared read‑only account gives every developer broader read rights than necessary and couples revocation to the whole team. Per‑user accounts isolate blast‑radius and enable individual audit trails, but they increase the number of <server> blocks that must be maintained.

Teams that sustain low‑overhead per‑user credentials typically automate the generation of settings.xml from a directory service (LDAP, SSO, or an internal credential vault) using a script or configuration‑management tool. When such automation exists, the maintenance cost is amortized and the security benefit outweighs the extra XML entries. In environments without automated provisioning, a shared read‑only account combined with CI‑only deploy credentials is often the pragmatic compromise.

Steps for this case

1. Determine whether you can automate per‑user settings.xml updates (e.g., via a provisioning script that pulls credentials from a vault and writes ~/.m2/settings.xml).
2. If automation is available:
   • Create a distinct <server> block for each user (or service account) with read‑only rights.
   • Create a second <server> block with deploy rights, referenced only in the CI job’s settings.xml or via -s flag.
   • Keep the repository <id> identical for read and deploy; Maven will pick the appropriate block based on which settings file is active.
3. If automation is not available:
   • Use a single shared read‑only <server> block for all developers.
   • Store deploy credentials exclusively in the CI environment (e.g., injected as environment variables or a CI‑managed settings file).
   • Rotate the shared password on a regular schedule and communicate the change to the team.
4. To mitigate stale‑failure markers after credential rotation:
   • Run Maven with the -U (or --update-snapshots) flag to force update of metadata and snapshots.
   • Alternatively, delete the relevant artifact metadata under ~/.m2/repository (e.g., rm -rf ~/.m2/repository/com/example/*) before the next build.
   • There is no built‑in Maven option to automatically clear failure markers; the above manual steps are the documented workaround.

Missing diagnostic detail that could change the recommendation: Do you have an automated provisioning mechanism for generating or updating individual settings.xml files per developer? If yes, per‑user server IDs are sustainable; if not, the shared read‑only approach may be preferable.