Porch does not actively detect or react to changes in repository credential Secrets. When a user updates the data field of a Secret referenced by a Repository's spec.git.secretRef (or spec.oci.secretRef), neither porch-server nor porch-controller proactively invalidates and re-fetches the credential. The behavior degrades differently between the two components:
porch-server: The cached gitRepository instance holds credentials in memory. On the next git operation, if authentication fails with transport.ErrAuthenticationRequired, doGitWithAuth retries with forceRefresh=true, which re-reads the Secret from the Kubernetes API. This is reactive recovery only — it works, but incurs at least one failed operation before self-healing.
porch-controller: Same reactive retry exists (shared doGitWithAuth code path), but the controller only reconciles on Repository spec changes (generation increments) or periodic requeue timers. It does not watch Secret objects. If auth fails and the error is not precisely transport.ErrAuthenticationRequired (e.g., 403 Forbidden from a different permission issue, or a network error masking the root cause), the controller enters a retry loop without ever re-fetching the secret, as BasicAuthCredential.Valid() and BearerTokenAuthCredentials.Valid() unconditionally return true.
Possible solutions -
Always re-read — picks up the new user on the very next git operation.
Watch Secrets — detects the change, triggers a reconcile that force-refreshes.
Porch does not actively detect or react to changes in repository credential Secrets. When a user updates the data field of a Secret referenced by a Repository's spec.git.secretRef (or spec.oci.secretRef), neither porch-server nor porch-controller proactively invalidates and re-fetches the credential. The behavior degrades differently between the two components:
porch-server: The cached gitRepository instance holds credentials in memory. On the next git operation, if authentication fails with transport.ErrAuthenticationRequired, doGitWithAuth retries with forceRefresh=true, which re-reads the Secret from the Kubernetes API. This is reactive recovery only — it works, but incurs at least one failed operation before self-healing.
porch-controller: Same reactive retry exists (shared doGitWithAuth code path), but the controller only reconciles on Repository spec changes (generation increments) or periodic requeue timers. It does not watch Secret objects. If auth fails and the error is not precisely transport.ErrAuthenticationRequired (e.g., 403 Forbidden from a different permission issue, or a network error masking the root cause), the controller enters a retry loop without ever re-fetching the secret, as BasicAuthCredential.Valid() and BearerTokenAuthCredentials.Valid() unconditionally return true.
Possible solutions -
Always re-read — picks up the new user on the very next git operation.
Watch Secrets — detects the change, triggers a reconcile that force-refreshes.