core: Credential Vending Refactor #3699
Conversation
| } | ||
|
|
||
| @Override | ||
| public @Nonnull ScopedCredentialsResult getSubscopedCredsForEntity( |
There was a problem hiding this comment.
While I agree that this change makes sense in general, polaris-core is traditionally sensitive to API changes (despite the standing evolution guidelines).
I'd propose to keep this method for now, even if it will be unused in OSS code.
There was a problem hiding this comment.
The NoSQL impl. can be replaced with a throw new UnsupportedOperationException(), but let's keep related code in polaris-core.
| Supplier<StorageAccessConfig> loader) { | ||
| long maxCacheDurationMs = maxCacheDurationMs(realmConfig); | ||
| return cache | ||
| .get( |
There was a problem hiding this comment.
The Supplier in this .get method in Caffeine is supposed to be fast, but I believe in our case it may hit network (e.g. STS), which is not desirable... It might be best to go back to LoadingCache, which allows loaders to be blocking.
| key, | ||
| k -> { | ||
| LOGGER.atDebug().log("StorageCredentialCache::load"); | ||
| StorageAccessConfig accessConfig = loader.get(); |
There was a problem hiding this comment.
Ideally, I think this should be something like loader.get(key). That is to ensure we produce StorageAccessConfig from exactly the same data that is used as the cache key, i.e. any change in key results in regeneration of StorageAccessConfig and any two StorageAccessConfig objects are logically equivalent if their keys match. WDYT?
2 participants
StorageCredentialCacheby moving orchestration logic intoStorageAccessConfigProviderbuildCacheKeytoPolarisStorageIntegrationProviderinterface so each storage backend (AWS, GCP, Azure) controls which fields are included in its cache key (e.g., only AWS includes principal name and session tags). non-AWS backends no longer include principal name and session tags in cache key.getSubscopedCredsForEntityfromPolarisMetaStoreManagerimplementations (AtomicOperation, Transactional, NoSql) — credential vending now goes through the standalonePolarisCredentialVendorImplPolarisCredentialVendorto acceptPolarisEntitydirectly instead of entity IDs. This is to avoid having to rematerialize PolarisEntity that is already available.