XJDKC opened a new pull request, #2523:
URL: https://github.com/apache/polaris/pull/2523
<!--
Possible security vulnerabilities: STOP here and contact
[email protected] instead!
Please update the title of the PR with a meaningful message - do not
leave it "empty" or "generated"
Please update this summary field:
The summary should cover these topics, if applicable:
* the motivation for the change
* a description of the status quo, for example the current behavior
* the desired behavior
* etc
PR checklist:
- Do a self-review of your code before opening a pull request
- Make sure that there's good test coverage for the changes included in
this PR
- Run tests locally before pushing a PR (./gradlew check)
- Code should have comments where applicable. Particularly
hard-to-understand
areas deserve good in-line documentation.
- Include changes and enhancements to the documentation (in
site/content/in-dev/unreleased)
- For Work In Progress Pull Requests, please use the Draft PR feature.
Make sure to add the information BELOW this comment.
Everything in this comment will NOT be added to the PR description.
-->
## Milestones
This is Part 3 of the [[Splitting] Initial SigV4 Auth Support for Catalog
Federation](https://github.com/apache/polaris/pull/1805). Upcoming parts will
build on this system:
* ~~#1899~~
* #2190
* SigV4 Auth Support for Catalog Federation - Part 3: Service Identity Info
Injection
* SigV4 Auth Support for Catalog Federation - Part 4: Connection Credential
Manager
## Introduction
This PR introduces the service identity injeciton logic. The service
identity info shouldn't be provided by polaris users but polaris itself. It
represents the identity of polaris service.
This PR introduces a `ServiceIdentityRegistry` to provide this ability (we
can rename it with a better name if needed, e.g. ServiceIdentityProvider).
Basically it has two operations
* Assigning a service identity to a catalog entity
* The vendor can choose to assign the same service identity across the
same account
* The vendor can also choose to assign different service identity to
different catalog entitys
* The DPO will contain a reference to the service identity.
* Resolving a service identity based on a service identity reference
* When generating response of `getCatalog` api, we need to resolve the the
service identity to get the full info of the identity, take AWS IAM for
example, we need to get the iam user arn
* When accessing the remote catalog, we also need to resolve the service
identity, this includes the aws credential of the iam user.
* After polaris get the iam user credential, polaris can assume the
customer-provided iam role to get the aws temp credentials, then accessing the
remote catalog by using SigV4 protocol.
This PR also introduces a `DefaultServiceIdentityRegistry`, basically it
allows customers to have some static configs stored in the
`applications.properties`. Although it doesn't provide the ability to
request/resolve a service identity during the runtime (all the identities must
be specified in advance before the server start). It provides a very useful and
easy way to test SigV4 auth which can act as a implementation reference. We can
add a dynamic service identity registry later if needed (vendor can also
implement their own dynamic service identity registry based on their internal
infra).
## Design Overview
Each `ConnectionConfigInfoDpo` (used for remote catalog federation) now
contains a `ServiceIdentityInfoDpo`, which in turn holds a
`ServiceSecretReference`. This design allows:
* Polaris to store only references to its service identity (e.g. AWS IAM
user)
* The actual credentials to be stored securely in a vault or secret manager
* Runtime resolution of credentials based on these references
* Role assumption using `SigV4AuthenticationParametersDpo` (supplied by the
user)
ServiceIdentityRegistry will be responsible for assigning a service identity
to the catalog entity.
## Key Components
* `ServiceIdentityRegistry`: Central registry responsible for:
* Assigning a service identity to a catalog entity.
* Resolving a service identity reference at runtime.
* `DefaultServiceIdentityRegistry`: The default implementation
(`DefaultServiceIdentityRegistry`) supports static configuration in
`application.properties` (useful for testing). Vendors may extend this with
dynamic backends (e.g., integrating with an internal identity system).
## Flowchart
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
