feat: Support querying S2A Addresses from MDS #1400
Conversation
rmehta19
force-pushed
the
s2a-java-integration
branch
from
0f96e86 to
ddac7aa
Compare
|
cc: @xmenxk |
|
|
@westarle, friendly ping :). Please review when you get a chance. |
There was a problem hiding this comment.
Thanks for working with us to address the comments. I think this mostly looks good to me given the context.
Can you also do two additional things:
- Run
mvn fmt:formaton this PR? - Update the title to be
feat: {title}? Something that describes the functionalityfeat: Support querying S2A Addresses from MDSor whatever you think aptly describes it.
rmehta19
changed the title
|
@lqiu96 , I've addressed your latest round of comments -- thanks for the feedback! Run mvn fmt:format on this PR?
Update the title to be feat: {title}? Something that describes the functionality feat: Support querying S2A Addresses from MDS or whatever you think aptly describes it.
|
| transportFactory.transport.setS2AContentMap( | ||
| "plaintextS2AAddressJsonKey", S2A.S2A_PLAINTEXT_ADDRESS_JSON_KEY); | ||
| transportFactory.transport.setS2AContentMap("plaintextS2AAddress", S2A_PLAINTEXT_ADDRESS); | ||
| transportFactory.transport.setS2AContentMap( | ||
| "mtlsS2AAddressJsonKey", S2A.S2A_MTLS_ADDRESS_JSON_KEY); | ||
| transportFactory.transport.setS2AContentMap("mtlsS2AAddress", S2A_MTLS_ADDRESS); |
There was a problem hiding this comment.
Ah, I was going to suggest something like:
For valid data:
transportFactory.transport.setS2AContentMap(
ImmutableMap.of(S2A.S2A_PLAINTEXT_ADDRESS_JSON_KEY, S2A_PLAINTEXT_ADDRESS,
S2A.S2A_MTLS_ADDRESS_JSON_KEY, S2A_MTLS_ADDRESS));
For invalid data:
transportFactory.transport.setS2AContentMap(
ImmutableMap.of(INVALID_JSON_KEY, S2A_PLAINTEXT_ADDRESS,
S2A.S2A_MTLS_ADDRESS_JSON_KEY, S2A_MTLS_ADDRESS));
And the content would be populated via iteration through tkey k/v's of the map. Something like:
if (requestStatusCode == 200) {
for (Map.Entry<String, String> entrySet: content.entrySet()) {
content.put(entrySet.getKey(), entrySet.getValue())
}
}
There was a problem hiding this comment.
This is more succinct -- thanks. Done in 1e6c058
| return new Builder(); | ||
| } | ||
|
|
||
| public String getPlaintextAddress() { |
There was a problem hiding this comment.
I'd like Javadocs for all these public things, pointing to public docs for MDS.
There was a problem hiding this comment.
We don't have this documented in public MDS docs (e.g. https://cloud.google.com/compute/docs/metadata/predefined-metadata-keys). We do have an AIP: https://google.aip.dev/auth/4115 which discusses this autconfig endpoint and how it fits in the mTLS via S2A + bound tokens story. WDYT about 934679c?
There was a problem hiding this comment.
Please include the documentation for each public method here. The AIP isn't a great landing place -- can you please look into improving the public MDS docs at least with a bug to the metadata service team?
There was a problem hiding this comment.
Done in 8ca8d69
The AIP isn't a great landing place -- can you please look into improving the public MDS docs at least with a bug to the metadata service team?
Agreed that public MDS docs will need to be updated to document this auto-mtls-configuration MDS endpoint that is being queried to learn where S2A is running. The endpoint is currently still experimental. I created a bug to track this internally, will share it with you in our meeting later today.
| OAuth2Utils.validateString( | ||
| responseData, S2A_PLAINTEXT_ADDRESS_JSON_KEY, PARSE_ERROR_S2A); | ||
| } catch (IOException ignore) { | ||
| } |
There was a problem hiding this comment.
Can you add comment on why these are ignored?
There was a problem hiding this comment.
I added a comment in 6644d50. In general, if there is any error in this function, we ignore, and populate empty addresses in the S2AConfig.
| HttpResponse response = request.execute(); | ||
| InputStream content = response.getContent(); |
There was a problem hiding this comment.
maybe do try/catch block around these to be more specific about the exceptions catching? Nested try/catch blocks are a bit hard to read.
There was a problem hiding this comment.
Ah, I think I was the one that suggested this, but am open to having the try-catch blocks be more specific or a different implementation.
I suggested just have one try-catch block since this code doesn't catch or return the error message back to the user. It just catches any IO error and returns an empty S2AConfig back. Unfortunately, this doesn't provide any useful feedback to the user. Given that this is how it behaves already in Go, I thought it would just be simpler to have a catch-all (one big try block) for this logic.
Ideally, we would have more specific try-catch blocks which could tell the user exactly what went wrong (i.e. failed to build the request because x, or the request failed because of y).
I believe there are two spots where we potentially would need to add try-catches:
- parseAs (Ah, thanks for the correction below)
- request.execute()
There was a problem hiding this comment.
There are a few places in this block that throw an IOException (the parseAs and buildGetRequest also throw IOException), so I removed the current nested try/catch block structure and added two separate try/catch blocks around the lines that throw an exception. Because we are getting rid of the big block, I also moved around variable definitions closer to where they are used.
There was a problem hiding this comment.
@lqiu96 , I think my changes and your comment happened at same time. Reading through your comment, the changes I just push match your suggestion. I removed the big try/catch and just did 2 smaller ones around building the request and executing it.
@zhumin8 , @lqiu96: I am fine with either option -- let me know if you prefer reverting to the 1 big/try catch block, or if you prefer the current state which has no nesting, but a few smaller try/catch blocks
There was a problem hiding this comment.
I am fine with splitting it up to reduce nesting.
|
…port (#3326) Modify the Client Libraries gRPC Channel builder to use mTLS via S2A if the experimental environment variable is set, S2A is available (We check this by using utility added in googleapis/google-auth-library-java#1400), and a few more conditions (see `shouldUseS2A`). Following https://google.aip.dev/auth/4115, Only attempt to use S2A after DirectPath and DCA (https://google.aip.dev/auth/4114) are ruled out as options. If conditions to use S2A are not met (env variable not set, or S2A is not running in environment, etc (`shouldUseS2A` returns false)), fall back to default TLS connection. When we are creating S2A-enabled Grpc Channel Credentials, we first try to secure the connection between the client and the S2A via MTLS, using [MTLS-MDS](https://cloud.google.com/compute/docs/metadata/overview#https-mds) credentials. If MTLS-MDS credentials can't be loaded, then we fallback to a plaintext connection between the client and S2A. The parallel go implementation : googleapis/google-api-go-client#1874 (now lives here: https://github.com/googleapis/google-cloud-go/blob/main/auth/internal/transport/cba.go) S2A Java client: https://github.com/grpc/grpc-java/tree/master/s2a Resolving b/376258193 means that S2A.java is no longer experimental --------- Co-authored-by: blakeli <blakeli@google.com>
Add utility to get S2A address from MDS MTLS autoconfiguration endpoint.
This utility will be used when creating mTLS channel using S2A Java Client, which takes S2A Address as input to create S2AChannelCredentials.
Parallel change in go: googleapis/google-api-go-client#1874
S2A Java client: grpc/grpc-java#11113
Resolving b/376258193 means that S2A.java is no longer experimental