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
Update Azure SDK and support additional authentication schemes #3839
Conversation
Thanks, this is awesome! Couple of things:
|
@milosgajdos oh sure, apologies I was thinking I should have split them out, my bad. appreciate you taking a look. |
0b207b5
to
263bf0c
Compare
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, |
263bf0c
to
7bae9ab
Compare
sorry I accidentally assumed gpg signing was the requirement, now properly signed off and go fmt run. Apologies. |
7bae9ab
to
9341366
Compare
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.
Can we group direct and indirect dependencies into their dedicated required
stanzas? We have like 4 groups in go.mod
now
9341366
to
7b7d77d
Compare
@milosgajdos good point, done. |
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. |
@kirat-singh can you rebase |
Codecov ReportPatch coverage:
📣 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
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. |
Seems like this would fix these?
|
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. |
No, this is fine. This will take me a bit of time to review as I'm not familiar with Azure API and SDK 😓 |
@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 🤔 |
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) |
accountName string | ||
container string | ||
serviceURL string |
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.
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.
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.
duh, sorted
} | ||
info := blobRef.Properties | ||
size := info.ContentLength | ||
size := *props.ContentLength |
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.
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
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, 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.
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.
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?
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.
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.
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 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.
@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. |
49ab310
to
88ef150
Compare
@kirat-singh can you sign your commit, please |
88ef150
to
c62551a
Compare
@milosgajdos oops, sorry I keep forgetting! done. |
@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. |
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 we are almost there. Just have a few comments
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.
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.
UdcGracePeriod = 30.0 * time.Minute | ||
UdcExpiryTime = 48.0 * time.Hour |
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.
Nit: https://github.com/golang/go/wiki/CodeReviewComments#initialisms
UdcGracePeriod = 30.0 * time.Minute | |
UdcExpiryTime = 48.0 * time.Hour | |
UDCGracePeriod = 30.0 * time.Minute | |
UDCExpiryTime = 48.0 * time.Hour |
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.
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.
4bfce34
to
0c703ef
Compare
Hi, sorry to chase, but I've made all the requested changes. |
Ping @corhere |
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.
Almost there!
} | ||
info := blobRef.Properties | ||
size := info.ContentLength | ||
size := *props.ContentLength |
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 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) |
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.
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
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.
Ping @kirat-singh – this error string also needs updating
@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. |
63cf8ea
to
8df98b5
Compare
@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>
8df98b5
to
ba4a6bb
Compare
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.
LGTM!
Awesome work @kirat-singh |
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.