Forem: Falolu Olaitan

Setting Up a Production-Ready Kubernetes Cluster on RHEL 9.7

Falolu Olaitan — Mon, 06 Apr 2026 21:26:45 +0000

Running Kubernetes on Red Hat Enterprise Linux (RHEL) is a common requirement in enterprise environments, especially in regulated industries where stability, security, and support matter.

This guide walks through how to set up a Kubernetes cluster on RHEL 9.7, using a multi-node architecture suitable for production workloads.

Architecture Overview

A typical production setup includes:

Control Plane Nodes (3)
API server
scheduler
controller manager
etcd (stacked or external)
Worker Nodes
run application workloads
Load Balancer (recommended)
provides a single endpoint for the API server

This design ensures:

high availability
fault tolerance
scalability

System Requirements

Each node should have:

RHEL 9.7 installed
at least 2 CPUs (4+ recommended)
4GB RAM minimum (8GB+ recommended)
stable network connectivity
unique hostname

Step 1: Disable Swap
Kubernetes requires swap to be disabled.

sudo swapoff -a

Remove it permanently:

sudo sed -i '/swap/d' /etc/fstab

Verify

free -h
swapon --show

Step 2: Configure Kernel Modules and Networking

Enable required modules:

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

Set sysctl parameters:

cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

sudo sysctl --system

Step 3: Configure Hostname and Hosts File

Set hostnames on each node:

hostnamectl set-hostname <node-name>

Update /etc/hosts on all nodes:

<IP> controlplane1
<IP> controlplane2
<IP> controlplane3
<IP> worker1
<IP> worker2

This helps with internal name resolution.

Step 4: Install Container Runtime (containerd)

Kubernetes no longer supports Docker directly as a runtime. Use containerd.

Install:

sudo dnf install -y containerd

Generate default config:

sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

Enable systemd cgroup driver:

Edit:

sudo vi /etc/containerd/config.toml

Set

SystemdCgroup = true

Restart

sudo systemctl restart containerd
sudo systemctl enable containerd

Step 5: Install Kubernetes Components

Add Kubernetes repo:

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.29/rpm/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.29/rpm/repodata/repomd.xml.key
EOF

Install:

sudo dnf install -y kubelet kubeadm kubectl

Enable kubelet:

sudo systemctl enable kubelet

Step 6: Initialize the Control Plane

Run on the first control plane node:

sudo kubeadm init \
  --control-plane-endpoint "<LOAD_BALANCER_DNS>:6443" \
  --upload-certs

If no load balancer exists, you can temporarily use the first node’s IP.

After initialization:

mkdir -p $HOME/.kube
sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Verify:

kubectl get nodes

Step 7: Join Additional Control Plane Nodes

Use the join command generated from kubeadm init, including:

token
discovery token CA cert hash
certificate key Example:

kubeadm join <endpoint>:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash> \
  --control-plane \
  --certificate-key <key>

Step 8: Join Worker Nodes

Run on each worker:

kubeadm join <endpoint>:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

Step 9: Install CNI (Networking)

Without a CNI plugin, pods cannot communicate.
Popular options:

Calico
Cilium
Flannel Example using Calico:

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Verify:

kubectl get pods -n kube-system

Step 10: Remove Control Plane Taints (Optional for testing)

By default, control planes don’t run workloads.

For lab/testing:

kubectl taint nodes --all node-role.kubernetes.io/control-plane-

For production, leave taints in place.

Step 11: Verify Cluster Health

kubectl get nodes
kubectl get pods -A
kubectl cluster-info

All nodes should be Ready.

Step 12: Add Load Balancer for Services (Optional)

For on-prem environments, you can use:

MetalLB
HAProxy + Keepalived
external hardware load balancer MetalLB allows you to assign IPs to services of type LoadBalancer.

Common Pitfalls

Swap not disabled

Cluster will fail to initialize.

Wrong cgroup driver

Mismatch between containerd and kubelet causes instability.

Firewall issues

Ensure required ports are open between nodes.

Missing CNI

Pods will remain in Pending.

kubeconfig not set

You’ll see errors like:

connection refused to localhost:8080

Production Considerations
For a real-world deployment:

use a load balancer for API server
separate etcd if scale increases
implement monitoring (Prometheus, Grafana)
enable logging aggregation
enforce RBAC policies
use TLS everywhere
implement backup strategy for etcd

Conclusion
Setting up Kubernetes on RHEL 9.7 gives you:

