Skip to content

Conversation

@XJDKC
Copy link
Collaborator

@XJDKC XJDKC commented Apr 4, 2025

No description provided.

@XJDKC XJDKC requested a review from dennishuo as a code owner April 4, 2025 05:15
@ApplicationScoped
@Identifier("in-memory")
public class UnsafeInMemorySecretsManagerFactory implements UserSecretsManagerFactory {
private final Map<String, UserSecretsManager> cachedEntityManagers = new ConcurrentHashMap<>();

Choose a reason for hiding this comment

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

Rename cachedEntityManagers to cachedSecretsManagers

@dennishuo dennishuo merged commit fd7ae59 into dhuo-catalog-federation-mvp-clean Apr 4, 2025
1 of 2 checks passed
dennishuo added a commit that referenced this pull request May 7, 2025
…ST Catalogs (apache#1305)

* Initial prototype of catalog federation just passing special properties into internal properties.

Make Resolver federation-aware to properly handle "best-effort" resolution of
passthrough facade entities.

Targets will automatically reflect the longest-path that we happen to have stored
locally and resolve grants against that path (including the degenerate case
where the longest-path is just the catalog itself).

This provides Catalog-level RBAC for passthrough federation.

Sketch out persistence-layer flow for how connection secrets might be pushed
down into a secrets-management layer.

* Defined internal representation classes for connection config

* Construct and initialize federated iceberg catalog based on connection config

* Apply the same spec renames to the internal ConnectionConfiguration representations.

* Manually pick @XJDKC fixes for integration tests and omittign secrets in response objects

* Fix internal connection structs with updated naming from spec PR

* Push CreateCatalogRequest down to PolarisAdminService::createCatalog just like UpdateCatalogRequest in updateCatalog.

This is needed if we're going to make PolarisAdminService handle secrets management without ever putting the secrets
into a CatalogEntity.

* Add new interface UserSecretsManager along with a default implementation

The default UnsafeInMemorySecretsManager just uses an inmemory ConcurrentHashMap
to store secrets, but structurally illustrates the full flow of intended
implementations.

For mutual protection against a compromise of a secret store or the core
persistence store, the default implementation demonstrates storing only
an encrypted secret in the secret store, and a one-time-pad key in the
returned referencePayload; other implementations using standard crypto
protocols may choose to instead only utilize the remote secret store as
the encryption keystore while storing the ciphertext in the referencePayload
(e.g. using a KMS engine with Vault vs using a KV engine).

Additionally, it demonstrates the use of an integrity check by storing a
basic hashCode in the referencePayload as well.

* Wire in UserSecretsManager to createCatalog and federated Iceberg API handlers

Update the internal DPOs corresponding to the various ConnectionConfigInfo API objects
to no longer contain any possible fields for inline secrets, instead holding the
JSON-serializable UserSecretReference corresponding to external/offloaded secrets.

CreateCatalog for federated catalogs containing secrets will now first extract
UserSecretReferences from the CreateCatalogRequest, and the CatalogEntity will
populate the DPOs corresponding to ConnectionConfigInfos in a secondary pass
by pulling out the relevant extracted UserSecretReferences.

For federated catalog requests, when reconstituting the actual sensitive
secret configs, the UserSecretsManager will be used to obtain the secrets
by using the stored UserSecretReferences.

Remove vestigial internal properties from earlier prototypes.

* Since we already use commons-codec DigestUtils.sha256Hex, use that for the hash in UnsafeInMemorySecretsManager
just for consistency and to illustrate a typical scenario using a cryptographic hash.

* Rename the persistence-objects corresponding to API model objects with a new naming
convention that just takes the API model object name and appends "Dpo" as a suffix;

* Use UserSecretsManagerFactory to Produce the UserSecretsManager (#1)

* Move PolarisAuthenticationParameters to a top-level property according to the latest spec

* Create a Factory for UserSecretsManager

* Fix a typo in UnsafeInMemorySecretsManagerFactory

* Gate all federation logic behind a new FeatureConfiguration - ENABLE_CATALOG_FEDERATION

* Also rename some variables and method names to be consistent with prior rename to ConnectionConfigInfoDpo

* Change ConnectionType and AuthenticationType to be stored as int codes in persistence objects.

Address PR feedback for various nits and javadoc comments.

* Add javadoc comment to IcebergCatalogPropertiesProvider

* Add some constraints on the expected format of the URN in UserSecretReference and placeholders
for next steps where we'd provide a ResolvingUserSecretsManager for example if the runtime ever
needs to delegate to two different implementations of UserSecretsManager for different entities.

Reduce the `forEntity` argument to just PolarisEntityCore to make it more clear that the
implementation is supposed to extract the necessary identifier info from forEntity for
backend cleanup and tracking purposes.

---------

Co-authored-by: Rulin Xing <[email protected]>
Co-authored-by: Rulin Xing <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants