Skip to content
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

Update Azure SDK and support additional authentication schemes #3839

Merged
merged 1 commit into from Apr 25, 2023

Conversation

kirat-singh
Copy link
Contributor

Microsoft has updated the golang Azure SDK significantly. Update the azure storage driver to use the new SDK. Add support for client secret and MSI authentication schemes in addition to shared key authentication.

Implement rootDirectory support for the azure storage driver to mirror the S3 driver.

Also support AWS_CA_BUNDLE for the S3 driver.

@milosgajdos
Copy link
Member

Thanks, this is awesome! Couple of things:

  1. Can we please split the S3 change from the Azure SDK change into separate PR
  2. Can you make sure you signed every commit as per the contributor guidelines

@kirat-singh
Copy link
Contributor Author

@milosgajdos oh sure, apologies I was thinking I should have split them out, my bad. appreciate you taking a look.

@kirat-singh
Copy link
Contributor Author

Hello,

This is done. I split out the AWS_CA_BUNDLE change into a separate pull request. Amended this commit, and signed it.

Appreciate your help.

best,
-Kirat

@kirat-singh
Copy link
Contributor Author

sorry I accidentally assumed gpg signing was the requirement, now properly signed off and go fmt run. Apologies.

Copy link
Member

@milosgajdos milosgajdos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we group direct and indirect dependencies into their dedicated required stanzas? We have like 4 groups in go.mod now

@kirat-singh
Copy link
Contributor Author

@milosgajdos good point, done.

@kirat-singh
Copy link
Contributor Author

Hi, I see there's a CodeQL warning which seems to have nothing to do with my change. Not quite sure what I can do to address it.

@milosgajdos
Copy link
Member

@kirat-singh can you rebase

@codecov-commenter
Copy link

codecov-commenter commented Feb 27, 2023

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (e5d5810) 56.58% compared to head (6f15461) 56.58%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #3839   +/-   ##
=======================================
  Coverage   56.58%   56.58%           
=======================================
  Files         105      105           
  Lines       10636    10636           
=======================================
  Hits         6018     6018           
  Misses       3946     3946           
  Partials      672      672           
Impacted Files Coverage Δ
registry/storage/driver/storagedriver.go 0.00% <ø> (ø)
registry/storage/blobwriter.go 33.33% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

@milosgajdos
Copy link
Member

@kirat-singh
Copy link
Contributor Author

kirat-singh commented Feb 27, 2023

yes looks like those would be resolved. and if you prefer I split out the rootdirectory changes, I'm happy to do so. I really care about the azure auth changes since the existing mechanism is very insecure. It requires you to expose your account key to the registry. This is basically impossible to revoke so it's a really bad idea to distribute it in any way. The token based auth and secret based auth is much much better.

@milosgajdos
Copy link
Member

No, this is fine. This will take me a bit of time to review as I'm not familiar with Azure API and SDK 😓

@milosgajdos
Copy link
Member

@kirat-singh not sure what CodQL's problem here is but it seems to have a beef with this PR 😬 I only skimmed through it -- it seems to be crying about logging user-provided values in parts of codebase that havent been touched for ages 🤔

@milosgajdos
Copy link
Member

I will close this PR and reopen because I suspect during the original CI run CodeQL had a bit of a fit. Let's see if re-triggering the build does the trick (CodeQL folks reported a bug that was accidentally pushed out last week)

registry/storage/driver/azure/parser.go Outdated Show resolved Hide resolved
registry/storage/driver/azure/azure_auth.go Outdated Show resolved Hide resolved
registry/storage/driver/azure/azure_auth.go Outdated Show resolved Hide resolved
Comment on lines 28 to 30
accountName string
container string
serviceURL string
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neither the accountName nor serviceURL fields are accessed. It looks like the values which are assigned to these fields are needed to construct cred and client, but are not needed afterwards.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

duh, sorted

registry/storage/driver/azure/azure_auth.go Outdated Show resolved Hide resolved
docs/configuration.md Outdated Show resolved Hide resolved
}
info := blobRef.Properties
size := info.ContentLength
size := *props.ContentLength
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
size := *props.ContentLength
size := props.ContentLength

FYI: the . field-access operator behaves like the -> operator in the C-family languages when applied to a pointer. Pretty much the only time a pointer-to-struct needs to be explicitly dereferenced is when you want to make a shallow copy. E.g.:

copied := *original

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, but in this case ContentLength itself is a pointer to an int64. Go figure. The azure apis are just horrible. So I left it as is.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, I naively assumed that ContentLength was a scalar without checking the GoDoc.

In idiomatic Go, pointer-to-scalar arguments and fields are often used as a poor man's Option<T> when unset needs to be distinguished from zero. How can we be certain that ContentLength is guaranteed to be != nil? Do we need an if props.ContentLength != nil guard to avoid dereferencing nil?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @corhere, I added defensive checks around these, please let me know if that's reasonable. Honestly I think these are required properties and don't think they can be nil unless there's some serious failure on the azure level, but agree that it's good to guard against.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with all your points @kirat-singh. Returning an error if a property required by the storage driver is missing from the azure API response is much more reasonable than panicking.

registry/storage/driver/azure/azure.go Outdated Show resolved Hide resolved
registry/storage/driver/azure/azure.go Show resolved Hide resolved
registry/storage/driver/azure/azure.go Outdated Show resolved Hide resolved
@kirat-singh
Copy link
Contributor Author

@corhere thank you for the review, I made changes as you suggest. Sorry for the delay, I was a bit busy last week with other stuff.

@milosgajdos
Copy link
Member

@kirat-singh can you sign your commit, please

@kirat-singh
Copy link
Contributor Author

@milosgajdos oops, sorry I keep forgetting! done.

@kirat-singh
Copy link
Contributor Author

@corhere and pushed a final change with some more fixes. for some reason github had 3 'hidden' conversations. I replied to your comments, but did not resolve them. Let me know if you want me to change anything else.

Copy link
Member

@milosgajdos milosgajdos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we are almost there. Just have a few comments

registry/storage/driver/azure/azure.go Outdated Show resolved Hide resolved
registry/storage/driver/azure/azure.go Show resolved Hide resolved
registry/storage/driver/azure/azure.go Show resolved Hide resolved
registry/storage/driver/azure/parser.go Outdated Show resolved Hide resolved
registry/storage/driver/storagedriver.go Show resolved Hide resolved
Copy link
Collaborator

@corhere corhere left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, aside from a style nitpick and a follow-up question regarding dereferencing pointer-typed struct fields in the Azure API responses. (Repeated here for visibility: what guarantees do we have that the fields which are unconditionally dereferenced will always be != nil?)

Please squash down the merge and "chore: address feedback" commits to get this PR ready to merge.

Comment on lines 18 to 19
UdcGracePeriod = 30.0 * time.Minute
UdcExpiryTime = 48.0 * time.Hour
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: https://github.com/golang/go/wiki/CodeReviewComments#initialisms

Suggested change
UdcGracePeriod = 30.0 * time.Minute
UdcExpiryTime = 48.0 * time.Hour
UDCGracePeriod = 30.0 * time.Minute
UDCExpiryTime = 48.0 * time.Hour

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed style nitpick. Squashed down commits.

I poked around the Azure APIs, the pointers seem to be an artifact of the code generator they use for the API bindings.
There's some internal code there that parses response headers and sets these pointers if the corresponding headers are present.

So I suppose it is possible that they can be nil. I added a bunch of defensive checks around them.

@kirat-singh kirat-singh force-pushed the feature.azure-sdk-update branch 2 times, most recently from 4bfce34 to 0c703ef Compare April 20, 2023 21:18
@kirat-singh
Copy link
Contributor Author

Hi, sorry to chase, but I've made all the requested changes.

@milosgajdos
Copy link
Member

Ping @corhere

Copy link
Collaborator

@corhere corhere left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost there!

}
info := blobRef.Properties
size := info.ContentLength
size := *props.ContentLength
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with all your points @kirat-singh. Returning an error if a property required by the storage driver is missing from the azure API response is much more reasonable than panicking.

info := blobRef.Properties
size := info.ContentLength
if props.ContentLength == nil {
return nil, fmt.Errorf("Failed to get ContentLength for path: %s", path)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return nil, fmt.Errorf("Failed to get ContentLength for path: %s", path)
return nil, fmt.Errorf("failed to get ContentLength for path: %s", path)

https://github.com/golang/go/wiki/CodeReviewComments#error-strings

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ping @kirat-singh – this error string also needs updating

registry/storage/driver/azure/azure.go Outdated Show resolved Hide resolved
registry/storage/driver/azure/azure.go Outdated Show resolved Hide resolved
registry/storage/driver/azure/azure.go Show resolved Hide resolved
@milosgajdos
Copy link
Member

@kirat-singh when you accept commit suggestions Github doesnt propagate git signatures, so you'll have to rebase and sign. I know it's silly and has been raised with GH on gazillion occasions to no avail.

@kirat-singh kirat-singh force-pushed the feature.azure-sdk-update branch 2 times, most recently from 63cf8ea to 8df98b5 Compare April 25, 2023 16:47
@kirat-singh
Copy link
Contributor Author

@milosgajdos thanks! noticed that. squashed, signed, committed. Thanks @corhere as well.

Microsoft has updated the golang Azure SDK significantly.  Update the
azure storage driver to use the new SDK.  Add support for client
secret and MSI authentication schemes in addition to shared key
authentication.

Implement rootDirectory support for the azure storage driver to mirror
the S3 driver.

Signed-off-by: Kirat Singh <kirat.singh@beacon.io>

Co-authored-by: Cory Snider <corhere@gmail.com>
Copy link
Collaborator

@corhere corhere left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@milosgajdos milosgajdos merged commit 2fb8dbd into distribution:main Apr 25, 2023
12 checks passed
@milosgajdos
Copy link
Member

Awesome work @kirat-singh

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.

None yet

4 participants