enterprise-grade stability
full control over infrastructure
flexibility for hybrid or on-prem environments

The key is not just getting the cluster running, but designing it for:

resilience
observability
security
scalability Once the foundation is solid, you can confidently run critical workloads on top of it.

Syncing Azure SQL Databases Across Subscriptions Using OpenShift CronJob (Without ADF)

Falolu Olaitan — Thu, 12 Feb 2026 20:31:59 +0000

Sometimes you need to move data between environments without introducing a heavy ETL tool like Azure Data Factory.

In my case, I needed to sync a table from:

A Production Azure SQL Database
To a Development Azure SQL Database
Across different subscriptions
Over Private Endpoints
Running inside Azure Red Hat OpenShift (ARO)

The goal:

Incrementally sync new rows every 2 minutes. No ADF. No linked servers. No manual exports.

Here’s how I built a lightweight, production-ready sync using:

bcp
sqlcmd
Kubernetes CronJob
A watermark table

Architecture Overview

Inside the OpenShift cluster:
A CronJob runs every 2 minutes
Reads the last synced ID from Dev
Exports new rows from Prod
Imports into Dev
Updates watermark

Networking:

Both SQL servers use Private Endpoints
privatelink.database.windows.net DNS zone linked properly
No public database access

Step 1: Create a Watermark Table in Dev

This keeps track of what has already been synced.

CREATE TABLE dbo.DataSyncWatermark (
  TableName sysname PRIMARY KEY,
  LastSyncedId bigint NOT NULL DEFAULT(0),
  UpdatedAt datetime2 NOT NULL DEFAULT SYSUTCDATETIME()
);

INSERT INTO dbo.DataSyncWatermark(TableName, LastSyncedId)
VALUES ('dbo.ActivityLogs', 0);

Step 2: Example Table Schema (Generic)

To keep this reusable, here’s a sample table structure:

CREATE TABLE dbo.ActivityLogs (
  Id bigint IDENTITY(1,1) NOT NULL PRIMARY KEY,
  UserId nvarchar(100),
  ActionType nvarchar(200),
  Payload nvarchar(max),
  Response nvarchar(max),
  StatusCode int,
  CreatedAt datetime2,
  ExtraMetadata nvarchar(2048)
);

Both Prod and Dev must have identical structure.

Step 3: Create Kubernetes Secret

Never hardcode credentials in YAML.

Create a secret like this:

oc create secret generic sql-sync-secret \
  --from-literal=PROD_SERVER=prod-sql.database.windows.net \
  --from-literal=PROD_DB=prod_database \
  --from-literal=PROD_USER=sync_user \
  --from-literal=PROD_PASS='StrongPassword!' \
  --from-literal=DEV_SERVER=dev-sql.database.windows.net \
  --from-literal=DEV_DB=dev_database \
  --from-literal=DEV_USER=sync_user \
  --from-literal=DEV_PASS='StrongPassword!'

Now the CronJob can safely consume these via environment variables.

Step 4: Required SQL Permissions

On Prod:

GRANT SELECT ON dbo.ActivityLogs TO sync_user;

On Dev:

GRANT SELECT, INSERT ON dbo.ActivityLogs TO sync_user;
GRANT SELECT, INSERT, UPDATE ON dbo.DataSyncWatermark TO sync_user;
GRANT ALTER ON dbo.ActivityLogs TO sync_user;

ALTER is required because we preserve identity values during import.

Step 5: The CronJob YAML

This version:

Runs every 2 minutes
Handles incremental sync
Avoids collation errors
Preserves identity
Avoids duplicate inserts
Auto-detects sqlcmd and bcp

apiVersion: batch/v1
kind: CronJob
metadata:
  name: sql-table-sync
spec:
  schedule: "*/2 * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          containers:
            - name: runner
              image: mcr.microsoft.com/mssql-tools
              envFrom:
                - secretRef:
                    name: sql-sync-secret
              command: ["/bin/bash","-lc"]
              args:
                - |
                  set -e

                  SQLCMD="/opt/mssql-tools/bin/sqlcmd"
                  BCP="/opt/mssql-tools/bin/bcp"

                  TABLE="dbo.ActivityLogs"
                  WM="dbo.DataSyncWatermark"

                  LAST_ID=$($SQLCMD -S "$DEV_SERVER" -d "$DEV_DB" -U "$DEV_USER" -P "$DEV_PASS" \
                    -h -1 -W -Q "SET NOCOUNT ON; SELECT LastSyncedId FROM $WM WHERE TableName = '$TABLE';")

                  DEV_MAX_ID=$($SQLCMD -S "$DEV_SERVER" -d "$DEV_DB" -U "$DEV_USER" -P "$DEV_PASS" \
                    -h -1 -W -Q "SET NOCOUNT ON; SELECT ISNULL(MAX(Id),0) FROM $TABLE;")

                  if [ "$LAST_ID" -lt "$DEV_MAX_ID" ]; then
                    LAST_ID="$DEV_MAX_ID"
                  fi

                  NEW_COUNT=$($SQLCMD -S "$PROD_SERVER" -d "$PROD_DB" -U "$PROD_USER" -P "$PROD_PASS" \
                    -h -1 -W -Q "SET NOCOUNT ON; SELECT COUNT(1) FROM $TABLE WHERE Id > ${LAST_ID};")

                  if [ "$NEW_COUNT" = "0" ]; then
                    exit 0
                  fi

                  $BCP "
                  SELECT
                    Id,
                    UserId COLLATE DATABASE_DEFAULT,
                    ActionType COLLATE DATABASE_DEFAULT,
                    Payload COLLATE DATABASE_DEFAULT,
                    Response COLLATE DATABASE_DEFAULT,
                    StatusCode,
                    CreatedAt,
                    ExtraMetadata COLLATE DATABASE_DEFAULT
                  FROM $TABLE
                  WHERE Id > ${LAST_ID}
                  ORDER BY Id
                  " queryout /tmp/data.dat \
                    -S "$PROD_SERVER" -d "$PROD_DB" -U "$PROD_USER" -P "$PROD_PASS" -n

                  $BCP $TABLE in /tmp/data.dat \
                    -S "$DEV_SERVER" -d "$DEV_DB" -U "$DEV_USER" -P "$DEV_PASS" \
                    -n -E -b 5000

                  $SQLCMD -S "$DEV_SERVER" -d "$DEV_DB" -U "$DEV_USER" -P "$DEV_PASS" -Q "
                    UPDATE $WM
                    SET LastSyncedId = (SELECT MAX(Id) FROM $TABLE),
                        UpdatedAt = SYSUTCDATETIME()
                    WHERE TableName = '$TABLE';
                  "

Common Issues I Faced

Private DNS returning NXDOMAIN Fix: Ensure both SQL servers have private endpoints and DNS zone groups attached.
Collation errors Fix: Add COLLATE DATABASE_DEFAULT to string columns in export query.
Duplicate primary key errors Fix: Align watermark with MAX(Id) in Dev.
Table does not exist” error Fix: Grant proper INSERT + ALTER permissions.

Why This Approach Works

No external ETL tool required
Lightweight
Kubernetes-native
Works across subscriptions
Fully automated
Secure over Private Link
Easy to generalize for other tables

When You Should Use Something Else

If you need:

Near real-time replication
Massive table sync
Transformations
CDC
Multi-region replication

Then consider:

Azure SQL replication
Azure Data Factory
Change Data Capture
Streaming architecture

Final Thoughts

Sometimes you don’t need a heavy data pipeline.

A well-designed incremental job, proper networking, and a watermark table can solve the problem cleanly.

From Helm AGIC Headaches to the AKS Add-on: a Real-World Migration + Troubleshooting Playbook

Falolu Olaitan — Thu, 16 Oct 2025 20:07:11 +0000

This write-up distills exactly what we just did: triaging an aging Helm-based AGIC install, fixing identity and tooling gotchas, and cleanly migrating to the AKS ingress-appgw add-on while keeping the same Application Gateway and public IP. I’m keeping it practical—commands, failure modes, and what to check next.

The situation we started with

AGIC (Helm) was old (1.5.x era) and running in default namespace.
It still used AAD Pod Identity patterns (aadpodidbinding, USE_MANAGED_IDENTITY_FOR_POD), which are deprecated in favor of Azure Workload Identity (WI).
A bunch of confusing errors popped up:
AGIC couldn’t get tokens (“Identity not found”) after UAMI changes.
APPGW_RESOURCE_ID was corrupted to C:/Program Files/Git/... (Git Bash path conversion).
An invalid API version warning (older CLI/extensions) during scripting.
AGIC logs showed malformed ARM targets like Subscription="Git" or empty Name—classic signs of a broken config map.
We also needed to keep the same IP (52.157.252.178) on the existing App Gateway.

Key decisions

Stop fighting the old chart. Microsoft moved AGIC Helm charts to OCI on MCR; the old blob repo is retired. If you stay on Helm, pull from oci://mcr.microsoft.com/azure-application-gateway/charts/ingress-azure and use Workload Identity
Prefer the AKS add-on for simplicity (identity + RBAC wiring handled for you). You can point it at an existing App Gateway—no new IP if you pass --appgw-id.
Ensure the gateway is v2 SKU (Standard_v2 or WAF_v2); AGIC requires v2.

What actually fixed things (chronologically)

Kill Git Bash path mangling If you must use Git Bash on Windows, disable MSYS path conversion so Azure resource IDs don’t become C:\Program Files\Git..

export MSYS_NO_PATHCONV=1
export MSYS2_ARG_CONV_EXCL="*"

Stop the old Helm controller Running two controllers (Helm + add-on) leads to churn. Uninstall Helm, or at minimum ensure only one is active:

helm uninstall ingress-azure -n default
kubectl -n default delete deploy,sa,cm,clusterrole,clusterrolebinding -l app=ingress-azure --ignore-not-found=true

If you keep Helm instead of the add-on, upgrade to the OCI chart and Workload Identity

Enable the AKS add-on against the existing App Gateway This reuses the same gateway and keeps your IP

APPGW_ID="/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Network/applicationGateways/<name>"
az aks enable-addons -g <rg> -n <cluster> -a ingress-appgw --appgw-id "$APPGW_ID"

Microsoft’s tutorial covers enabling the add-on on an existing AKS and existing App Gateway (even in separate VNets)

Check identity/RBAC for the add-on The add-on wires a user-assigned identity in the node resource group (MC_...). Give it rights on the gateway:

ADDON_MI="/subscriptions/<sub>/resourceGroups/<mc_rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<addon-mi>"
ADDON_PRINCIPAL=$(az identity show --ids "$ADDON_MI" --query principalId -o tsv)

# Required at minimum:
az role assignment create --assignee "$ADDON_PRINCIPAL" --role "Contributor" --scope "$APPGW_ID"

# Helpful read scope at RG (prevents odd read failures of related objects):
az role assignment create --assignee "$ADDON_PRINCIPAL" --role "Reader" \
  --scope "/subscriptions/<sub>/resourceGroups/<gateway-rg>"

Confirm AGIC is actually watching your Ingress
AGIC processes Ingresses with kubernetes.io/ingress.class: azure/application-gateway or spec.ingressClassName: azure/application-gateway. Your manifest already has the legacy annotation, which is fine.
Make sure your Services have Endpoints
Most “backend not updated” cases are just Services resolving to zero endpoints (selectors don’t match pods, wrong targetPort, probes failing). AGIC won’t add pool members without endpoints:

kubectl -n default get svc <name> -o wide
kubectl -n default get endpoints <name> -o wide

Why the original errors happened (and how to recognize them)

“Identity not found” from IMDS after switching identities → the UAMI wasn’t attached to the VMSS (Helm MSI pattern) or AGIC was still configured to an old clientId. Attaching the UAMI to all node scale sets and granting AppGW Contributor resolves it; add-on wires its own identity.
https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/how-to-configure-managed-identities-scale-sets?pivots=identity-mi-methods-azp
Invalid API version → older CLI/extensions forcing a stale API; upgrade CLI/extensions. (General Azure CLI hygiene.)

If you stay on Helm instead of the add-on
Use the OCI chart and Workload Identity:

# Enable OIDC + WI
az aks update -g <rg> -n <cluster> --enable-oidc-issuer --enable-workload-identity

# Federate your UAMI to the service account AGIC uses
AKS_OIDC_ISSUER=$(az aks show -g <rg> -n <cluster> --query oidcIssuerProfile.issuerUrl -o tsv)
az identity federated-credential create \
  --name agic \
  --identity-name <your-uami> \
  --resource-group <rg> \
  --issuer "$AKS_OIDC_ISSUER" \
  --subject "system:serviceaccount:<ns>:<sa>"

IDENTITY_CLIENT_ID=$(az identity show -g <rg> -n <your-uami> --query clientId -o tsv)
APPGW_ID="/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Network/applicationGateways/<name>"

# Upgrade/install from OCI chart on MCR
helm upgrade --install ingress-azure oci://mcr.microsoft.com/azure-application-gateway/charts/ingress-azure \
  -n <ns> \
  --set appgw.applicationGatewayID="$APPGW_ID" \
  --set armAuth.type=workloadIdentity \
  --set armAuth.identityClientID="$IDENTITY_CLIENT_ID" \
  --set rbac.enabled=true

