Repository navigation
fix(gcs): use a separate credentials file per secret key - #309
Merged
Merged
Conversation
leonardoce
force-pushed
the
dev/gcs-credentials-per-store
branch
from
October 2, 2026 08:15
24110fd to
120366b
Compare
Contributor
|
I opened cloudnative-pg/machinery#325 to fix the reason why we need |
leonardoce
approved these changes
Oct 5, 2026
NiccoloFei
approved these changes
Oct 12, 2026
mnencia
changed the title
A single process can run barman-cloud commands for different object stores at the same time. A replica cluster, for instance, archives WAL to its own object store while restoring it from the source one. The Google application credentials were always written to the same file, so a command could run with the credentials of another object store, and an object store using the GKE environment emptied the file the other commands were reading. Write each credentials file to a path that depends on the referenced secret and key, point GOOGLE_APPLICATION_CREDENTIALS at it, and serialize the writes. The GKE environment no longer touches any file. Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
mnencia
force-pushed
the
dev/gcs-credentials-per-store
branch
from
October 14, 2026 07:45
120366b to
b03f9b9
Compare
mnencia
approved these changes
Oct 14, 2026
The mutex comment now says when to remove it. Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
mnencia
changed the title
leonardoce
approved these changes
Oct 14, 2026
mnencia
added a commit
that referenced
this pull request
Oct 16, 2026
Remove `googleCredentialsMutex`. It serialized the writes of the GCS credentials file because `WriteFileAtomic` named its temporary file after the current second, so concurrent writes of the same file shared it. machinery v0.6.1 uses a random suffix, which was the condition set in #309 to drop the mutex (cloudnative-pg/machinery#325). Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A process can run barman-cloud commands for different object stores at the same time. For example, a replica cluster archives WAL to its own store and restores from the source one. All Google credentials went to one shared file, so a command could run with the identity of another store. A store using the GKE environment also emptied the file while other commands read it.
Each secret key now has its own file,
/controller/.google-credentials/<secret>/<key>, andGOOGLE_APPLICATION_CREDENTIALSpoints to it. The GKE environment no longer writes any file. Writes are serialized becauseWriteFileAtomicnames its temporary file after the current second.Same problem as #284, for SSE-C keys.