add sds client/server example for manual testing#3803
add sds client/server example for manual testing#3803wenchenglu merged 6 commits intoistio:masterfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3803 +/- ##
=======================================
- Coverage 76% 76% -<1%
=======================================
Files 291 291
Lines 26869 26825 -44
=======================================
- Hits 20379 20315 -64
- Misses 5178 5203 +25
+ Partials 1312 1307 -5
Continue to review full report at Codecov.
|
Gopkg.lock
Outdated
| analyzer-name = "dep" | ||
| analyzer-version = 1 | ||
| inputs-digest = "64e85d7b234617a9afbc0a95c64d1716f88ea99a3bbf475ab377c8d92f1100e4" | ||
| inputs-digest = "29d2c4c3d4cd0875ee211ab5e55c87a9554e4fb76b3ecec300dd055fd0014c97" |
There was a problem hiding this comment.
You might want to revert this file, which causes circleci dependency error in presubmit: https://circleci.com/gh/istio/istio/38114?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
|
done |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: myidpt The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
|
@myidpt |
|
Are there plans to aggregate SDS with regular xDS? Specifically, are there
any consistency issues with secrets not being available for routes?
…On Tue, Feb 27, 2018, 10:37 AM Wencheng Lu ***@***.***> wrote:
@myidpt <https://github.com/myidpt>
good point, will have a follow up cl to refactor this to library in the
directory you suggested
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3803 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AJGIxjRqbQ62gPk3BygceyJ9NU9YiBuAks5tZEsZgaJpZM4SUUrM>
.
|
|
@wenchenglu That sounds good to me. |
|
/lgtm cancel //PR changed after LGTM, removing LGTM. @myidpt @wenchenglu |
|
@kyessenov I think currently we don't plan to aggregate SDS with xDS. For the consistency issue, I guess we are still implementing the SDS on Envoy. I think it's reasonable to start with having Envoy disable the upstream traffic relying on the key/certs, when the key/certs are not present. |
|
@kyessenov although I am not sure what you meant by "any consistency issues with secrets not being available for routes"? |
costinm
left a comment
There was a problem hiding this comment.
Looks good in general - it would be great to put this into the node agent main.
| if *tls { | ||
| creds, err := credentials.NewServerTLSFromFile(*certFile, *keyFile) | ||
| if err != nil { | ||
| log.Fatalf("Failed to generate credentials %v", err) |
There was a problem hiding this comment.
Failed to load.
Should it wait for some time ( since certs show up with some delay ) ? Or fail ?
There was a problem hiding this comment.
Also what's the use case - isn't it over UDS or localhost ?
There was a problem hiding this comment.
yes, it is over UDS. This is a server code for manual test. I'll refactor this PR to a library with UDS support only
| } | ||
|
|
||
| // StreamSecrets is not supported. | ||
| func (s *SDSServer) StreamSecrets(stream sds.SecretDiscoveryService_StreamSecretsServer) error { |
There was a problem hiding this comment.
Did you test this with envoy ? My understanding was that fetch is called by REST ( which is json ), while gRPC is calling stream.
There was a problem hiding this comment.
Fetch is fine for this use-case. You do need to a gRPC gateway for HTTP mapping.
|
For the 'client' side - it would be great to try it out by changing the envoy bootstrap file, so we can get a |
|
@wenchenglu: The following test failed, say
DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
@myidpt @wenchenglu The consistency issue I have in mind is that if any LDS (or RDS?) resource references a secret that's not delivered through SDS, then those LDS/RDS resources get rejected by envoy. If they don't get rejected, envoy would blackhole the traffic since secrets are not delivered at the same time. |
|
|
||
| // FetchSecrets fetches the X.509 key/cert for a given workload whose identity | ||
| // can be derived from the UDS path where this call is received. | ||
| func (s *SDSServer) FetchSecrets(ctx context.Context, request *api.DiscoveryRequest) (*api.DiscoveryResponse, error) { |
There was a problem hiding this comment.
As an optimization, you can ignore requests that have version info "0".
There was a problem hiding this comment.
This is a server code mainly for manual test. how to set versioninfo is still to be figured out.
|
@kyessenov |
No description provided.