Configure Live Data in Container insights

To view live data with Container insights from Azure Kubernetes Service (AKS) clusters, configure authentication to grant permission to access your Kubernetes data. This security configuration allows real-time access to your data through the Kubernetes API directly in the Azure portal.

This feature supports the following methods to control access to logs, events, and metrics:

• AKS without Kubernetes role-based access control (RBAC) authorization enabled
• AKS enabled with Kubernetes RBAC authorization
  • AKS configured with the cluster role binding clusterMonitoringUser
• AKS enabled with Microsoft Entra SAML-based single sign-on

These instructions require administrative access to your Kubernetes cluster. If you're configuring to use Microsoft Entra ID for user authentication, you also need administrative access to Microsoft Entra ID.

This article explains how to configure authentication to control access to the Live Data feature from the cluster:

• Kubernetes RBAC-enabled AKS cluster
• Microsoft Entra integrated AKS cluster

Authentication model

The Live Data feature uses the Kubernetes API, which is identical to the kubectl command-line tool. The Kubernetes API endpoints use a self-signed certificate, which your browser will be unable to validate. This feature uses an internal proxy to validate the certificate with the AKS service, ensuring the traffic is trusted.

The Azure portal prompts you to validate your sign-in credentials for a Microsoft Entra ID cluster. It redirects you to the client registration setup during cluster creation (and reconfigured in this article). This behavior is similar to the authentication process required by kubectl.

Users of this feature require the Azure Kubernetes Cluster User Role to access the cluster to download the kubeconfig and use this feature. Users do not require contributor access to the cluster to use this feature.

Use clusterMonitoringUser with Kubernetes RBAC-enabled clusters

To eliminate the need to apply more configuration changes to allow the Kubernetes user role binding clusterUser access to the Live Data feature after enabling Kubernetes RBAC authorization, AKS has added a new Kubernetes cluster role binding called clusterMonitoringUser. This cluster role binding has all the necessary permissions out of the box to access the Kubernetes API and the endpoints for using the Live Data feature.

To use the Live Data feature with this new user, you must be a member of the Azure Kubernetes Service Cluster User or Contributor role on the AKS cluster resource. Container insights, when enabled, is configured to authenticate by using clusterMonitoringUser by default. If the clusterMonitoringUser role binding doesn't exist on a cluster, clusterUser is used for authentication instead. Contributor gives you access to clusterMonitoringUser (if it exists), and Azure Kubernetes Service Cluster User gives you access to clusterUser. Any of these two roles give sufficient access to use this feature.

AKS released this new role binding in January 2020, so clusters created before January 2020 don't have it. If you have a cluster that was created before January 2020, the new clusterMonitoringUser can be added to an existing cluster by performing a PUT operation on the cluster. Or you can perform any other operation on the cluster that performs a PUT operation on the cluster, such as updating the cluster version.

Kubernetes cluster without Kubernetes RBAC enabled

If you have a Kubernetes cluster that isn't configured with Kubernetes RBAC authorization or integrated with Microsoft Entra single sign-on, you don't need to follow these steps. You already have administrative permissions by default in a non-RBAC configuration.

Configure Kubernetes RBAC authorization

When you enable Kubernetes RBAC authorization, clusterUser and clusterAdmin are used to access the Kubernetes API. This configuration is similar to running az aks get-credentials -n {cluster_name} -g {rg_name} without the administrative option. For this reason, clusterUser needs to be granted access to the endpoints in the Kubernetes API.

The following example steps demonstrate how to configure cluster role binding from this YAML configuration template.

1. Copy and paste the YAML file and save it as LogReaderRBAC.yaml.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
      name: containerHealth-log-reader
   rules:
       - apiGroups: ["", "metrics.k8s.io", "extensions", "apps"]
         resources:
            - "pods/log"
            - "events"
            - "nodes"
            - "pods"
            - "deployments"
            - "replicasets"
         verbs: ["get", "list"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
      name: containerHealth-read-logs-global
   roleRef:
      kind: ClusterRole
      name: containerHealth-log-reader
      apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: User
     name: clusterUser
     apiGroup: rbac.authorization.k8s.io
   

2. To update your configuration, run the command kubectl apply -f LogReaderRBAC.yaml.

Configure Microsoft Entra integrated authentication

An AKS cluster configured to use Microsoft Entra ID for user authentication uses the sign-in credentials of the person accessing this feature. In this configuration, you can sign in to an AKS cluster by using your Microsoft Entra authentication token.

Microsoft Entra client registration must be reconfigured to allow the Azure portal to redirect authorization pages as a trusted redirect URL. Users from Microsoft Entra ID are then granted access directly to the same Kubernetes API endpoints through ClusterRoles and ClusterRoleBindings.

For more information on advanced security setup in Kubernetes, review the Kubernetes documentation.

Client registration reconfiguration

1. Locate the client registration for your Kubernetes cluster in Microsoft Entra ID under Microsoft Entra ID > App registrations in the Azure portal.

2. On the left pane, select Authentication.

3. Add two redirect URLs to this list as Web application types. The first base URL value should be https://afd.hosting.portal.chinacloudapi.cn/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html. The second base URL value should be https://monitoring.hosting.portal.chinacloudapi.cn/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html.

   Note

   If you're using this feature in Microsoft Azure operated by 21Vianet, the first base URL value should be https://afd.hosting.azureportal.chinaloudapi.cn/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html. The second base URL value should be https://monitoring.hosting.azureportal.chinaloudapi.cn/monitoring/Content/iframe/infrainsights.app/web/base-libs/auth/auth.html.

4. After you register the redirect URLs, under Implicit grant, select the options Access tokens and ID tokens. Then save your changes.

You can configure authentication with Microsoft Entra ID for single sign-on only during initial deployment of a new AKS cluster. You can't configure single sign-on for an AKS cluster that's already deployed.

Grant permission

Each Microsoft Entra account must be granted permission to the appropriate APIs in Kubernetes to access the Live Data feature. The steps to grant the Microsoft Entra account are similar to the steps described in the Kubernetes RBAC authentication section. Before you apply the YAML configuration template to your cluster, replace clusterUser under ClusterRoleBinding with the desired user.

For more help in configuring your AKS cluster ClusterRoleBinding, see Create Kubernetes RBAC binding.

Next steps

Now that you've set up authentication, you can view metrics and events and logs in real time from your cluster.