-
Notifications
You must be signed in to change notification settings - Fork 1
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
Add new interfaces to support operations on nested credentials #29
Open
gouthamMN
wants to merge
9
commits into
main
Choose a base branch
from
gniranjan/nestedCred
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.
+528
−108
Open
Changes from all commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
8c444ae
add interfaces for nested credentials
gouthamMN 382bc8f
update unit tests
gouthamMN f929b46
New tests for nested credentials interfaces
gouthamMN db4c231
separate secret response types and make secret value non ptr
gouthamMN f6679b7
update UT to use cmp instead reflect
gouthamMN 777a30d
separate deleted secret response type
gouthamMN 94370d3
update UT to verify entire response
gouthamMN 4f436ae
update integration test
gouthamMN be6d299
bind to this using
gouthamMN 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
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.
Unless this method and its siblings is adding some value for the caller - e.g. taking in the credentials object and calculating the storage path - we should omit the method entirely.
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 agree with your point, but since the
kvClient
is private and won't be able to access outside thestore
package this might have to be redesigned altogether. I think original author of this was @carvalhe and tagging him here to understand the rationale behind this.@stevekuznetsov - So, If I understand your ask properly then the possible solution is to make
kvClient
a public as this would let the client to directly access KV interface methods. But with this we might introduce inconsistency in the way we let the client access our methods.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 all of the users of this library will need to impose some keyvault key naming convention by which a specific credential or nested credential can be stored and retrieved by knowing only some identifying characteristics of the MSI. I imagine both the refresher and the
clusters-service
will furthermore need to agree on this pattern. We can either omit the storage piece from this library and leave it up to the end-clients or we can add value to the storage piece by amending our interfaces not to act over opaquesecretName
s.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.
This approach needs to be discussed with RH as this will impact Classic MIWI clusters changes.
Is the ask is to create a separate interface for cred obj and nested cred obj? eg:
DeleteCredentialsObject()
&DeleteNestedCredentialsObject()
?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.
Let's see how the clients use the library and decide what makes the most sense for the interface.
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.
For MIWI classic, we're currently doing exactly what @stevekuznetsov described in an earlier comment; we impose a naming convention for the KV keys by using a utility function that takes in the cluster doc and returns the secret name, call the utility function to get the name, and then delete by name: https://github.com/Azure/ARO-RP/blob/b534984ce591b208ded342d8e1538f1fce69d837/pkg/cluster/delete.go#L372
In classic we only need to delete
CredentialsObjects
and notNestedCredentialsObjects
though. Maybe someone from HCP would be able to provide more valuable input here.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.
Do we ever use the result of the deletion call? I would assume not because the backing credential is actually deleted.
For HCP, CS wanted to prefix the secret name with either
nco
orco
representing nested credential object and credential object respectively.ARO Classic is storing the raw credentials object with the below contents, where the docID is a guid and the name is the name of the resource ID of the managed identity.
Do we need to force consistent naming across the two, or can we have the refresher and ARO HCP (cluster service) leverage
nco
and assume everything else is a credentials object? Also is there any way to abstract the deletion to exist for both types and the response is either just a string or we don't care about it?If we'd like consistent prefix/suffix across 3 repos (cluster service, aro classic, and msi refresher) should we move the naming prefix into this library and return the secret name back, or do we not care as a client?
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.
That is my question. I assumed the answer was yes - please provide your opinions :)