fix(vault): let vault entity cache key not containing workspace id #13610
Conversation
This file contains 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
github-actions
bot
added
core/db
schema-change-noteworthy
cherry-pick kong-ee
|
Since OSS does not have workspace related tests, corresponding test has been added in the EE cherry-pick PR. |
bungle
approved these changes
Sep 3, 2024
catbro666
approved these changes
Sep 4, 2024
tzssangglass
approved these changes
Sep 4, 2024
windmgc
removed
the
cherry-pick kong-ee
andrewgkew
pushed a commit
to andrewgkew/kong
that referenced
this pull request
Sep 5, 2024
…ong#13610) This PR modifies the `cache_key` function of the vault entity to always generate a cache key without workspace id. Vault entity is workspace-able, but our secret rotation timer always run without workspace settings(thus the default workspace is being used), so during secret rotation, the code https://github.com/Kong/kong/blob/4e38b965b922f57febe8652fb96b7d74aeab591a/kong/pdk/vault.lua#L620-L621 will generate a duplicate vault cache with default workspace id for each non-default workspace vault entity, and those cache will never be refreshed. The result of this issue is that when you update a vault entity's configuration inside a non-default workspace, it will never take effect in the secret rotation. Since the prefix of vault entity is unique across workspaces, it should be safe to only use one cache key without workspace id, so that the correct cache is used during secret rotation. FTI-6152
github-actions bot
pushed a commit
that referenced
this pull request
Sep 14, 2024
…13610) This PR modifies the `cache_key` function of the vault entity to always generate a cache key without workspace id. Vault entity is workspace-able, but our secret rotation timer always run without workspace settings(thus the default workspace is being used), so during secret rotation, the code https://github.com/Kong/kong/blob/4e38b965b922f57febe8652fb96b7d74aeab591a/kong/pdk/vault.lua#L620-L621 will generate a duplicate vault cache with default workspace id for each non-default workspace vault entity, and those cache will never be refreshed. The result of this issue is that when you update a vault entity's configuration inside a non-default workspace, it will never take effect in the secret rotation. Since the prefix of vault entity is unique across workspaces, it should be safe to only use one cache key without workspace id, so that the correct cache is used during secret rotation. FTI-6152 (cherry picked from commit 3455151)
|
Git push to origin failed for release/3.7.x with exitcode 1 |
3 tasks
|
Successfully created backport PR for |
github-actions bot
pushed a commit
that referenced
this pull request
Sep 14, 2024
…13610) This PR modifies the `cache_key` function of the vault entity to always generate a cache key without workspace id. Vault entity is workspace-able, but our secret rotation timer always run without workspace settings(thus the default workspace is being used), so during secret rotation, the code https://github.com/Kong/kong/blob/4e38b965b922f57febe8652fb96b7d74aeab591a/kong/pdk/vault.lua#L620-L621 will generate a duplicate vault cache with default workspace id for each non-default workspace vault entity, and those cache will never be refreshed. The result of this issue is that when you update a vault entity's configuration inside a non-default workspace, it will never take effect in the secret rotation. Since the prefix of vault entity is unique across workspaces, it should be safe to only use one cache key without workspace id, so that the correct cache is used during secret rotation. FTI-6152 (cherry picked from commit 3455151)
3 tasks
|
Git push to origin failed for release/3.8.x with exitcode 1 |
|
Successfully created backport PR for |
github-actions bot
pushed a commit
that referenced
this pull request
Sep 14, 2024
…13610) This PR modifies the `cache_key` function of the vault entity to always generate a cache key without workspace id. Vault entity is workspace-able, but our secret rotation timer always run without workspace settings(thus the default workspace is being used), so during secret rotation, the code https://github.com/Kong/kong/blob/4e38b965b922f57febe8652fb96b7d74aeab591a/kong/pdk/vault.lua#L620-L621 will generate a duplicate vault cache with default workspace id for each non-default workspace vault entity, and those cache will never be refreshed. The result of this issue is that when you update a vault entity's configuration inside a non-default workspace, it will never take effect in the secret rotation. Since the prefix of vault entity is unique across workspaces, it should be safe to only use one cache key without workspace id, so that the correct cache is used during secret rotation. FTI-6152 (cherry picked from commit 3455151)
3 tasks
|
Git push to origin failed for release/3.7.x with exitcode 1 |
|
Successfully created backport PR for |
|
Git push to origin failed for release/3.8.x with exitcode 1 |
|
Git push to origin failed for release/3.6.x with exitcode 1 |
ms2008
pushed a commit
that referenced
this pull request
Sep 14, 2024
…13610) This PR modifies the `cache_key` function of the vault entity to always generate a cache key without workspace id. Vault entity is workspace-able, but our secret rotation timer always run without workspace settings(thus the default workspace is being used), so during secret rotation, the code https://github.com/Kong/kong/blob/4e38b965b922f57febe8652fb96b7d74aeab591a/kong/pdk/vault.lua#L620-L621 will generate a duplicate vault cache with default workspace id for each non-default workspace vault entity, and those cache will never be refreshed. The result of this issue is that when you update a vault entity's configuration inside a non-default workspace, it will never take effect in the secret rotation. Since the prefix of vault entity is unique across workspaces, it should be safe to only use one cache key without workspace id, so that the correct cache is used during secret rotation. FTI-6152 (cherry picked from commit 3455151)
ms2008
pushed a commit
that referenced
this pull request
Sep 14, 2024
…13610) This PR modifies the `cache_key` function of the vault entity to always generate a cache key without workspace id. Vault entity is workspace-able, but our secret rotation timer always run without workspace settings(thus the default workspace is being used), so during secret rotation, the code https://github.com/Kong/kong/blob/4e38b965b922f57febe8652fb96b7d74aeab591a/kong/pdk/vault.lua#L620-L621 will generate a duplicate vault cache with default workspace id for each non-default workspace vault entity, and those cache will never be refreshed. The result of this issue is that when you update a vault entity's configuration inside a non-default workspace, it will never take effect in the secret rotation. Since the prefix of vault entity is unique across workspaces, it should be safe to only use one cache key without workspace id, so that the correct cache is used during secret rotation. FTI-6152 (cherry picked from commit 3455151)
windmgc
added a commit
that referenced
this pull request
Sep 14, 2024
…13610) This PR modifies the `cache_key` function of the vault entity to always generate a cache key without workspace id. Vault entity is workspace-able, but our secret rotation timer always run without workspace settings(thus the default workspace is being used), so during secret rotation, the code https://github.com/Kong/kong/blob/4e38b965b922f57febe8652fb96b7d74aeab591a/kong/pdk/vault.lua#L620-L621 will generate a duplicate vault cache with default workspace id for each non-default workspace vault entity, and those cache will never be refreshed. The result of this issue is that when you update a vault entity's configuration inside a non-default workspace, it will never take effect in the secret rotation. Since the prefix of vault entity is unique across workspaces, it should be safe to only use one cache key without workspace id, so that the correct cache is used during secret rotation. FTI-6152 (cherry picked from commit 3455151)
|
Cherrypick in https://github.com/Kong/kong-ee/pull/10165 |
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.
Summary
This PR modifies the
cache_keyfunction of the vault entity to always generate a cache key without workspace id.Vault entity is workspace-able, but our secret rotation timer always run without workspace settings(thus the default workspace is being used), so during secret rotation, the code
kong/kong/pdk/vault.lua
Lines 620 to 621 in 4e38b96
Since the prefix of vault entity is unique across workspaces, it should be safe to only use one cache key without workspace id, so that the correct cache is used during secret rotation.
Checklist
changelog/unreleased/kongorskip-changeloglabel added on PR if changelog is unnecessary. README.mdIssue reference
FTI-6152