Azure-sdk-for-java: Client builders should accept another client for initialization

[rickle-msft]

Coming from #6536, builders should be able to accept another client and extract the pipeline and client for initialization. This helps conveniently construct clients that don't share package internals or inheritance hierarchies.

[SukruthKS]

When I opened #6536, it was in the context of EncryptedBlobClient. It'd be great if builders for other specialized clients like BlobLeaseClient can also get this capability. Looks like this feature request is already generalized to apply to all builders, but just wanted to point out in case it was going to be added only to EncryptedBlobClientBuilder :)

[SukruthKS]

Never mind. BlobLeaseClientBuilder already has this.

[gapra-msft]

Hi @SukruthKS,

Just to help clarify things, are you only concerned about caching credentials when needing to use the EncryptedBlobClientBuilder or are you also concerned about the other optional pipeline settings that are configurable from the builder?

Would it be sufficient if we could provide you with a method on the builder like encryptedBuilder.credential(existingClient.getHttpPipeline())

This would be a method that sets the credential found in the httpPipeline provided. Then you would have to go in and configure optional policies if need be.

[SukruthKS]

We are not setting any pipeline policies currently so getting just the creds from an existing pipeline should be sufficient. However, I could see us adding pipeline policies in the future for any custom requirements and having the ability to generate EncryptedBlobClient with those policies would be useful.

[gapra-msft]

Hi @SukruthKS I recently merged a PR that should address this issue. It should go out in our next release. I'll go ahead and close the issue, feel free to re-open it in case we can add additional functionality that would suit your needs

[SukruthKS]

@gapra-msft when I create EncryptedBlobClient from an existing BlobClient instance as shown below, it doesn't seem to copy over CustomerProvidedKey set in the blob client and I don't see an option to set it explicitly on EncryptedBlobClientBuilder either. Is there a way to do it?

EncryptedBlobClient encryptedBlobClient = new EncryptedBlobClientBuilder()
    .blobClient(existingBlobClient)
    .buildEncryptedBlobClient;

[gapra-msft]

Hi @SukruthKS

Sorry about that. Originally I didn't copy over the CustomerProvidedKey since I didn't realize people would want to double encrypt their data. We will work on adding that back in.

Thanks

[rickle-msft]

@SukruthKS do you foresee any need to specify an encryption scope on encrypted blob clients? Since we're adding the ability to add CPK to encrypted clients, we're wondering if we should add support for this related feature now, unless you have no intention of using it.

[SukruthKS]

@rickle-msft we have only been using FullBlob encryption scope and I don't see us changing it anytime soon. I assume that is the default if no scope is specified with the new encrypted blob client?

[rickle-msft]

So there's actually a new-ish feature on the service called encryption-scope that allows you to set a CPK on the account and then on each creation account, direct the service to use that CPK to encrypt the blob once the data reaches the service. This is what I was asking about.

I think you are asking about how much of the blob is encrypted, and yes, FullBlob is the default and only option in this regard.

I'm assuming from the direction you took the question that you don't use the service's encryption-scope feature, so we'll hold off on adding that for now.

[gapra-msft]

Hi @SukruthKS
Would there be a problem with just adding a customerProvidedKey method on the EncryptedBlobClientBuilder? We can't just extract it from the provided BlobClient since there is no secure way to do so. Currently there is a getCustomerProvidedKey method on the BlobClient but due to security reasons we plan to deprecate that.

[SukruthKS]

@gapra-msft having an option to specify CPK on the builder should be good enough for us.