Skip to content

Conversation

@dmihalcik-virtru
Copy link
Member

@dmihalcik-virtru dmihalcik-virtru commented Oct 28, 2025

Proposed Changes

  • Looking up a key now loads the manager field in the key provider
  • This is required, as the manager should be the factory key, not the name
  • This allows us to load the same manager multiple times with different configs.

HOWEVER the config is only looked at on the first load; we should update this so it evicts and reloads the provider if the config changes. This hopefully will come in a follow-up.

Similarly, we don't have much in the way of integration tests for these, since we don't include a key manager that takes a config. I'll look into starting the Vault sample plugin back up and running.

While I'm here, since our downstream deps no longer create them, I've removed support for the KeyManagerFactory that does not take a context object.

Checklist

  • I have added or updated unit tests
  • I have added or updated integration tests (if appropriate)
  • I have added or updated documentation

Testing Instructions

@github-actions github-actions bot added comp:db DB component comp:policy Policy Configuration ( attributes, subject mappings, resource mappings, kas registry) comp:kas Key Access Server size/m labels Oct 28, 2025
@github-actions
Copy link
Contributor

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 176.257239ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 102.910421ms

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric Value
Total Decrypts 100
Successful Decrypts 100
Failed Decrypts 0
Total Time 365.17113ms
Throughput 273.84 requests/second

TDF3 Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 40.02711364s
Average Latency 398.277495ms
Throughput 124.92 requests/second

NANOTDF Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 28.057643001s
Average Latency 279.537497ms
Throughput 178.20 requests/second

@github-actions
Copy link
Contributor

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 179.298752ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 97.228438ms

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric Value
Total Decrypts 100
Successful Decrypts 100
Failed Decrypts 0
Total Time 358.306732ms
Throughput 279.09 requests/second

TDF3 Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 38.954792686s
Average Latency 388.094958ms
Throughput 128.35 requests/second

NANOTDF Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 27.307295802s
Average Latency 272.141622ms
Throughput 183.10 requests/second

@github-actions
Copy link
Contributor

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 178.141572ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 102.93831ms

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric Value
Total Decrypts 100
Successful Decrypts 100
Failed Decrypts 0
Total Time 350.338843ms
Throughput 285.44 requests/second

TDF3 Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 38.76923911s
Average Latency 386.218126ms
Throughput 128.97 requests/second

NANOTDF Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 26.949404263s
Average Latency 268.18243ms
Throughput 185.53 requests/second

@github-actions
Copy link
Contributor

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 164.057467ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 100.648221ms

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric Value
Total Decrypts 100
Successful Decrypts 100
Failed Decrypts 0
Total Time 363.207306ms
Throughput 275.32 requests/second

TDF3 Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 38.545131442s
Average Latency 384.189ms
Throughput 129.72 requests/second

NANOTDF Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 27.329956246s
Average Latency 272.395285ms
Throughput 182.95 requests/second

@github-actions
Copy link
Contributor

- Looking up a key now loads the `manager` field in the key provider
- This is required, as the manager should be the factory key, not the name
- This allows us to load the same manager multiple times with different configs.

HOWEVER the config is only looked at on the first load; we should update this so it evicts and reloads the provider if the config changes. This will come in a follow-up.
@github-actions
Copy link
Contributor

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 180.310962ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 104.248642ms

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric Value
Total Decrypts 100
Successful Decrypts 100
Failed Decrypts 0
Total Time 373.463455ms
Throughput 267.76 requests/second

TDF3 Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 40.471342341s
Average Latency 402.909064ms
Throughput 123.54 requests/second

NANOTDF Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 28.347130536s
Average Latency 282.382921ms
Throughput 176.38 requests/second

@dmihalcik-virtru dmihalcik-virtru marked this pull request as ready for review October 28, 2025 16:53
@dmihalcik-virtru dmihalcik-virtru requested review from a team as code owners October 28, 2025 16:53
@github-actions
Copy link
Contributor

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 180.842782ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 105.262978ms

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric Value
Total Decrypts 100
Successful Decrypts 100
Failed Decrypts 0
Total Time 365.228438ms
Throughput 273.80 requests/second

