Skip to content

Ensure new links are rendered in web#1

Merged
eric-maynard merged 1 commit intoeric-maynard:configuring-polaris-for-productionfrom
apache:configuring-polaris-for-production
Aug 1, 2024
Merged

Ensure new links are rendered in web#1
eric-maynard merged 1 commit intoeric-maynard:configuring-polaris-for-productionfrom
apache:configuring-polaris-for-production

Conversation

@annafil
Copy link

@annafil annafil commented Aug 1, 2024

Hey Eric,

Did a quick pass to make sure that the web docs are also updated and include your changes using the instructions here :)

Can we merge this in before we merge in your PR on the main repo? 🙏

@eric-maynard eric-maynard merged commit 06699c3 into eric-maynard:configuring-polaris-for-production Aug 1, 2024
eric-maynard pushed a commit that referenced this pull request Dec 12, 2024
* Adds a ForeignTableEntity and Subtype

* Add JavaDoc for _source Parameter
eric-maynard pushed a commit that referenced this pull request Apr 18, 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 <rulin.xing+oss@snowflake.com>
Co-authored-by: Rulin Xing <xjdkcsq3@gmail.com>
@snazy snazy deleted the configuring-polaris-for-production branch June 16, 2025 13:52
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.

3 participants