-
Notifications
You must be signed in to change notification settings - Fork 63
Conversation
Although this doesn't seem to be required, it is better to do things according to API doc.
This will make sure only the `signingPrincipal` needs readonly permission on the object instead of the service account associated with flyteadmin.
This is because of introducing of google.golang.org/protobuf
Codecov Report
@@ Coverage Diff @@
## master #121 +/- ##
==========================================
- Coverage 62.39% 62.24% -0.16%
==========================================
Files 104 105 +1
Lines 7752 7840 +88
==========================================
+ Hits 4837 4880 +43
- Misses 2345 2385 +40
- Partials 570 575 +5
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
@@ -46,8 +46,8 @@ var compiledTaskDigest = []byte{ | |||
0xa, 0x22, 0x80, 0xb1, 0x8, 0x44, 0x53, 0xf3, 0xca, 0x60, 0x4, 0xf7, 0x6f} | |||
|
|||
var compiledWorkflowDigest = []byte{ | |||
0x1c, 0x66, 0x45, 0x89, 0x8f, 0x5, 0xa5, 0x4f, 0xf5, 0xba, 0x6f, 0xd9, 0xd, 0x70, 0xf6, 0x86, 0xf, 0x8e, 0x7e, 0x1b, | |||
0x80, 0x1d, 0xb9, 0x59, 0xe, 0x3, 0x50, 0x4d, 0x64, 0xeb, 0x13, 0xa2} | |||
0xeb, 0x66, 0x44, 0xe8, 0x1c, 0xa8, 0x51, 0x7d, 0x3f, 0x33, 0xf0, 0x77, 0x95, 0x24, 0x84, 0xc2, 0xbe, 0x79, 0xcd, |
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 is due to introducing of google.golang.org/protobuf
as transitive dependency.
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.
interesting, @katrogan will this affect all existing digests to be invalidated, should be fine, but we might cause some re-registrations?
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 is where I most concerned about as well. I can dig a bit further to see whether this can be avoided.
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.
oh interesting! this could be a problem because some folks will get a warning about the digest changing for a workflow with the same identifier, so they will have to change the version parameter to reregister - which is unfortunate
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 managed to revert this change by downgrading a few deps, in latest commit. Still we will need to face this thing later: #121 (comment)
@@ -45,6 +46,12 @@ func GetRemoteDataHandler(cfg RemoteDataHandlerConfig) RemoteDataHandler { | |||
return &remoteDataHandler{ | |||
remoteURL: implementations.NewAWSRemoteURL(awsConfig, presignedURLDuration), | |||
} | |||
case common.GCP: |
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.
@katrogan / @honnix with the new change to return the entire data as part of the getData API, we should probably think of making signing optional (we have to keep it around to ensure that very large datasets can still be served). By optional I mean, that if it is not specified, the signing should just be skipped.
I do not think my comment needs to be added as part of this commit, but as a follow up? @katrogan what do you think?
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.
yeah that was what i had in the original idl pr - adding a mode to specify what data we want returned and making only the signed url a non-default option. returning the signed url data optionally sounds good to me
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.
One comment, but LGTM
codes.Internal, "failed to get object size for %s with %v", uri, err) | ||
} | ||
|
||
// The second return argument here is the GetObjectOutput, which we don't use below. |
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: is this comment relevant?
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.
Oops, sorry. Copy pasta. Will fix.
} | ||
|
||
type gcsClientWrapper struct { | ||
delegate *gcs.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.
hey @honnix I'm not super familiar with the delegate pattern, what's the reason for using it 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.
is this so you can mock out the bucket like you commented below?
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.
Yes. That is the only way I could figure out how to test this fluid API.
SignBytes: func(b []byte) ([]byte, error) { | ||
req := &credentialspb.SignBlobRequest{ | ||
Payload: b, | ||
Name: "projects/-/serviceAccounts/" + g.signingPrincipal, |
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.
what's the meaning of this string prefix?
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.
It's a GCP resource name: https://cloud.google.com/iam/docs/reference/rest/v1/projects.serviceAccounts/signBlob
Basically, it means the service account
in some GCP project (-
) that doesn't matter.
@@ -3,6 +3,8 @@ module github.com/lyft/flyteadmin | |||
go 1.13 | |||
|
|||
require ( | |||
cloud.google.com/go v0.56.0 |
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 is the last version staying on protobuf v1.3.5. Since v1.4.0, github.com/golang/protobuf
started to depend on google.golang.org/protobuf
: https://github.com/golang/protobuf/blob/v1.4.0/ptypes/timestamp/timestamp.pb.go#L9
So sooner or later we will need to face this issue again.
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.
oh this is awesome, thank you for finding it
* signed GCS URL Impersonate the signingPrincipal to get object attributes and sign the GCS URL This will make sure only the `signingPrincipal` needs readonly permission on the object instead of the service account associated with flyteadmin.
TL;DR
Add support of signed GCS URL.
This is a continuation of #81 because CI doesn't seem to work in forked repo.
Type
Are all requirements met?
Complete description
Right now only AWS/S3 presigned URL is support. This PR adds support for GCS URL.
The signing part looks a bit funky, mainly due to GCP lib does not support signing URL without
materialised service account key. So this PR uses https://cloud.google.com/iam/docs/reference/credentials/rest/v1/projects.serviceAccounts/signBlob directly.
SigningPrincipal
refers to the service account that signs the URL, as well as reads object size. Service account associated with flyteadmin instance needs to have the role on the principal.Tracking Issue
Follow-up issue
NA