Blog Post

Apps on Azure Blog
2 MIN READ

Simplify Your Azure Kubernetes Service Connection Configuration with Service Connector

CocoWang's avatar
CocoWang
Icon for Microsoft rankMicrosoft
May 24, 2024

Workloads deployed on an Azure Kubernetes Service (AKS) cluster often need to access Azure backing resources, such as Azure Key Vault, databases, or AI services like Azure OpenAI Service. Users are required to manually configure Microsoft Entra Workload ID or Managed Identities so their AKS workloads can securely access these protected resources.

The Service Connector integration greatly simplifies the connection configuration experience for AKS workloads and Azure backing services. Service Connector takes care of authentication and network configurations securely and follows Azure best practices, so you can focus on your application code without worrying about your infrastructure connectivity.

Service Connector Action Breakdown

 

Before, in order to connect from AKS pods to a private Azure backing services using workload identity, users needed to perform the following actions manually:

  1. Create a managed identity
  2. Retrieve the OIDC issuer URL
  3. Create Kubernetes service account
  4. Establish federated identity credential trust
  5. Grant permissions to access Azure Services
  6. Deploy the application

Now, Service Connector performs steps 2 to 5 automatically. Additionally, for Azure services without public access, Service Connector creates private connection components such as private link, private endpoint, DNS record,

You can create a connection in the Service Connection blade within AKS.

 

Click create and select the target service, authentication method, and networking rule. The connection will then be automatically set up. Here are a few helpful links to for you to learn more about Service Connector.

 

 

 

 

 

 

Updated May 30, 2024
Version 6.0
  • CarFre's avatar
    CarFre
    Copper Contributor

    This detail explanation show that Microsoft promote now a new solution to by pass the workflow of constructing other adjacent resource to trust the connection.

    Is the a way to limit the access of a service connection to a dedicated namespace or pod?

    If this resource is accessible from all pods using it can we open a security hole.

  • AidanB990's avatar
    AidanB990
    Copper Contributor

    Can you advise on the timescale for this going GA - I am keen to use the connector for Keyvault in Production