XJDKC commented on code in PR #2523: URL: https://github.com/apache/polaris/pull/2523#discussion_r2380604921
########## polaris-core/src/main/java/org/apache/polaris/core/identity/registry/ServiceIdentityRegistry.java: ########## @@ -0,0 +1,58 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +package org.apache.polaris.core.identity.registry; + +import java.util.Optional; +import org.apache.polaris.core.identity.ServiceIdentityType; +import org.apache.polaris.core.identity.dpo.ServiceIdentityInfoDpo; +import org.apache.polaris.core.identity.resolved.ResolvedServiceIdentity; + +/** + * A registry interface for managing and resolving service identities in Polaris. + * + * <p>In a multi-tenant Polaris deployment, each catalog or tenant may be associated with a distinct + * service identity that represents the Polaris service itself when accessing external systems + * (e.g., cloud services like AWS or GCP). This registry provides a central mechanism to manage + * those identities and resolve them at runtime. + * + * <p>The registry helps abstract the configuration and retrieval of service-managed credentials + * from the logic that uses them. It ensures a consistent and secure way to handle identity + * resolution across different deployment models, including SaaS and self-managed environments. + */ +public interface ServiceIdentityRegistry { + /** + * Discover a new {@link ServiceIdentityInfoDpo} for the given service identity type. Typically + * used during entity creation to associate a default or generated identity. + * + * @param serviceIdentityType The type of service identity (e.g., AWS_IAM). + * @return A new {@link ServiceIdentityInfoDpo} representing the discovered service identity. + */ + Optional<ServiceIdentityInfoDpo> discoverServiceIdentity(ServiceIdentityType serviceIdentityType); + + /** + * Resolves the given service identity by retrieving the actual credential or secret referenced by + * it, typically from a secret manager or internal credential store. + * + * @param serviceIdentityInfo The service identity metadata to resolve. + * @return A {@link ResolvedServiceIdentity} including credentials and other resolved data. + */ + Optional<ResolvedServiceIdentity> resolveServiceIdentity( + ServiceIdentityInfoDpo serviceIdentityInfo); Review Comment: `ResolvedServiceIdentity` = `ServiceIdentityInfoDpo` + actual service identity info (e.g., iam user arn) + credentials. The idea is: `ResolvedServiceIdentity` should contain all the info we need of a service identity. The idea is that `ResolvedServiceIdentity` should contain everything we need for a service identity. The child classes of `ResolvedServiceIdentity` would hold the service-identity–specific details. The flow is: 1. We discover a service identity of the type we need via `ServiceIdentityRegistry::discoverServiceIdentity`. That gives us a `ServiceIdentityInfoDpo`, which is essentially a reference to the service identity. 2. Later, we can use `ServiceIdentityInfoDpo` to fetch the full service identity info. With that, we can: * Inject the catalog entity to surface the service identity info (e.g., IAM User ARN). * Use its credentials to assume the role, fetch temporary credentials, and then use those temp creds to access the remote catalog. > Since discovery is driven by ServiceIdentityType add a new lookup / registry method for the credentials required for this identity driven by ServiceIdentityType I don't agree with this approach, for a few reasons: 1. Like I mentioned earlier on slack, some secret managers require the client to pass in a `ciphertext`, meaning we need to pass in a `SecretReference`. 3. What if the vendor decides to assign different service identities for different catalog entities, even within the same realm? In that case, `ServiceIdentityType` alone isn't sufficient. -- 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]