TDF3 Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 38.138413215s
Average Latency 377.994127ms
Throughput 131.10 requests/second

NANOTDF Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 27.248109356s
Average Latency 271.614645ms
Throughput 183.50 requests/second

@github-actions
Copy link
Contributor

@strantalis
Copy link
Member

/gemini review

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request effectively refactors the key manager loading mechanism to use ProviderConfig, allowing for more flexible configurations. The changes are well-contained, and the removal of the legacy KeyManagerFactory without context is a good cleanup. The updates to use KeyManagerCtxFactories across the services are consistent. My review includes a couple of suggestions to improve error message clarity for better debuggability.

@github-actions
Copy link
Contributor

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 185.748857ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric Value
Approved Decision Requests 1000
Denied Decision Requests 0
Total Time 95.965618ms

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric Value
Total Decrypts 100
Successful Decrypts 100
Failed Decrypts 0
Total Time 359.449165ms
Throughput 278.20 requests/second

TDF3 Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 38.700367592s
Average Latency 385.243823ms
Throughput 129.20 requests/second

NANOTDF Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 27.437199122s
Average Latency 273.179549ms
Throughput 182.23 requests/second

@dmihalcik-virtru dmihalcik-virtru added this pull request to the merge queue Oct 29, 2025
Merged via the queue into main with commit 65ba2e0 Oct 29, 2025
38 checks passed
@dmihalcik-virtru dmihalcik-virtru deleted the DSPX-1841-pc-manager branch October 29, 2025 14:33
@strantalis
Copy link
Member

/backport

opentdf-automation bot pushed a commit that referenced this pull request Oct 29, 2025
### Proposed Changes

- Looking up a key now loads the `manager` field in the key provider
- This is required, as the manager should be the factory key, not the
name
- This allows us to load the same manager multiple times with different
configs.

HOWEVER the config is only looked at on the first load; we should update
this so it evicts and reloads the provider if the config changes. This
hopefully will come in a follow-up.

Similarly, we don't have much in the way of integration tests for these,
since we don't include a key manager that takes a config. I'll look into
starting the Vault sample plugin back up and running.

While I'm here, since our downstream deps no longer create them, I've
removed support for the `KeyManagerFactory` that does *not* take a
context object.

### Checklist

- [x] I have added or updated unit tests
- [ ] I have added or updated integration tests (if appropriate)
- [ ] I have added or updated documentation

### Testing Instructions

(cherry picked from commit 65ba2e0)
@opentdf-automation
Copy link
Contributor

Successfully created backport PR for release/service/v0.11:

opentdf-automation bot added a commit that referenced this pull request Oct 29, 2025
### Proposed Changes

- Looking up a key now loads the `manager` field in the key provider
- This is required, as the manager should be the factory key, not the
name
- This allows us to load the same manager multiple times with different
configs.

HOWEVER the config is only looked at on the first load; we should update
this so it evicts and reloads the provider if the config changes. This
hopefully will come in a follow-up.

Similarly, we don't have much in the way of integration tests for these,
since we don't include a key manager that takes a config. I'll look into
starting the Vault sample plugin back up and running.

While I'm here, since our downstream deps no longer create them, I've
removed support for the `KeyManagerFactory` that does *not* take a
context object.

### Checklist

- [x] I have added or updated unit tests
- [ ] I have added or updated integration tests (if appropriate)
- [ ] I have added or updated documentation

### Testing Instructions

(cherry picked from commit 65ba2e0)
jakedoublev pushed a commit that referenced this pull request Oct 29, 2025
…se/service/v0.11] (#2842)

# Description
Backport of #2837 to `release/service/v0.11`.

Co-authored-by: opentdf-automation[bot] <149537512+opentdf-automation[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport release/service/v0.11 comp:db DB component comp:kas Key Access Server comp:policy Policy Configuration ( attributes, subject mappings, resource mappings, kas registry) size/m

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants