add authorized ip range variable for azure

[dcmcand]

Reference Issues or PRs

Closes #2784

What does this implement/fix?

Put a x in the boxes that apply

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds a feature)
• Breaking change (fix or feature that would cause existing features not to work as expected)
• Documentation Update
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no API changes)
• Build related changes
• Other (please describe):

Testing

• Did you test the pull request locally?
• Did you add new tests?

How to test this PR?

Ensure you can deploy to azure with an existing azure config.

Then

Add a authorized_ip_ranges line to the azure provider of your nebari-config.yaml. Deploy to azure and ensure that access to api server is limited to that ip range.

example config block

azure:
  authorized_ip_ranges: ["80.145.170.197/32"]  # make this your own ip address
  kubernetes_version: 1.29.2
  region: eastus
  storage_account_postfix: esrr
  node_groups:
    general:
      instance: Standard_D8_v3
      min_nodes: 1
      max_nodes: 1
    user:
      instance: Standard_D4_v3
      min_nodes: 0
      max_nodes: 5
    worker:
      instance: Standard_D4_v3
      min_nodes: 0
      max_nodes: 5

Any other comments?

[dcmcand]

The failing tests appear unrelated to these changes.

[viniciusdc]

Hi @dcmcand, I am not sure if this will be related at all, but last time we changed something related to IP ranges (specifically for AWS CIDRs blocks) we ended up having issues with Dask (here's some of the discussion points #828)

So I would just suggest to do a full Azure deploy with these settings and double check if dask can spin correctly.

[dcmcand]

Hi @dcmcand, I am not sure if this will be related at all, but last time we changed something related to IP ranges (specifically for AWS CIDRs blocks) we ended up having issues with Dask (here's some of the discussion points #828)

So I would just suggest to do a full Azure deploy with these settings and double check if dask can spin correctly.

That looks unrelated, but I will test it.

[dcmcand]

@viniciusdc tested and dask works fine. Now that 2024.12.1 is out, could I get a review here?

[viniciusdc]

It looks good to me; I only have a single question regarding the aks cluster new block api_server_access_profile; did you test this modification on a previously deployed cluster? And is can this change be safely rolled back?

[viniciusdc]

Including this field leads to a resource update. Does it affect the running nodes at all?

[dcmcand]

It shouldn't be I can test.

[dcmcand]

All it does is update and attribute, no replacement needed. It also runs on the cluster, not on the node.