AKS Deployment in Azure Stack Hub - Service principal identity (SPN)
zohebs341 opened this issue · 6 comments
Hi Team,
I am planning to deploy the k8s cluster using the AKS engine in Azure Stack Hub. In order to deploy the cluster, we need Service Principal details. My question is, can I create it using the below command and use it in the cluster creation process? How can I renew it in the future as the validation will be one year for that secret?
az ad sp create-for-rbac --name azurestack-aks-sp --query password -o tsv ----> It will be valid for 1 year, how about renewal?
As in documentation, it has been said that if the secret is expired then the cluster will not be operational/functional. Or do I need to contact the Azure Stack Hub cloud operator to provide Service Principal name/secret details by adding it to a contributor role at the subscription level?
Hi, @zohebs341! Opening issues in this AKS Engine repo unfortunately will not get you any answers about deploying AKS in Azure Stack Hub. Please open an issue in the Azure Stack Docs repo https://github.com/MicrosoftDocs/azure-stack-docs/issues so that team can guide you in the right direction - thanks!
Hello @zohebs341, I can answer quickly.
How can I renew it in the future as the validation will be one year for that secret?
You can either execute aks-engine upgrade using the new secret, deploy a new cluster or manually update /etc/kubernetes/azure.json on each node.
If the secret is expired then the cluster will not be operational/functional.
True, operations that require K8s to CRUD IaaS resources will fail.
Or do I need to contact the Azure Stack Hub cloud operator to provide Service Principal name/secret details
You would need just a new secret for the SPN.
@jadarsie Thank you Javier.
If I use aks-engine upgrade command with new SPN client ID/client Secret. It will just upgrade existing cluster right? Rather than creating a new cluster. I mean to say, existing VMs/LoadBalncers/ deployed applications will remain unchanged.
New Client ID & Secret with below command is fine I guess?
aks-engine upgrade
--azure-env AzureStackCloud
--location xyz
--resource-group kube-rg
--subscription-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
--api-model kube-rg/apimodel.json
--client-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
--client-secret xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
--force
I would also update servicePrincipalProfile just in case.
existing VMs/LoadBalncers/ deployed applications will remain unchanged
VMs will be recreated and pods moved around, storage is something else to consider, please read this.
Depending on your capacity/networking constraints and/or the type of deployed applications, it may be worthwhile considering a cluster upgrade process that consists of creating new clusters instead of upgrading existing ones.
@jadarsie Hi Javier.
For secrets, we can create an SPN first and then create a secret with an expiry of 2 years right? at least, in this case, the secret expiry will be for two years rather than one year.
yes you can