Skip to content

Conversation

opentdf-automation[bot]
Copy link
Contributor

Description

Backport of #2601 to release/service/v0.8.

@opentdf-automation
Copy link
Contributor Author

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin backport-2601-to-release/service/v0.8
git worktree add --checkout .worktree/backport-2601-to-release/service/v0.8 backport-2601-to-release/service/v0.8
cd .worktree/backport-2601-to-release/service/v0.8
git reset --hard HEAD^
git cherry-pick -x a5fc994acc5491bf8cbf751b675302b459e1f3b0
git push --force-with-lease

@opentdf-automation opentdf-automation bot force-pushed the backport-2601-to-release/service/v0.8 branch from 4769755 to effc352 Compare September 12, 2025 14:04
@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 docs Documentation size/m labels Sep 12, 2025
…-instance support (#2601)

This PR implements the provider configuration manager column enhancement
and includes a significant architecture improvement to eliminate code
duplication.

 Core Features

- ✅ Added manager column to provider_config table with composite unique
constraint (provider_name + manager)
- ✅ Database migration with backward compatibility (existingrecords
default to 'local' manager)
- ✅ Updated protobuf definitions to require manager field in API
requests
  - ✅ Enhanced SQL queries and audit logging to support manager field

  Key Benefits

1. Multiple Instance Support: Create multiple provider configs with same
name but different manager types
2. No Code Duplication: Trust system is single source of truth for
available managers
3. Automatic Discovery: Well-known configuration endpoint automatically
exposes registered trust key managers
4. Premium Integration: Custom managers integrate seamlessly via
existing WithTrustKeyManagerFactories pattern
5. Backward Compatibility: Existing providers automatically assigned
'local' manager type

  Technical Changes

  - Database: Added manager column with composite unique constraint
- API: Manager field now required in CreateProviderConfig, optional in
UpdateProviderConfig
- Service: Validates against RegistrationParams.KeyManagerFactories
instead of separate registry
- Well-known Config: Dynamically populated from trust key manager
factories
  - Tests: Updated to reflect new validation approach

  Usage for Custom Managers

  Premium builds can add custom managers using the existing
  pattern:
```go
  server.Start(
      server.WithTrustKeyManagerFactories(
          trust.NamedKeyManagerFactory{Name: "premium-hsm",
  Factory: hsmFactory},
          trust.NamedKeyManagerFactory{Name: "premium-vault",
  Factory: vaultFactory},
      ),
  )
```

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

(cherry picked from commit a5fc994)
@strantalis strantalis force-pushed the backport-2601-to-release/service/v0.8 branch from effc352 to c1d3396 Compare September 15, 2025 15:53
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.161299ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

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

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric Value
Total Decrypts 100
Successful Decrypts 100
Failed Decrypts 0
Total Time 354.415336ms
Throughput 282.15 requests/second

TDF3 Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 37.399009864s
Average Latency 371.91334ms
Throughput 133.69 requests/second

NANOTDF Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 25.88856496s
Average Latency 258.015674ms
Throughput 193.14 requests/second

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.833788ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

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

Standard Benchmark Metrics Skipped or Failed

Bulk Benchmark Results

Metric Value
Total Decrypts 100
Successful Decrypts 100
Failed Decrypts 0
Total Time 354.134822ms
Throughput 282.38 requests/second

TDF3 Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 37.845130886s
Average Latency 376.084426ms
Throughput 132.12 requests/second

NANOTDF Benchmark Results:

Metric Value
Total Requests 5000
Successful Requests 5000
Failed Requests 0
Concurrent Requests 50
Total Time 26.232592768s
Average Latency 261.630587ms
Throughput 190.60 requests/second

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp:db DB component comp:kas Key Access Server comp:policy Policy Configuration ( attributes, subject mappings, resource mappings, kas registry) docs Documentation size/m
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant