-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move secret validation logic and authN-loadPrincipal into PolarisSecretsManager
#511
Open
snazy
wants to merge
1
commit into
apache:main
Choose a base branch
from
snazy:move-secret-validation-logic
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+143
−46
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -23,8 +23,10 @@ | |
import jakarta.annotation.Nonnull; | ||
import jakarta.annotation.Nullable; | ||
import org.apache.polaris.core.PolarisCallContext; | ||
import org.apache.polaris.core.entity.PolarisBaseEntity; | ||
import org.apache.polaris.core.entity.PolarisPrincipalSecrets; | ||
import org.apache.polaris.core.persistence.BaseResult; | ||
import org.apache.polaris.core.persistence.PolarisMetaStoreManager.EntityResult; | ||
|
||
/** Manages secrets for Polaris principals. */ | ||
public interface PolarisSecretsManager { | ||
|
@@ -39,6 +41,17 @@ public interface PolarisSecretsManager { | |
PrincipalSecretsResult loadPrincipalSecrets( | ||
@Nonnull PolarisCallContext callCtx, @Nonnull String clientId); | ||
|
||
@Nonnull | ||
SecretValidationResult validateSecret( | ||
@Nonnull PolarisCallContext callCtx, @Nonnull String clientId, @Nonnull String clientSecret); | ||
|
||
@Nonnull | ||
EntityResult loadPrincipal( | ||
@Nonnull PolarisCallContext callCtx, | ||
@Nullable String roleName, | ||
@Nullable String clientId, | ||
@Nullable Long principalId); | ||
|
||
/** | ||
* Rotate secrets | ||
* | ||
|
@@ -100,4 +113,34 @@ public PolarisPrincipalSecrets getPrincipalSecrets() { | |
return principalSecrets; | ||
} | ||
} | ||
|
||
/** the result of load/rotate principal secrets */ | ||
class SecretValidationResult extends BaseResult { | ||
|
||
private final PolarisBaseEntity principal; | ||
|
||
public SecretValidationResult( | ||
@Nonnull BaseResult.ReturnStatus errorCode, @Nullable String extraInformation) { | ||
super(errorCode, extraInformation); | ||
this.principal = null; | ||
} | ||
|
||
public SecretValidationResult(@Nonnull PolarisBaseEntity principal) { | ||
super(BaseResult.ReturnStatus.SUCCESS); | ||
this.principal = principal; | ||
} | ||
|
||
@JsonCreator | ||
private SecretValidationResult( | ||
@JsonProperty("returnStatus") @Nonnull BaseResult.ReturnStatus returnStatus, | ||
@JsonProperty("extraInformation") @Nullable String extraInformation, | ||
@JsonProperty("principalSecrets") @Nonnull PolarisBaseEntity principal) { | ||
super(returnStatus, extraInformation); | ||
this.principal = principal; | ||
} | ||
|
||
public PolarisBaseEntity getPrincipal() { | ||
return principal; | ||
} | ||
Comment on lines
+142
to
+144
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same comment on returning the principal from the secret validation command. I can imagine storing extra metadata, such as the principal id with the client id / secret, but the entity itself should be returned from the persistence layer. |
||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Loading the principal entity should be the purview of the persistence layer, not the secrets manager. IMO, the secrets manager should be something like Vault or AWS Secrets manager that knows nothing about Polaris entities, but does know how to store client id / secret
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is: effectively only the secrets manager knows which attributes it has at hand, correct?
Currently, it's the principal-ID, which is another unique ID in the JWT - but it should rather be just the client-ID. But that's currently hard to refactor, because the data model details leak all the way up. That's why #512 is there as an immediate follow-up.
TL;DR this PR is one of a series of upcoming PRs to untangle the hard dependency of all the services on the data model details/internals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Vault, Secrets Manager, and K8s all allow storing secret values as structured types, like JSON. I think it's pretty easy to imagine a layout like using the
clientId
as the secret key and storing the secret value as something like{"secret": "abcd", "principalId": 1}
. This allows full decoupling of the PolarisSecretsManager from the PolarisMetaStoreManager, whereas returning thePrincipalEntity
from thePolarisSecretsManager
means it has to maintain a reference to the MetaStore and the MetaStore has to deal with lookup keys beside name and id. No other entity has a lookup key beside name or id, so I think keeping it consistent for Principal makes sense.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue here is: there are currently two lookup keys: client-ID and principal-ID. Client-ID is the natural key, so I think that we should only use that one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think, the assumption that Polaris is the source-of-truth for principals is not correct. Principals/identities are usually managed elsewhere. It would be difficult to force people to add a principal-ID as a new attribute to new or existing identities. On top, principal-ID is an internal concern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The secrets manager is only used for Polaris-managed Principals. There's no need to manage secrets for externally managed Principals. I think the assumption that Polaris is authoritative here is a safe one