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

Add PrivateLinkService and PrivateEndpoint support #2733

Merged
merged 24 commits into from
Mar 29, 2023
Merged

Conversation

super-harsh
Copy link
Collaborator

@super-harsh super-harsh commented Feb 19, 2023

Closes #1313

Special notes for your reviewer:

With the support for PrivateLinkService and PrivateEndpoint, we don't need to export any field as DNS and Ip address to reach the endpoint/service is either provided by the user, ServiceConnection, or by the vnet.

If applicable:

  • this PR contains tests

Copy link
Member

@matthchr matthchr left a comment

Choose a reason for hiding this comment

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

Bunch of comments but this overall looks pretty good to me. Some of my comments boil down to "I am not sure I understand this workflow" - which is Azure's issue... but I wanna make sure it's clear for users of ASO.

v2/azure-arm.yaml Show resolved Hide resolved
v2/azure-arm.yaml Show resolved Hide resolved

}

func DNSZoneGroup_CRUD(tc *testcommon.KubePerTestContext, vnet *v1beta20201101.VirtualNetwork, endpoint *network.PrivateEndpoint, rg *resources.ResourceGroup) {
Copy link
Member

Choose a reason for hiding this comment

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

Ok so this test is basically testing the scenario where the user has a VNET + PrivateDNSZone already configured on that VNET, and they want the PrivateEndpoint to create an entry in that existing PrivateDNSZone?

This seems pretty OK from a user-experience for me.

What about the other scenarios? User has NO private DNS zone and just wants to associate the Private Endpoint with a VNET directly. Should we have another test for that scenario? That scenario will make use of the customDnsConfigs property of the PrivateEndpoint, right?

"github.com/Azure/azure-service-operator/v2/internal/testcommon"
)