NOTE: When you enable the add-on with --appgw-id, it reuses your existing App Gateway and therefore keeps the same public IP. Your DNS records pointing at that IP don’t need to change. Creating the add-on without --appgw-id would create a new gateway (and new IP)

How to Deploy AI Model Endpoints in Azure Machine Learning Studio

Falolu Olaitan — Sat, 17 May 2025 08:16:22 +0000

Azure Machine Learning Studio (Azure ML) is a powerful platform for building, training, and deploying machine learning models. This guide will walk you through creating a new workspace, registering a model, setting up a custom environment, and deploying a model to an endpoint

Step 1: Create a New Workspace
What is an Azure ML Workspace?
A workspace is a foundational resource in Azure ML that provides a centralized place to manage machine learning experiments, resources, and assets.

Steps to Create a Workspace

Log in to Azure Portal: Go to ml.azure.com.
Create a New Workspace:
Click on + Create.
Fill in the required details:
Subscription: Select your Azure subscription.
Resource Group: Choose an existing one or create a new one.
Workspace Name: Provide a unique name for your workspace.
Region: Select the region closest to your team or resources.
Click Review + Create and then Create.

Step 2: Register Your Model
Why Register a Model?
Model registration ensures version control and enables easy deployment and collaboration within your team.

Steps to Register a Model

Log in to Azure ML Studio:
Go to your workspace in Azure ML Studio (https://ml.azure.com).
Register the Model:
Navigate to Assets > Models > Register Model.

Upload your model file (e.g., .pkl, .onnx, or .mlmodel).

Provide details such as:
Model Name: Give it a unique name.
Description: Briefly describe the model.

Optionally, tag your model for better organization.
Complete Registration:
Click Register to store the model in the workspace

Step 3: Create a Custom Environment
What is an Environment in Azure ML?
An environment encapsulates the dependencies required for model training or inference, such as Python packages, system libraries, and environment variables.

Steps to Create a Custom Environment

Navigate to Environments:
In Azure ML Studio, go to Assets > Environments.

Create a New Environment:

Click + New Environment.
Choose Custom Environment and provide:
Name: A unique name for the environment.
Description: Details about the environment’s purpose.

Specify Dependencies:

Using a YAML File: Upload a .yml file containing your dependencies.
Manually Add Dependencies:
Choose a base image (e.g., AzureML TensorFlow or AzureML PyTorch).
Add specific Python packages in the Conda or Pip section.
Save the Environment
Review the configuration and click Create.

Step 4: Deploy a Model to an Endpoint
What is an Endpoint?
Endpoints expose your model as a web service, allowing applications to interact with it via REST APIs.

Steps to Deploy a Model

Prepare Your Model and Environment:
Ensure the model and environment are registered in the workspace.
Create a Deployment:
Go to Endpoints > Real-time Endpoints > + New Endpoint.
Provide details:
Name: A unique name for the endpoint.
Compute Type: Choose between managed online endpoints or Kubernetes.
Specify Deployment Configuration:
Model: Select the registered model.
Environment: Choose the custom environment you created.
Inference Configuration: Define the entry script (e.g., score.py) and other runtime settings.
Click Deploy and monitor the deployment status.
Test the Endpoint:
Once deployed, use the endpoint URL and API key to send test requests using tools like Postman or Python’s requests library.

Conclusion
Azure Machine Learning Studio streamlines the entire machine learning lifecycle, from model development to deployment. By following the steps outlined above, you can effectively manage resources, ensure reproducibility, and deploy your models with ease.

How to Automate Azure App Service IP Whitelisting with Azure DevOps Pipeline

Falolu Olaitan — Sat, 17 May 2025 07:57:15 +0000

If you’re managing IP restrictions for an Azure App Service, you’ve likely encountered the need to add, update, or remove IP addresses for access control. Doing this manually can be cumbersome and prone to errors, especially when dealing with multiple environments or services. By using an Azure DevOps (ADO) pipeline, you can automate IP whitelisting, ensuring that changes are applied consistently.

In this guide, I’ll walk you through using the Azure CLI in an Azure DevOps pipeline to manage IP restrictions dynamically. We’ll set up a pipeline that:

Accepts an IP address and rule name as parameters.
Checks if an existing IP restriction with the specified name already exists. Deletes the existing rule if found and adds the new IP restriction with a specified priority. let's dive in!

Prerequisites
Before we get started, make sure you have:

Azure CLI installed on your DevOps agent.
Azure Service Connection in ADO, allowing access to your Azure subscription.
Resource Group and App Service name where you plan to implement IP restrictions.

Step 1: Understanding the Azure CLI Commands
The Azure CLI provides straightforward commands for managing access restrictions. Here’s a quick breakdown:

Add an IP Restriction
This command adds an IP address to the list of allowed addresses for your app service, specifying a priority to manage the order of rules.

az webapp config access-restriction add \
--resource-group <RESOURCE_GROUP> \
--name <APP_SERVICE_NAME> \
--rule-name <RULE_NAME> \
--ip-address <IP_ADDRESS> \
--priority <PRIORITY> \
--action Allow

Remove an IP Restriction by Name
This command deletes an IP restriction by referencing the rule name.

az webapp config access-restriction remove \
--resource-group <RESOURCE_GROUP> \
--name <APP_SERVICE_NAME> \
--rule-name <RULE_NAME>

Step 2: Setting Up the Azure DevOps Pipeline
Now, we’ll create an ADO pipeline that uses these CLI commands. This pipeline will take three parameters: ruleName, ipAddress, and priority. If a rule with the specified name already exists, it will be deleted before adding the new IP restriction.

Here’s the complete YAML file for the pipeline:

trigger: none

parameters:
- name: ruleName
displayName: 'Name of the IP Rule'
type: string
default: ''
- name: ipAddress
displayName: 'IP Address to Allow'
type: string
default: ''
- name: priority
displayName: 'Priority of the Rule'
type: number # Corrected type from 'int' to 'number'
default: 100

jobs:
- job: ManageAppServiceIP
displayName: 'Manage App Service IP Whitelisting'
pool:
vmImage: 'ubuntu-latest'

steps:
- task: AzureCLI@2
displayName: 'Check and Update IP Restriction on App Service'
inputs:
azureSubscription: '<YOUR_AZURE_SERVICE_CONNECTION>'
scriptType: bash
scriptLocation: inlineScript
inlineScript: |
# Define variables
RESOURCE_GROUP="<RESOURCE_GROUP>"
APP_SERVICE_NAME="<APP_SERVICE_NAME>"
RULE_NAME="${{ parameters.ruleName }}"
IP_ADDRESS="${{ parameters.ipAddress }}"
PRIORITY="${{ parameters.priority }}"

echo "Checking if IP restriction rule exists for ${RULE_NAME}..."

# Check if the IP rule with the specified name already exists
EXISTING_RULE=$(az webapp config access-restriction show \
--resource-group $RESOURCE_GROUP \
--name $APP_SERVICE_NAME \
--query "ipSecurityRestrictions[?name=='$RULE_NAME']" \
-o tsv)

# If rule exists, delete it
if [[ -n "$EXISTING_RULE" ]]; then
echo "Rule ${RULE_NAME} exists. Deleting existing rule..."
az webapp config access-restriction remove \
--resource-group $RESOURCE_GROUP \
--name $APP_SERVICE_NAME \
--rule-name $RULE_NAME
echo "Existing rule ${RULE_NAME} deleted."
else
echo "No existing rule found for ${RULE_NAME}. Adding new rule."
fi

# Add the new IP restriction with priority
echo "Adding IP restriction for ${IP_ADDRESS} with name ${RULE_NAME} and priority ${PRIORITY}..."
az webapp config access-restriction add \
--resource-group $RESOURCE_GROUP \
--name $APP_SERVICE_NAME \
--rule-name $RULE_NAME \
--ip-address $IP_ADDRESS \
--priority $PRIORITY \
--action Allow
echo "IP restriction rule ${RULE_NAME} added successfully with priority ${PRIORITY}."

Step 3: Fixing YAML Errors in ADO
When working with YAML files in ADO, you may encounter validation errors. For example, if you receive an error like String does not match the pattern of “^boolean$”, it could indicate a type mismatch.

In our case, the type of priority was initially set to int, which Azure DevOps expects as number. Changing it from int to number resolved the error:

- name: priority
displayName: 'Priority of the Rule'
type: number # Set type to 'number' instead of 'int'
default: 100

Conclusion
Automating IP whitelisting for an Azure App Service saves time and reduces human error. By using an ADO pipeline, you ensure that IP restriction rules are managed consistently across environments. This setup is flexible, allowing you to update IP restrictions simply by providing new inputs when running the pipeline.

Tip: Consider adding notifications or approval steps in ADO if you’re managing critical IP whitelisting to prevent accidental overrides.
Happy automating!