sassoftware / viya4-iac-azure

This project contains Terraform configuration files to provision infrastructure components required to deploy SAS Viya platform products on Microsoft Azure Cloud.
Apache License 2.0
72 stars 88 forks source link

fix: (IAC-1427) AKS Networking Tab reports incorrect load balancer SKU #377

Closed Shaffi-Housseini closed 4 months ago

Shaffi-Housseini commented 5 months ago

Terraform Version Details

terraform_version

Terraform Variable File Details

terraform.txt

Steps to Reproduce

Running the terraform commands using default values in the tfvars files.

Expected Behavior

Expecting Load Balancer SKU value of the AKS Cluster's API Server to be 'Standard' in Propcase rather than Lowcase in the networking overview tab in azure.

Actual Behavior

Currently is being set as Lowcase which we think is causing the Authorized IP ranges being disabled rather than showing the IP ranges setup in the TFVars file.

Additional Context

We created an AKS cluster using Terraform, as we have done many times before. However, this time, we've noticed that access to the API Server is limited. We are aware that we have used a list of CIDR IP ranges, but even clients on the approved IP ranges are failing to connect with "Failed to get /version Forbidden".

We suspect this is because the Value for the load balancer SKU is now being set to 'standard' as lowercase rather than 'Standard' and somehow its not being parsed correctly. See doc attached - Error when connecting to AKS API Server.docx

We have attempted to modify the line where this is fed in to be Propcase and rerunning the terraform commands- https://github.com/sassoftware/viya4-iac-azure/blob/main/modules/azure_aks/main.tf#L41.

However, this is returning the following error and is expecting it to be lowercase. Is there a way this could be changed to default it to feeding it the propcase value? image

References

No response

Code of Conduct

riragh commented 4 months ago

@Shaffi-Housseini, Thanks for notifying us of this discrepancy. We did notice this issue in our automation run and I have been debugging it. There is already an Internal ticket to track this issue. Unfortunately, so far in my debugging process I haven't been able to reproduce this issue.

The lowercase "standard" for Load Balancer SKU is the only acceptable value in Terraform. There has been no update on terraform provider to change that. Terraform provider azurerm makes the underlying Azure API calls and these values are then converted somehow to whatever Azure expects. All of this is outside of IAC. So, changing the value to "Standard" will throw error as expected.

One other observation during debugging was only Portal's networking tab is incorrectly showing the "Authorized IP ranges" to be disabled. The Overview tab shows the IP ranges correctly under Networking section. Also, verified it through az CLI to confirm the "Authorized IP ranges" was set correctly for the deployment.

Could you please verify that's the case on your deployments as well? As I am unable to reproduce this issue, I will be creating a Microsoft Azure support ticket to get help, as this looks like something wrong with the API and Azure Portal. I'll update this issue later once I more information.

Shaffi-Housseini commented 4 months ago

@riragh. Thanks for the reply. I can confirm that we are only noticing this discrepancy on the networking tab of the AKS cluster resource: image

When checking the load balancer service in the 'MC_*' recourse group it is being displaced correctly: image

As well as when checking the overview tab of cluster resource: image

We have already raised ticket with Microsoft Azure support to highlight this issue and see whether this is a fault on their end, considering terraform only accepts 'standard' - Support Request: AKS Control Pane reports incorrect load balancer SKU and Networking tab incorect - Microsoft Azure

riragh commented 4 months ago

Fix was applied by Azure and things seem to be working as expected now. Closing this ticket based on internal verification and user's confirmation in internal ticket.