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

feat(kuma-cp) Improve certificate verification #779

Merged
merged 2 commits into from
May 27, 2020

Conversation

jakubdyszkiewicz
Copy link
Contributor

Summary

Improve certificate verification by checking URI SANs.

@jakubdyszkiewicz jakubdyszkiewicz requested a review from a team May 26, 2020 12:30
Copy link
Contributor

@lobkovilya lobkovilya left a comment

Choose a reason for hiding this comment

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

Looks good, just one question related to comment.

@@ -27,11 +35,17 @@ func CreateDownstreamTlsContext(ctx xds_context.Context, metadata *core_xds.Data
}, nil
}

func CreateUpstreamTlsContext(ctx xds_context.Context, metadata *core_xds.DataplaneMetadata) (*envoy_auth.UpstreamTlsContext, error) {
// CreateUpstreamTlsContext creates UpstreamTlsContext for outgoing connections
// It verifies that the client has TLS certificate signed by Mesh CA with URI SAN of spiffe://{mesh_name}/{upstream_service}
Copy link
Contributor

Choose a reason for hiding this comment

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

If UpstreamTlsContext is configured on the cluster of the client-side, why it verifies that "client" has TLS certificate? I'm not sure here, but it feels like it verifies "server", doesn't it?

func CreateUpstreamTlsContext(ctx xds_context.Context, metadata *core_xds.DataplaneMetadata) (*envoy_auth.UpstreamTlsContext, error) {
// CreateUpstreamTlsContext creates UpstreamTlsContext for outgoing connections
// It verifies that the client has TLS certificate signed by Mesh CA with URI SAN of spiffe://{mesh_name}/{upstream_service}
// Server exposes for the the clients cert with multiple URI SANs, which means that if client DP has inbound with services "web" and "web-api" and communicates with "backend"
Copy link
Contributor

Choose a reason for hiding this comment

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

typo: "the the"

@@ -55,7 +55,7 @@ resources:
safeRegexMatch:
googleRe2:
maxProgramSize: 500
regex: '.*&service=[^&]*frontend[,&].*'
regex: .*&service=[^&]*frontend[,&].*
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we want to remove the single quotes here?

Copy link
Contributor

@nickolaev nickolaev left a comment

Choose a reason for hiding this comment

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

Looks good to me.

Base automatically changed from feat/multiple-san-uri to master May 27, 2020 10:12
@jakubdyszkiewicz jakubdyszkiewicz force-pushed the feat/multiple-san-uri-verification branch from ccd7512 to 4d9c2fa Compare May 27, 2020 10:30
@jakubdyszkiewicz jakubdyszkiewicz merged commit 3eed01f into master May 27, 2020
@jakubdyszkiewicz jakubdyszkiewicz deleted the feat/multiple-san-uri-verification branch May 27, 2020 10:57
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

3 participants