Enabling SDS in the gateway

[rshriram]

Signed-off-by: Shriram Rajagopalan shriramr@vmware.com

[rshriram]

What this API allows is to always have SDS agent in the gateway pod while still using old style file based configs. Then users can incrementally migrate to the SDS server by changing their existing gateway configs to use the CredentialStoreRemoteBackend with the resourceName as secretName. In other words, it allows some servers to have file based paths and others to have SDS without any guess work involving determining whether or not the gateway pod has a SDS agent.

[wenchenglu]

@myidpt please help review. I cannot add you to reviewer list, not sure why

[JimmyCYJ]

Change the field ID to begin with 1?
string server_certificate = 1;
string private_key = 2;

[myidpt]

I think that's to facilitate the proto field orders when doing the encoding.

[myidpt]

I'm generally OK with this approach. Wait for Costin's comments.
@costinm

[costinm]

+1, it's a good compromise, we can refine it in 1.2 based on user feedback.

I like the idea of using Gateway resource name as key in the SDS storage, it seems to solve all automated cases.

[wenchenglu]

/lgtm
/approve

[istio-testing]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rshriram, wenchenglu

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [rshriram]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[costinm]

I don't think this is a very nice UX - nor a good reason to deprecate server_certificate and the other fields.

We do need to keep a file-based option - and the existing fields work fine.

I don't agree that users should manually configure server_address or resource_name - it should be environment based, and user settings will prevent us from auto-provisioning and auto-config.

Pretty strong -1 on this change, in particular for 1.1

[costinm]

/hold

[rshriram]

FYI, the server certificates is still there.

servers:
- hosts:
   - foo.com
   tls:
    credentialStore:
      files:
        serverCertificate: ...
        privateKey...

Or

servers:
- hosts:
   - foo.com
  tls:
    credentialStore:
     remote:
       resourceName: mysecret

Only the secret name is mandatory. the server path is additional customization.

And systems that are auto provisioning the gateways - they are already generating the Gateway configs and the k8s secrets based on the hostnames. So all they have to do is something like this:

servers:
- hosts:
   - foo.com
tls:
 credentialStore:
   remote:
     resourceName: foo.com

Explicit spec avoids confusions caused by auto inference of that one single field