How to access AKS cluster using FQDN

Question

I am using Terraform for cluster provisioning

This my script

resource "azurerm_resource_group" "rg" {
  name     = var.resource_group_name
  location = var.location
}

# Private DNS
resource "azurerm_private_dns_zone" "ahasa-private" {
  name                = "abhi.io"
  resource_group_name = azurerm_resource_group.rg.name
}

# AKS Cluster

resource "azurerm_kubernetes_cluster" "cluster" {
  name                = var.cluster_name
  location            = azurerm_resource_group.rg.location
  resource_group_name = azurerm_resource_group.rg.name
  dns_prefix          = "learnk8scluster"

  default_node_pool {
    name       = var.default_pool_name
    node_count = var.node_count
    vm_size    = var.vm_size
    os_disk_size_gb = var.os_disk_size_gb
    enable_auto_scaling = true
    min_count           = var.min_count
    max_count           = var.
    type                 = "VirtualMachineScaleSets"
  }
    
  identity {
    type = "SystemAssigned"
  }
}

if i type kubectl cluster-info i can see

And if i try to access CoreDNS url in browser it comes like this

what is the reason for it. How can i access AKS cluster FQDN

Answer 1

Kubernetes uses client certificates, bearer tokens, an authenticating proxy, or HTTP basic auth to authenticate API requests through authentication plugins. For more on authentication to the API server please check here. AKS does not allow Anonymous access to the API server which is why you are getting the following:

{
  ...
  "status": "Failure",
  "message": "Unauthorized",
  "reason": "Unauthorized",
  "code": 401
}

Directly accessing the REST API

kubectl handles locating and authenticating to the API server. If you want to directly access the REST API with an http client like curl or wget, or a browser, there are multiple ways you can locate and authenticate against the API server:

1. Run kubectl in proxy mode (recommended). This method is recommended, since it uses the stored apiserver location and verifies the identity of the API server using a self-signed cert. No man-in-the-middle (MITM) attack is possible using this method.
2. Alternatively, you can provide the location and credentials directly to the http client. This works with client code that is confused by proxies. To protect against man in the middle attacks, you'll need to import a root cert into your browser.

---

Here is a bunch of steps that should get you started:

SERVICE_ACCOUNT=my-service-account
#-- Create a service Account
kubectl create serviceaccount $SERVICE_ACCOUNT
#-- Create clusterrolebinding for the service account to cluster-admin clusterrole (be very cautious while assigning cluster-admin privileges)
kubectl create clusterrolebinding my-clusterrolebinding --clusterrole cluster-admin --serviceaccount default:$SERVICE_ACCOUNT
#-- Get the ServiceAccount's token Secret's name
$ SECRET=$(kubectl get serviceaccount ${SERVICE_ACCOUNT} -o json | jq -Mr '.secrets[].name | select(contains("token"))')
#-- Extract the Bearer token from the Secret and decode
$ TOKEN=$(kubectl get secret ${SECRET} -o json | jq -Mr '.data.token' | base64 -d)
#-- Extract, decode and write the ca.crt to a temporary location
$ kubectl get secret ${SECRET} -o json | jq -Mr '.data["ca.crt"]' | base64 -d > /tmp/ca.crt
#-- Access CoreDNS API endpoint
curl -s <CoreDNS_URL>  --header "Authorization: Bearer $TOKEN" --cacert /tmp/ca.crt

Note: his script relies on jq. You can alternatively use jsonpath as well.