Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

control-plane: sds: add stub implementations #144

Merged
merged 1 commit into from
Sep 6, 2019

Conversation

yskopets
Copy link
Contributor

@yskopets yskopets commented Sep 4, 2019

changes:

  • add stab implementations that return mesh_ca certificate (to validate remote side) and indentity_cert certificate (to authenticate itself to the remote side)

@yskopets yskopets added this to the 0.1 milestone Sep 4, 2019
@yskopets yskopets force-pushed the feature/sds-stub-providers branch 2 times, most recently from f50a15a to 512bf73 Compare September 5, 2019 09:29
}

func (s *server) version(msg proto.Message) string {
return core.NewUUID()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure here, but with XDS such code would mean that Envoy and Control Plane would go back and forth exchanging data, because version is different every time. Can we either hardcode some string or do the same thing as we did with XDS which is comparing previous sent value?

or does it work here just fine?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The typical workflow on a SDS stream is:

  1. -> DiscoveryRequest
  2. <- DiscoveryResponse
  3. -> DiscoveryRequest (ACK)

after that, there is no more communication.

So, the version can be anything

Token: string(credential),
},
}
if err := k.client.Create(ctx, tokenReview); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see that we create this TokenReview with a client. How K8S then manages it? Don't we have to delete this after the review or K8S will clean it for us?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TokenReview object is not persisted.

Technically, it's a only method call (POST), but designed to fit into k8s API model

}
}

func DefaultDataplaneResolver(resourceManager core_manager.ResourceManager) func(context.Context, core_xds.ProxyId) (*core_mesh.DataplaneResource, error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the return type can be DataplaneResolver

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry, I interfered into your review process.

Both universal and k8s authenticators have been moved into a separate PR - https://github.com/Kong/kuma/pull/149

@yskopets yskopets changed the base branch from feature/sds-listen-on-tls to feature/add-builtin-ca-manager September 5, 2019 16:54
@yskopets yskopets force-pushed the feature/add-builtin-ca-manager branch from 199b4a3 to ce53851 Compare September 6, 2019 16:01
@yskopets yskopets changed the base branch from feature/add-builtin-ca-manager to master September 6, 2019 18:01
@yskopets yskopets merged commit eebda19 into master Sep 6, 2019
@yskopets yskopets deleted the feature/sds-stub-providers branch September 8, 2019 01:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants