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

Bug/Help Needed: Private Endpoint Exposes only one NIC IP address #4464

Open
mehighlow opened this issue Nov 22, 2024 · 3 comments
Open

Bug/Help Needed: Private Endpoint Exposes only one NIC IP address #4464

mehighlow opened this issue Nov 22, 2024 · 3 comments
Labels
bug 🪲 Something isn't working waiting-on-user-response Waiting on more information from the original user before progressing.

Comments

@mehighlow
Copy link
Contributor

mehighlow commented Nov 22, 2024

Describe the bug

Private Endpoint Integration for CosmosDB exposes only one NIC IP address. However, a Private Endpoint for CosmosDB might create more than one NIC + IP address.

Automation can be leveraged to create just one DNS record for PrimaryNicPrivateIpAddress:

│   ├── OperatorSpec: *Object (3 properties)
│   │   ├── ConfigMapExpressions: *core.DestinationExpression[]
│   │   ├── ConfigMaps: *Object (1 property)
│   │   │   └── PrimaryNicPrivateIpAddress: *genruntime.ConfigMapDestination

although both IP addresses remain valid for establishing connections:

Image

The issue arises using CosmosDB client (Azure SDK for .NET). By default, client has the LimitToEndpointProperty set to false. This configuration instructs the SDK to automatically discover write and read regions and use them when the configured application region is unavailable. In my case, the application opted to use the regional FQDN, even though the endpoint connection was configured as global. This behavior can be addressed by setting the LimitToEndpointProperty to true and ConnectionMode set to Gateway. But this adjustment requires knowing what to look for.

Azure Service Operator Version: 2.9.0

Expected behavior

Both regional and global IP addresses are exposed, required FQDN records exposed.

To Reproduce

Deploy CosmosDB with Private Endpoint integration. Use the Azure SDK for .NET to establish a connection to the database with default settings. Observe that the client selects the regional endpoint, even though the supplied database FQDN is global.

Screenshots

N/A

Additional context

N/A

@mehighlow mehighlow added the bug 🪲 Something isn't working label Nov 22, 2024
@matthchr matthchr changed the title Bug/Help Needed: Private Enpoint Exposes only one NIC IP address Bug/Help Needed: Private Endpoint Exposes only one NIC IP address Nov 25, 2024
@matthchr
Copy link
Member

Does the Status of the PrivateEndpoint contain the IPs that you want?

If so, can you use the new expressions feature to output all of the URLs/IPs you want to a configmap?

If Status does have the FQDNs you want, if you share its shape here I can help you to craft a CEL expression that will output the one(s) you want.

@matthchr matthchr added waiting-on-user-response Waiting on more information from the original user before progressing. and removed needs-triage 🔍 labels Nov 25, 2024
@theunrepentantgeek
Copy link
Member

Any update @mehighlow ?

@mehighlow
Copy link
Contributor Author

@matthchr , @theunrepentantgeek

status indeed contains all IP addresses and FQDNs.

  conditions:
  - lastTransitionTime: "2024-12-18T06:03:57Z"
    observedGeneration: 1
    reason: Succeeded
    status: "True"
    type: Ready
  customDnsConfigs:
  - fqdn: dbname.documents.azure.com
    ipAddresses:
    - 10.10.16.4
  - fqdn: dbname-westus2.documents.azure.com
    ipAddresses:
    - 10.10.16.5

I’ll create a PR once this is done. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🪲 Something isn't working waiting-on-user-response Waiting on more information from the original user before progressing.
Projects
Development

No branches or pull requests

3 participants