3

I am using kubectl to control Kubernetes Service on Azure (scaling, getting pod status). Is it safe to call kubectl automatically in a script on production and not worry that the credentials will expire?

This is what I did once on the production server (required manual login via web page) (os is Windows Server 2016):

az login
az account set --subscription="S"
az aks get-credentials --resource-group R --name C

This is what is being run in a script/application:

kubectl get pods

Can I be sure the last call will just work from now on (and will not require manual login on a sunday night)?

user1713059
  • 1,425
  • 2
  • 17
  • 34

3 Answers3

2

To control the Azure Kubernetes service, you need permission to perform the actions. So the core of safety is permission. You can use the service principal with the right permission you need without interaction. So the az login could be changed into this:

az login --service-principal -u service_principal_app_id -p service_principal_secret

To get the credentials to access the cluster, there two permission:

Azure Kubernetes Service Cluster Admin Role or Azure Kubernetes Service Cluster User Role

You can get more details here and decide which to use. You can set the expiry date for the service principal, take a look at another issue.

Charles Xu
  • 29,862
  • 2
  • 22
  • 39
0

find below recommendations

  1. It is perfectly fine to use those commands
  2. Instead of individual id, suggest you use service principal and secret to login to azure
P Ekambaram
  • 15,499
  • 7
  • 34
  • 59
0

az aks get-credentials basically generates a kubernetes config file for you in ~/.kube/config which includes cluster information and a client certificate to access the kubernetes api server. kubectl uses this configuration file by default.

You can also use a different config file location. If your script has access to this config file, it should just work.

Markus Dresch
  • 5,290
  • 3
  • 20
  • 40