diff --git a/content/rancher/v2.6/en/cluster-admin/editing-clusters/aks-config-reference/_index.md b/content/rancher/v2.6/en/cluster-admin/editing-clusters/aks-config-reference/_index.md index 02b70c5ee55..1b522f15ad3 100644 --- a/content/rancher/v2.6/en/cluster-admin/editing-clusters/aks-config-reference/_index.md +++ b/content/rancher/v2.6/en/cluster-admin/editing-clusters/aks-config-reference/_index.md @@ -21,10 +21,6 @@ Rancher can configure member roles for AKS clusters in the same way as any other > The configuration information in this section assumes you have already set up a service principal for Rancher. For step-by-step instructions for how to set up the service principal, see [this section.]({{}}/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/aks/#prerequisites-in-microsoft-azure) -### Tenant ID - -To get the tenant ID, go to the Azure Portal, then click **Azure Active Directory**, then click **App registrations**, then click the name of the service principal. The tenant ID is listed on the app registration detail page as **Directory (tenant) ID**. - ### Subscription ID To get the subscription ID, click **All Services** in the left navigation bar. Then click **Subscriptions**. Go to the name of the subscription that you want to associate with your Kubernetes cluster and copy the **Subscription ID**. diff --git a/content/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/aks/_index.md b/content/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/aks/_index.md index 64157308900..e3aa18629c8 100644 --- a/content/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/aks/_index.md +++ b/content/rancher/v2.6/en/cluster-provisioning/hosted-kubernetes-clusters/aks/_index.md @@ -27,7 +27,6 @@ To interact with Azure APIs, an AKS cluster requires an Azure Active Directory ( Before creating the service principal, you need to obtain the following information from the [Microsoft Azure Portal](https://portal.azure.com): - Subscription ID -- Tenant ID - Client ID - Client secret @@ -84,7 +83,7 @@ You can also follow these instructions to set up a service principal and give it 1. Optional: Choose which accounts can use the service principal. 1. Click **Register**. 1. You should now see the name of your service principal under **Azure Active Directory > App registrations**. -1. Click the name of your service principal. Take note of the tenant ID and application ID (also called app ID or client ID) so that you can use it when provisioning your AKS cluster. Then click **Certificates & secrets**. +1. Click the name of your service principal. Take note of the application ID (also called app ID or client ID) so that you can use it when provisioning your AKS cluster. Then click **Certificates & secrets**. 1. Click **New client secret**. 1. Enter a short description, pick an expiration time, and click **Add**. Take note of the client secret so that you can use it when provisioning the AKS cluster. diff --git a/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/azure/_index.md b/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/azure/_index.md index d771d0804e4..44f87a9da3a 100644 --- a/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/azure/_index.md +++ b/content/rancher/v2.6/en/cluster-provisioning/rke-clusters/node-pools/azure/_index.md @@ -32,7 +32,7 @@ az ad sp create-for-rbac \ --scopes="/subscriptions/" ``` -The creation of this service principal returns three pieces of identification information, *The application ID, also called the client ID*, *The client secret*, and *The tenant ID*. This information will be used when you create a node template for Azure. +The creation of this service principal returns three pieces of identification information, *The application ID, also called the client ID*, and *The client secret*. This information will be used when you create a node template for Azure. # Creating an Azure Cluster @@ -91,4 +91,4 @@ You can access your cluster after its state is updated to **Active**. After creating your cluster, you can access it through the Rancher UI. As a best practice, we recommend setting up these alternate ways of accessing your cluster: - **Access your cluster with the kubectl CLI:** Follow [these steps]({{}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#accessing-clusters-with-kubectl-on-your-workstation) to access clusters with kubectl on your workstation. In this case, you will be authenticated through the Rancher server’s authentication proxy, then Rancher will connect you to the downstream cluster. This method lets you manage the cluster without the Rancher UI. -- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps]({{}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster. \ No newline at end of file +- **Access your cluster with the kubectl CLI, using the authorized cluster endpoint:** Follow [these steps]({{}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/#authenticating-directly-with-a-downstream-cluster) to access your cluster with kubectl directly, without authenticating through Rancher. We recommend setting up this alternative method to access your cluster so that in case you can’t connect to Rancher, you can still access the cluster.