# Kubernetes and VM Basic Auth Needed One Endpoint, Not Four > A deployed service's web address with no password on it is one click away from being locked down. ZopDay puts that click right next to the address itself: an admin clicks a lock icon, and the service… Source: https://zop.dev/resources/blogs/basic-auth-for-services-needed-one-endpoint-not-four Published: 2026-09-30 · Author: riya-mittal · Tags: cloudops, kubernetes, zopday --- A [deployed service's web address](https://zop.dev/resources/blogs/shareable-install-link-zopday) with no password on it is one click away from being locked down. ZopDay puts that click right next to the address itself: an admin clicks a lock icon, and the service gets HTTP Basic Auth. ZopDay generates both the username and the password. The password shows exactly once, with a Copy credentials control that grabs both values at once, because there won't be a second chance to see it on screen again. From that same place, the password can be rotated while the username stays fixed, or the whole thing can be removed. It works the same way whether the service runs on Kubernetes or on a VM, ZopCloud included. ## Only a Hash Is Ever Stored The provisioner builds the username as the service's own name plus six random characters, and generates a 24-character password alongside it. What actually persists afterward is the bcrypt hash of that password, nothing else. The real credential pair is handed back to whoever enabled the feature exactly once, at creation time, and never persisted anywhere in a form that could be read back out later. A system that can't produce your password even under compulsion is a meaningfully stronger guarantee than one that merely promises not to show it to anyone. ## One Feature, Three Enforcement Surfaces Where that hash actually gets enforced depends entirely on which infrastructure owns the service's route, and each one works differently. Architecture diagram On Kubernetes, enforcement is an owner-labeled Secret paired with nginx authentication annotations, written through whichever of three paths actually controls that service's ingress: a customer's own custom Ingress resource gets patched directly, a platform-managed Ingress gets its host configuration updated, and a chart-owned deployment goes through Helm release values and an upgrade. Only a specific, allowlisted set of annotation keys is permitted through any of the three paths, regardless of which one applies. On a [VM-hosted service](https://zop.dev/resources/blogs/idle-services-vm-sleep-and-wake), the password hash lives in a cloud secret manager alongside host annotations, and the deployer resolves that hash directly into Caddy's own basic_auth configuration directive. A VM that belongs to a shared ZopCloud pool gets an extra layer on top: the hash is stored under the pool account using a key that includes the calling organization's own id, and access is only permitted when the deployment genuinely belongs to that caller, sits in a shared space, and the VM is actually a member of that same space. Any other combination returns a uniform 403, deliberately uninformative, rather than a more specific error that could leak something about what else exists in that pool. ## Rotate Keeps the Name, Remove Waits for Agreement Only one credential pair exists per host at any time. Rotating the password leaves the username exactly as it was, so anything already configured to expect that username keeps working after a rotation. Removing Basic Auth strips the relevant annotations first, and only deletes the underlying secret once both the currently-live state and the newly-requested state agree that auth should be off. That ordering closes a specific race: deleting the secret too early, before confirming the live state actually reflects the removal, could destroy a credential still being actively relied on somewhere in flight. ## A Stage Bug Broke More Than Basic Auth A fix found directly on stage, in the same release, repaired something that looked unrelated to Basic Auth at first but genuinely wasn't. When a service had no saved port configuration, a config-only deploy would try to look up a port the running container had never actually published, and fail outright with an error about not being able to read the published host port. That failure didn't stay contained to Basic Auth. It also broke ordinary environment variable updates and plain Settings saves on that same service, because all three paths ran through the identical broken port lookup. The fix falls back to the container's one actually-published port when nothing was explicitly saved, logging a warning when it does, and still refuses outright when the container has published nothing at all for it to fall back to. ## Four Routes Became One The same follow-up release collapsed four separate API routes down to a single REST endpoint: one POST to enable Basic Auth, which returns the generated credentials directly in its response, and one DELETE to remove it, both taking an explicit target parameter set to either cluster or vm. A request whose stated target doesn't match the actual resource now returns a plain 400 rather than succeeding against the mismatched one. The old, separate VM-specific route was removed outright, with no backward-compatible alias left behind for anyone still calling it. That's a deliberately hard cutover rather than a gradual one, and it only works because the provisioner, the gateway, the [MCP server](https://zop.dev/resources/blogs/mcp-server-protocol-negotiation-and-discovery), and the frontend all shipped the change together in the same release, with nothing left depending on the old shape of the API.