func Test_Networking_PrivateEndpoint_CRUD(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

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

Did you reference an ARM template/bicep example to produce this test? If so can you link it in a comment up here at the top?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

There is an ARM bicep example identical to this, however, they use SQLServer and we're using StorageAccount in this test. Still do we add the link?

Copy link
Member

Choose a reason for hiding this comment

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

Yeah I think still worth adding the link. Just say you replaced SQLServer with StorageAccount

Copy link
Member

Choose a reason for hiding this comment

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

I don't see the comment, yet.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Added!

{
Name: to.StringPtr("testEndpoint"),
PrivateLinkServiceReference: tc.MakeReferenceFromResource(sa),
GroupIds: []string{"blob"}, // TODO: This is a bit weird that user has to figure out the group ID(s).
Copy link
Member

Choose a reason for hiding this comment

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

is this the same thing they need to do in an ARM template?

Copy link
Member

Choose a reason for hiding this comment

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

If it is the same as the ARM template story, we may want to have the GroupIds configurable from config maps so that we can automate the workflow.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

the problem is, GroupIDs are not findable from a resource, it can be funky to get groupIDs for each type of resource into a configMap. For example, for Batch/BatchAccounts, it can be either batchAccount or nodeManagement(depending upon the subresource/service type), for CosmosDB/DatabaseAccounts it is Sql, for ServiceBus/namespaces it'll be namespace etc.

Copy link
Member

Choose a reason for hiding this comment

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

I am not sure I follow the configMap angle either. I just wanted to confirm that we're at parity with ARM templates or BICEP here, which I think we are. The user needs to (somehow) know what the GroupID is for their resource. I think if that's the same experience users get in the ARM template/BICEP/Terraform world then that's OK we're at parity with how it is in the rest of Azure.

ConfigMaps: &network20220701.PrivateLinkServiceOperatorConfigMaps{
Alias: &genruntime.ConfigMapDestination{
Name: plsConfigMap,
Key: "alias",
Copy link
Member

Choose a reason for hiding this comment

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

What exactly is alias and why do users want to consume it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Alias is a globally unique name for your service. It helps you mask the customer data for your service and at the same time creates an easy-to-share name for your service. When you create a Private Link service, Azure generates an alias for your service that you can share with your customers. Your customers can use this alias to request a connection to your service.

The alias is composed of three parts: Prefix.GUID.Suffix

Prefix is the service name. You can pick your own prefix. After "Alias" is created, you can't change it, so select your prefix appropriately.

GUID will be provided by platform. This GUID makes the name globally unique.

Suffix is appended by Azure: region.azure.privatelinkservice

Complete alias: Prefix. {GUID}.region.azure.privatelinkservice

Reference: https://learn.microsoft.com/en-us/azure/private-link/private-link-service-overview#alias

Copy link
Member

Choose a reason for hiding this comment

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

This sounds like something that should be called out in our docs. Consider adding a doc fragment to docs/v2/azure/supported-resources so that this included.

{
Name: to.StringPtr("testEndpoint"),
PrivateLinkServiceReference: tc.MakeReferenceFromResource(sa),
GroupIds: []string{"blob"}, // TODO: This is a bit weird that user has to figure out the group ID(s).
Copy link
Member

Choose a reason for hiding this comment

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

If it is the same as the ARM template story, we may want to have the GroupIds configurable from config maps so that we can automate the workflow.

ConfigMaps: &network20220701.PrivateLinkServiceOperatorConfigMaps{
Alias: &genruntime.ConfigMapDestination{
Name: plsConfigMap,
Key: "alias",
Copy link
Member

Choose a reason for hiding this comment

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

This sounds like something that should be called out in our docs. Consider adding a doc fragment to docs/v2/azure/supported-resources so that this included.

Copy link
Member

@theunrepentantgeek theunrepentantgeek left a comment

Choose a reason for hiding this comment

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

Blocking merge until we finish investigation of the version changes in the generated tests.

@eskaufel
Copy link

How is the progress on this? We need this as well

@codecov-commenter
Copy link

codecov-commenter commented Mar 21, 2023

Codecov Report

Merging #2733 (3ce523c) into main (4c935ef) will increase coverage by 0.02%.
The diff coverage is 51.38%.

@@            Coverage Diff             @@
##             main    #2733      +/-   ##
==========================================
+ Coverage   52.45%   52.48%   +0.02%     
==========================================
  Files        1091     1135      +44     
  Lines      431744   444130   +12386     
==========================================
+ Hits       226488   233107    +6619     
- Misses     169206   173982    +4776     
- Partials    36050    37041     +991     
Impacted Files Coverage Δ
...0200601/private_dns_zones_aaaa_record_types_gen.go 49.93% <ø> (ø)
...20200601/private_dns_zones_txt_record_types_gen.go 50.52% <ø> (ø)
...200601/private_dns_zones_txt_spec_arm_types_gen.go 33.33% <ø> (ø)
...s_zones_virtual_network_link_spec_arm_types_gen.go 33.33% <ø> (ø)
...rivate_dns_zones_virtual_network_link_types_gen.go 58.73% <ø> (ø)
...601storage/private_dns_zones_a_record_types_gen.go 55.55% <ø> (ø)
...storage/private_dns_zones_aaaa_record_types_gen.go 55.17% <ø> (ø)
...torage/private_dns_zones_cname_record_types_gen.go 55.17% <ø> (ø)
...01storage/private_dns_zones_mx_record_types_gen.go 55.17% <ø> (ø)
...1storage/private_dns_zones_ptr_record_types_gen.go 55.17% <ø> (ø)
... and 43 more

... and 5 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@matthchr
Copy link
Member

@eskaufel This will be part of the v2.0.0 release.

Copy link
Member

@matthchr matthchr left a comment

Choose a reason for hiding this comment

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

There were a bunch of user scenarios we were tracking with this work, here's my take on what we wanted and what you've got:

  • Private Link Service CRUD support
  • Private endpoint CRUD support

The Private Endpoint connection scenarios:

  • PE connects to VNET with PrivateDNSZone: Supported via PrivateEndpointsPrivateDnsZoneGroup. do we also need to support via raw IP (IP exported from PE, imported into ARecord, via configmap?)
  • PE connects to VNET using on-prem DNS. Requires DNS forwarder stuff we don't have set up here.

Is that right?

v2/azure-arm.yaml Outdated Show resolved Hide resolved
v2/azure-arm.yaml Outdated Show resolved Hide resolved
v2/azure-arm.yaml Show resolved Hide resolved
Copy link
Member

@matthchr matthchr left a comment

Choose a reason for hiding this comment

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

LGTM. We should probably merge this before my huge PR that adds the v1api version and removes v1alpha.

That way I need to rebase and fix it as opposed to you need to.

Copy link
Member

@theunrepentantgeek theunrepentantgeek 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.

"github.com/Azure/azure-service-operator/v2/internal/testcommon"
)

func Test_Networking_PrivateEndpoint_CRUD(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

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

I don't see the comment, yet.

@super-harsh super-harsh enabled auto-merge (squash) March 29, 2023 02:54
@super-harsh super-harsh merged commit cdbcb93 into main Mar 29, 2023
@super-harsh super-harsh deleted the feature/pls branch March 29, 2023 03:48
emilychu9318 pushed a commit to emilychu9318/azure-service-operator that referenced this pull request Apr 11, 2023
* Add PrivateLinkService and PrivateEndpoint support
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

Support for Private Link
5 participants