fix: create a dedicated AWS-XKS user and grant permissions for him - #1107
Open
Manuthor wants to merge 9 commits into
Open
fix: create a dedicated AWS-XKS user and grant permissions for him#1107Manuthor wants to merge 9 commits into
Manuthor wants to merge 9 commits into
Conversation
Manuthor
force-pushed
the
fix/xks_permissions
branch
from
September 3, 2026 09:37
a140315 to
12fd9fd
Compare
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
Manuthor
force-pushed
the
fix/xks_permissions
branch
from
September 3, 2026 09:56
12fd9fd to
fcc7978
Compare
Manuthor
added a commit
that referenced
this pull request
Sep 3, 2026
…WS XKS authorization Addresses 5 review findings on PR #1107 (also confirmed independently by /threat-model analysis), all rooted in the fact that nothing enforced the invariant that AWS_XKS_SERVICE_USER cannot collide with, or be granted through, any other reachable identity/configuration: 1. CreateKey idempotent-collision path only checked object_type == SymmetricKey before granting AWS_XKS_SERVICE_USER Encrypt/Decrypt/ GetAttributes, letting a signed XKS CreateKey request adopt an arbitrary pre-existing non-XKS symmetric key. Now also requires the aws-xks tag; otherwise fails closed. (CWE-863/CWE-284) 2. Externally-derived identities (OIDC JWT email/sub, Auth Verifier JWT, mTLS certificate CN, SPIRE SVID, UI session/OIDC login) were never checked against the reserved AWS_XKS_SERVICE_USER string, so a client-controlled identity equal to "[aws-xks-service]" could authenticate as the XKS delegate on the normal KMIP/REST surface. Added a single `reject_reserved_aws_xks_identity` guard invoked at every such construction site. (CWE-290) 3. `crypto_officer.users` containing AWS_XKS_SERVICE_USER would grant it full Crypto Officer rights, defeating the least-privilege design. Server startup now rejects this configuration when AWS XKS is enabled. (CWE-269) 4. `default_username == AWS_XKS_SERVICE_USER` made every CreateKey fail permanently (self-grant rejected by grant_access). Server startup now rejects this configuration when AWS XKS is enabled. (CWE-20) 5. The startup migration for legacy aws-xks keys only granted access on behalf of the *current* default_username, silently stranding keys created under a previously-configured default_username after a rotation. The migration now resolves and grants on behalf of each key's actual persisted owner. (CWE-284) All changes verified: `cargo build -p cosmian_kms_server`, full `cargo test -p cosmian_kms_server --lib` (397 passed, 0 failed), and `cargo clippy -p cosmian_kms_server --all-targets --all-features -- -D warnings` (zero warnings).
Manuthor
added a commit
that referenced
this pull request
Sep 3, 2026
…ration Previously, if retrieve_object() failed for a tagged aws-xks key during migrate_aws_xks_key_access, the error was logged and the key was skipped, allowing server startup to succeed while that key remained unusable through XKS (missing the AWS_XKS_SERVICE_USER grant) until a later successful migration attempt. Propagate the error via '?' so startup fails fast on a database read failure instead of silently completing an incomplete migration. Addresses PR review comment (macroscopeapp) on commit 64b5699: #1107 (comment)
Manuthor
added a commit
that referenced
this pull request
Sep 3, 2026
…WS XKS authorization Addresses 5 review findings on PR #1107 (also confirmed independently by /threat-model analysis), all rooted in the fact that nothing enforced the invariant that AWS_XKS_SERVICE_USER cannot collide with, or be granted through, any other reachable identity/configuration: 1. CreateKey idempotent-collision path only checked object_type == SymmetricKey before granting AWS_XKS_SERVICE_USER Encrypt/Decrypt/ GetAttributes, letting a signed XKS CreateKey request adopt an arbitrary pre-existing non-XKS symmetric key. Now also requires the aws-xks tag; otherwise fails closed. (CWE-863/CWE-284) 2. Externally-derived identities (OIDC JWT email/sub, Auth Verifier JWT, mTLS certificate CN, SPIRE SVID, UI session/OIDC login) were never checked against the reserved AWS_XKS_SERVICE_USER string, so a client-controlled identity equal to "[aws-xks-service]" could authenticate as the XKS delegate on the normal KMIP/REST surface. Added a single `reject_reserved_aws_xks_identity` guard invoked at every such construction site. (CWE-290) 3. `crypto_officer.users` containing AWS_XKS_SERVICE_USER would grant it full Crypto Officer rights, defeating the least-privilege design. Server startup now rejects this configuration when AWS XKS is enabled. (CWE-269) 4. `default_username == AWS_XKS_SERVICE_USER` made every CreateKey fail permanently (self-grant rejected by grant_access). Server startup now rejects this configuration when AWS XKS is enabled. (CWE-20) 5. The startup migration for legacy aws-xks keys only granted access on behalf of the *current* default_username, silently stranding keys created under a previously-configured default_username after a rotation. The migration now resolves and grants on behalf of each key's actual persisted owner. (CWE-284) All changes verified: `cargo build -p cosmian_kms_server`, full `cargo test -p cosmian_kms_server --lib` (397 passed, 0 failed), and `cargo clippy -p cosmian_kms_server --all-targets --all-features -- -D warnings` (zero warnings).
Manuthor
added a commit
that referenced
this pull request
Sep 3, 2026
…ration Previously, if retrieve_object() failed for a tagged aws-xks key during migrate_aws_xks_key_access, the error was logged and the key was skipped, allowing server startup to succeed while that key remained unusable through XKS (missing the AWS_XKS_SERVICE_USER grant) until a later successful migration attempt. Propagate the error via '?' so startup fails fast on a database read failure instead of silently completing an incomplete migration. Addresses PR review comment (macroscopeapp) on commit 64b5699: #1107 (comment)
Manuthor
force-pushed
the
fix/xks_permissions
branch
from
September 3, 2026 15:19
8cd2ea3 to
943a224
Compare
Manuthor
added a commit
that referenced
this pull request
Sep 3, 2026
…WS XKS authorization Addresses 5 review findings on PR #1107 (also confirmed independently by /threat-model analysis), all rooted in the fact that nothing enforced the invariant that AWS_XKS_SERVICE_USER cannot collide with, or be granted through, any other reachable identity/configuration: 1. CreateKey idempotent-collision path only checked object_type == SymmetricKey before granting AWS_XKS_SERVICE_USER Encrypt/Decrypt/ GetAttributes, letting a signed XKS CreateKey request adopt an arbitrary pre-existing non-XKS symmetric key. Now also requires the aws-xks tag; otherwise fails closed. (CWE-863/CWE-284) 2. Externally-derived identities (OIDC JWT email/sub, Auth Verifier JWT, mTLS certificate CN, SPIRE SVID, UI session/OIDC login) were never checked against the reserved AWS_XKS_SERVICE_USER string, so a client-controlled identity equal to "[aws-xks-service]" could authenticate as the XKS delegate on the normal KMIP/REST surface. Added a single `reject_reserved_aws_xks_identity` guard invoked at every such construction site. (CWE-290) 3. `crypto_officer.users` containing AWS_XKS_SERVICE_USER would grant it full Crypto Officer rights, defeating the least-privilege design. Server startup now rejects this configuration when AWS XKS is enabled. (CWE-269) 4. `default_username == AWS_XKS_SERVICE_USER` made every CreateKey fail permanently (self-grant rejected by grant_access). Server startup now rejects this configuration when AWS XKS is enabled. (CWE-20) 5. The startup migration for legacy aws-xks keys only granted access on behalf of the *current* default_username, silently stranding keys created under a previously-configured default_username after a rotation. The migration now resolves and grants on behalf of each key's actual persisted owner. (CWE-284) All changes verified: `cargo build -p cosmian_kms_server`, full `cargo test -p cosmian_kms_server --lib` (397 passed, 0 failed), and `cargo clippy -p cosmian_kms_server --all-targets --all-features -- -D warnings` (zero warnings).
Manuthor
added a commit
that referenced
this pull request
Sep 3, 2026
…ration Previously, if retrieve_object() failed for a tagged aws-xks key during migrate_aws_xks_key_access, the error was logged and the key was skipped, allowing server startup to succeed while that key remained unusable through XKS (missing the AWS_XKS_SERVICE_USER grant) until a later successful migration attempt. Propagate the error via '?' so startup fails fast on a database read failure instead of silently completing an incomplete migration. Addresses PR review comment (macroscopeapp) on commit 64b5699: #1107 (comment)
Manuthor
force-pushed
the
fix/xks_permissions
branch
from
September 3, 2026 20:41
943a224 to
7cb4fd0
Compare
Manuthor
added a commit
that referenced
this pull request
Sep 4, 2026
…WS XKS authorization Addresses 5 review findings on PR #1107 (also confirmed independently by /threat-model analysis), all rooted in the fact that nothing enforced the invariant that AWS_XKS_SERVICE_USER cannot collide with, or be granted through, any other reachable identity/configuration: 1. CreateKey idempotent-collision path only checked object_type == SymmetricKey before granting AWS_XKS_SERVICE_USER Encrypt/Decrypt/ GetAttributes, letting a signed XKS CreateKey request adopt an arbitrary pre-existing non-XKS symmetric key. Now also requires the aws-xks tag; otherwise fails closed. (CWE-863/CWE-284) 2. Externally-derived identities (OIDC JWT email/sub, Auth Verifier JWT, mTLS certificate CN, SPIRE SVID, UI session/OIDC login) were never checked against the reserved AWS_XKS_SERVICE_USER string, so a client-controlled identity equal to "[aws-xks-service]" could authenticate as the XKS delegate on the normal KMIP/REST surface. Added a single `reject_reserved_aws_xks_identity` guard invoked at every such construction site. (CWE-290) 3. `crypto_officer.users` containing AWS_XKS_SERVICE_USER would grant it full Crypto Officer rights, defeating the least-privilege design. Server startup now rejects this configuration when AWS XKS is enabled. (CWE-269) 4. `default_username == AWS_XKS_SERVICE_USER` made every CreateKey fail permanently (self-grant rejected by grant_access). Server startup now rejects this configuration when AWS XKS is enabled. (CWE-20) 5. The startup migration for legacy aws-xks keys only granted access on behalf of the *current* default_username, silently stranding keys created under a previously-configured default_username after a rotation. The migration now resolves and grants on behalf of each key's actual persisted owner. (CWE-284) All changes verified: `cargo build -p cosmian_kms_server`, full `cargo test -p cosmian_kms_server --lib` (397 passed, 0 failed), and `cargo clippy -p cosmian_kms_server --all-targets --all-features -- -D warnings` (zero warnings).
Manuthor
added a commit
that referenced
this pull request
Sep 4, 2026
…ration Previously, if retrieve_object() failed for a tagged aws-xks key during migrate_aws_xks_key_access, the error was logged and the key was skipped, allowing server startup to succeed while that key remained unusable through XKS (missing the AWS_XKS_SERVICE_USER grant) until a later successful migration attempt. Propagate the error via '?' so startup fails fast on a database read failure instead of silently completing an incomplete migration. Addresses PR review comment (macroscopeapp) on commit 64b5699: #1107 (comment)
Manuthor
force-pushed
the
fix/xks_permissions
branch
from
September 4, 2026 04:58
b7ed3e7 to
e747f3b
Compare
…WS XKS authorization Addresses 5 review findings on PR #1107 (also confirmed independently by /threat-model analysis), all rooted in the fact that nothing enforced the invariant that AWS_XKS_SERVICE_USER cannot collide with, or be granted through, any other reachable identity/configuration: 1. CreateKey idempotent-collision path only checked object_type == SymmetricKey before granting AWS_XKS_SERVICE_USER Encrypt/Decrypt/ GetAttributes, letting a signed XKS CreateKey request adopt an arbitrary pre-existing non-XKS symmetric key. Now also requires the aws-xks tag; otherwise fails closed. (CWE-863/CWE-284) 2. Externally-derived identities (OIDC JWT email/sub, Auth Verifier JWT, mTLS certificate CN, SPIRE SVID, UI session/OIDC login) were never checked against the reserved AWS_XKS_SERVICE_USER string, so a client-controlled identity equal to "[aws-xks-service]" could authenticate as the XKS delegate on the normal KMIP/REST surface. Added a single `reject_reserved_aws_xks_identity` guard invoked at every such construction site. (CWE-290) 3. `crypto_officer.users` containing AWS_XKS_SERVICE_USER would grant it full Crypto Officer rights, defeating the least-privilege design. Server startup now rejects this configuration when AWS XKS is enabled. (CWE-269) 4. `default_username == AWS_XKS_SERVICE_USER` made every CreateKey fail permanently (self-grant rejected by grant_access). Server startup now rejects this configuration when AWS XKS is enabled. (CWE-20) 5. The startup migration for legacy aws-xks keys only granted access on behalf of the *current* default_username, silently stranding keys created under a previously-configured default_username after a rotation. The migration now resolves and grants on behalf of each key's actual persisted owner. (CWE-284) All changes verified: `cargo build -p cosmian_kms_server`, full `cargo test -p cosmian_kms_server --lib` (397 passed, 0 failed), and `cargo clippy -p cosmian_kms_server --all-targets --all-features -- -D warnings` (zero warnings).
…ration Previously, if retrieve_object() failed for a tagged aws-xks key during migrate_aws_xks_key_access, the error was logged and the key was skipped, allowing server startup to succeed while that key remained unusable through XKS (missing the AWS_XKS_SERVICE_USER grant) until a later successful migration attempt. Propagate the error via '?' so startup fails fast on a database read failure instead of silently completing an incomplete migration. Addresses PR review comment (macroscopeapp) on commit 64b5699: #1107 (comment)
GET /ocsp/{encoded_request} decoded the base64url path segment with the
padded URL_SAFE engine, which rejects any input missing '=' padding.
RFC 6960 Appendix A does not mandate padding, and several real clients
(including openssl ocsp, used by this project's own black-box OCSP
test suite) emit unpadded base64url, so well-formed GET requests were
being rejected with a spurious 422 instead of returning the expected
signed OCSP response.
Switch to a custom base64 engine with DecodePaddingMode::Indifferent,
which accepts both padded and unpadded input on decode.
Also reorders an import in crate/crypto/src/openssl/ocsp.rs to satisfy
nightly rustfmt (pre-existing drift, unrelated to the fix above but
required by the pre-commit hook to land it).
eviden.com (Proteccio HSM vendor page) currently returns 503 Service Unavailable to automated crawlers, blocking the lychee pre-commit hook for every commit — including ones that never touch documentation. Excluded following the same precedent already used for other sites that return 5xx to bots (docs.fortinet.com, www.ibm.com, etc.).
Manuthor
force-pushed
the
fix/xks_permissions
branch
from
September 4, 2026 14:13
a4583bc to
bb8dab8
Compare
| let xks_service_user = UserId::from(AWS_XKS_SERVICE_USER); | ||
| let granted = kms_server | ||
| .database | ||
| .list_user_operations_on_object(&uid, &xks_service_user, false) |
There was a problem hiding this comment.
🟠 High src/start_kms_server.rs:286
The migration can skip the durable [aws-xks-service] grant and leave XKS operations dependent on a wildcard grant. Because false includes inherited permissions in granted, a key with all three operations granted to * is treated as migrated; revoking that wildcard grant then breaks XKS access. Query direct permissions with no_inherited_access = true so the explicit service grant is created.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @crate/server/src/start_kms_server.rs around line 286:
The migration can skip the durable `[aws-xks-service]` grant and leave XKS operations dependent on a wildcard grant. Because `false` includes inherited permissions in `granted`, a key with all three operations granted to `*` is treated as migrated; revoking that wildcard grant then breaks XKS access. Query direct permissions with `no_inherited_access = true` so the explicit service grant is created.
| validate_aws_xks_reserved_identity_config(&kms_server.params)?; | ||
| // Grant the reserved XKS service identity usage on XKS keys created by earlier | ||
| // versions. See `migrate_aws_xks_key_access`. | ||
| migrate_aws_xks_key_access(&kms_server).await?; |
There was a problem hiding this comment.
🟡 Medium src/start_kms_server.rs:1100
prepare_kms_server blocks HTTP server construction and binding until migrate_aws_xks_key_access finishes. Because the migration has no durable completion marker and scans every tagged key serially on each restart, installations with many XKS keys incur an unbounded repeated startup delay; move it to a bounded/background migration or persist completion state.
🚀 Reply "fix it for me" or copy this AI Prompt for your agent:
In file @crate/server/src/start_kms_server.rs around line 1100:
`prepare_kms_server` blocks HTTP server construction and binding until `migrate_aws_xks_key_access` finishes. Because the migration has no durable completion marker and scans every tagged key serially on each restart, installations with many XKS keys incur an unbounded repeated startup delay; move it to a bounded/background migration or persist completion state.
Unit tests added for UserId::try_new use assert!(...is_err()) and .expect() on Result, which are idiomatic in test code but denied workspace-wide (clippy::expect_used, clippy::assertions_on_result_states). Allow both on the test module, following the existing precedent in crate/interfaces/src/object_handle.rs.
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
1 participant
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.
Closes #1093
Note
Introduce reserved
AWS_XKS_SERVICE_USERidentity for XKS operations and grants[aws-xks-service]used as a least-privilege delegate for all XKS encrypt, decrypt, metadata, and key-creation operations, replacing caller-ARN authorizationdefault_username; CreateKey grants the reserved identity exactlyEncrypt,Decrypt, andGetAttributes, rejects non-XKS symmetric-key ID collisions, and is idempotentaws-xks-tagged legacy keys and grants the reserved identity its three permissions using each key's actual ownerdefault_usernameor a crypto-officer userawsPrincipalArnfrom request metadata; the ARN is now audit-only. Existing XKS keys created under a previousdefault_usernamereceive the reserved-identity grants at next startup. The reserved identity string[aws-xks-service]is now prohibited indefault_usernameandcrypto_officer.userswhen XKS is enabled.Macroscope summarized 38908c1.