azure

func (*Azure) DeleteResourceGroup ¶

func (a *Azure) DeleteResourceGroup(ctx context.Context)

func (*Azure) GetSealedSecretsBackupBucketName ¶

func (a *Azure) GetSealedSecretsBackupBucketName() string

func (*Azure) GetVMSpecs ¶

func (a *Azure) GetVMSpecs(ctx context.Context, vmType string) *cloud.VMSpec

func (*Azure) SetupDisasterRecovery ¶

func (a *Azure) SetupDisasterRecovery(ctx context.Context)

func (*Azure) SetupWorkloadIdentityProvider ¶

func (a *Azure) SetupWorkloadIdentityProvider(ctx context.Context)

Workloads deployed in Kubernetes clusters require Azure AD application credentials or managed identities to access Azure AD protected resources, such as Azure Key Vault and Microsoft Graph.

The Azure AD Pod Identity open-source project provided a way to avoid needing these secrets, by using Azure managed identities.

Azure AD Workload Identity for Kubernetes integrates with the capabilities native to Kubernetes to federate with external identity providers. This approach is simpler to use and deploy, and overcomes several limitations in Azure AD Pod Identity :

(1) Removes the scale and performance issues that existed for identity assignment

(2) Supports Kubernetes clusters hosted in any cloud or on-premises

(3) Supports both Linux and Windows workloads

(4) Removes the need for Custom Resource Definitions and pods that intercept Instance Metadata
    Service (IMDS) traffic

(5) Avoids the complication and error-prone installation steps such as cluster role assignment
    from the previous iteration.

In this model, the Kubernetes cluster becomes a token issuer, issuing tokens to Kubernetes Service Accounts. These service account tokens can be configured to be trusted on Azure AD applications or user-assigned managed identities. A workload can exchange a service account token projected to its volume for an Azure AD access token using the Azure Identity SDKs or the Microsoft Authentication Library (MSAL).

You can read more here : https://azure.github.io/azure-workload-identity/docs/.

The workflow looks like this :

(1) The Kubernetes workload sends the signed ServiceAccount token in a request, to Azure Active
    Directory (AAD).

(2) AAD will then extract the OpenID provider issuer discovery document URL from the request
    and fetch it from Azure Storage Container.

(3) AAD will extract the JWKS document URL from that OpenID provider issuer discovery document
    and fetch it as well.

    The JSON Web Key Sets (JWKS) document contains the public signing key(s) that allows AAD to
    verify the authenticity of the service account token.

(4) AAD will use the public signing key(s) to verify the authenticity of the ServiceAccount
    token.

    Finally it'll return an AAD token, back to the Kubernetes workload.

You can view the sequence diagram here : https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters/oidc-issuer.html#sequence-diagram.

func (*Azure) UpdateCapiClusterValuesFileWithCloudSpecificDetails ¶

func (a *Azure) UpdateCapiClusterValuesFileWithCloudSpecificDetails(ctx context.Context,
	capiClusterValuesFilePath string,
	_updates any,
)

func (*Azure) UpdateMachineTemplate ¶

func (a *Azure) UpdateMachineTemplate(ctx context.Context, clusterClient client.Client, _updates any)