En el presente documento describelos comandos kubectl a jecutar para adecuar los clusters AKS para usar KEYVAULT.

Especialmente para los clusters creados antes de Octubre del 2020.!!!!
En caso el cluster haya sido creado despues del 2020 usando los lienamientos de AD, los drivers de CSI para usar KEyvault con AKS ya fueron instlados en los clustes AKS al momento de su creacion. Solo verificar que se hayn creado los secretos por Ingenieriau OPeraciones.

1. CONTROL DE VERSIONES DEL DOCUMENTO


Autor	Javier Caparo
Version	1.0
Fecha	07/07/2021

2. PRE REQUISITOS

Tener kubectl y helm instalados en la Shell desde donde se va trabajar
Version de AKS >= 1.16

$ kubectl get nodes
NAME                                STATUS   ROLES   AGE     VERSION
aks-nodepool1-42196441-vmss000000   Ready    agent   2d23h   v1.19.9
aks-nodepool1-42196441-vmss000001   Ready    agent   2d23h   v1.19.9
$

El cluster AKS debe tener los drivers CSI instalados ( se deben ver 4 lineas : 2 store provider, 2 de store csi driver)

$ kubectl --namespace=csi-storage get pods
NAME                                                 READY   STATUS    RESTARTS   AGE
csi-secrets-csi-secrets-store-provider-azure-89shm   1/1     Running   0          17m
csi-secrets-csi-secrets-store-provider-azure-8r8vh   1/1     Running   0          17m
csi-secrets-secrets-store-csi-driver-knbp2           3/3     Running   0          17m
csi-secrets-secrets-store-csi-driver-q2whb           3/3     Running   0          17m
$

3. Si los drivers no estan instalados como los instalo?

Necesito tener HELM instalado

Crear el namespace “csi-storage”:
$ kubectl create ns csi-storage

Agregar el repo de Helm para agregar los CSI drivers:

$ helm repo add csi-secrets-store-provider-azure https://raw.githubusercontent.com/Azure/secrets-store-csi-driver-provider-azure/master/charts

Instalar los drivers de CSI en el AKS cluster:

$ helm install csi-secrets csi-secrets-store-provider-azure/csi-secrets-store-provider-azure -n csi-storage

Verificar que los drivers estén instalados , igual que en el paso inicial

$ kubectl --namespace=csi-storage get pods
NAME                                                 READY   STATUS    RESTARTS   AGE
csi-secrets-csi-secrets-store-provider-azure-89shm   1/1     Running   0          17m
csi-secrets-csi-secrets-store-provider-azure-8r8vh   1/1     Running   0          17m
csi-secrets-secrets-store-csi-driver-knbp2           3/3     Running   0          17m
csi-secrets-secrets-store-csi-driver-q2whb           3/3     Running   0          17m
$

4. VERIFICAR en clusters a los que se les hizo update a 1.19.9 ( clusters creados en los años 2018, 2019 y antes de Octubre del 2020

Ejecutar estos yaml files para agregar un Cluster Role y Cluster Role Binding al Secret Provider: copiar las lineas de abajo en un archivo con el nombre que prefieran ( ejemplo: roles.yaml) y y usar kubectl apply –f roles.yaml

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: secretprovidersyncing-role
rules:
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: secretprovidersyncing-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: secretprovidersyncing-role
subjects:
- kind: ServiceAccount
  name: secrets-store-csi-driver
  namespace: csi-storage

Verificar que fueron agregados con commando

kubectl get rolebindings,clusterrolebindings --all-namespaces -o custom-columns='KIND:kind,NAMESPACE:metadata.namespace,NAME:metadata.name,SERVICE_ACCOUNTS:subjects[?(@.kind=="ServiceAccount")].name' | grep secretprovider

Resultado similar a este:

ClusterRoleBinding   <none>               secretproviderclasses-rolebinding                      secrets-store-csi-driver
ClusterRoleBinding   <none>               secretprovidersyncing-rolebinding                      secrets-store-csi-driver

5 Y si los drivers estan ya instalados, que sigue? Dar Acceso a Keyvault desde AKS

PREREQUISITOS 1: Tener un KeyVault ya creado y registrado en el Azure AD ( Active Directory) que tenga un SP ( Service Principal ) y tener como datos el Client ID y el Client Secret de esa App de KeyVault en el Azure AD

Client ID : xxxx-xxxx-xxxx-xxxx Client Secret : : yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

PREREQUISITOS 2: El nombre de la mesa es el nombre del namespace ( team namespace). Ejemplo

Mesa visor : namespace==visor Mesa genesis : namespace == genesis

Agregar esos 2 parámetros ( Client ID , Y , Client Secret) como SECRETS en el AKS y adicionalmente agregar un label , en el namespace de la mesa ( ejemplo: ( -n mta : ‘o -n visor). (# Refer to https://secrets-store-csi-driver.sigs.k8s.io/load-tests.html for more details on why this is necessary in future releases.) ( Reemplzar los valores de los pre requisites donde corresponde – no incluir los <> obviamente):

$ kubectl create secret generic secrets-store-creds --from-literal clientid=<AZURE_CLIENT_ID> --from-literal clientsecret=<AZURE_CLIENT_SECRET> -n <team namespace>

$kubectl label secret secrets-store-creds secrets-store.csi.k8s.io/used=true -n <team namespace>

Revisar que se hayan creado ( de tipo Opaque) :

$ kubectl get secret secrets-store-creds -n <team namespace)

Ejemplo:

$ kubectl get secret secrets-store-creds -n genesis
NAME                  TYPE     DATA   AGE
secrets-store-creds   Opaque   2      12d

6. Errores comunes:

Hemos observado que en los clusters antiguos, cuando tratan de instalar el microservicio de “Config Server”, este hace Crash en el Kubernetes, (se despliega pero el pod no sube ).
Este error puede ser porque que durante el upgrade y luego de la intalacion de los CSI drivers, no se hayan creado el CLuster Role y Cluster Role Binding del SecretProvider.
Estos son los logs de los pods del tipo csi-secrets-secrets-store-csi-driver-xxxxx en el container de secrets-store donde se obtienen errores como estos:

I0706 16:55:59.178681       1 nodeserver.go:300] "Using grpc client" provider="azure" pod="ms-genesis-config-server-85c78f8697-qzkwp"
I0706 16:55:59.321039       1 nodeserver.go:73] "unmounting target path as node publish volume failed" targetPath="/var/lib/kubelet/pods/50388112-12e2-4e43-807b-113b43758893/volumes/kubernetes.io~csi/secrets-store-inline/mount" pod="genesis/ms-genesis-config-server-85c78f8697-qzkwp"
E0706 16:55:59.323233       1 utils.go:79] GRPC error: failed to mount secrets store objects for pod genesis/ms-genesis-config-server-85c78f8697-qzkwp, err: rpc error: code = Unknown desc = failed to mount objects, error: failed to get objectType:secret, objectName:AZURE-KEYVAULT-CLIENT-ID, objectVersion:: keyvault.BaseClient#GetSecret: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="Forbidden" Message="The user, group or application 'appid=fa912d6a-24d4-4111-bd93-5d9781b6044a;oid=e7f2e17a-a190-4faf-85de-8ef1380e2649;iss=https://sts.windows.net/929616ff-818c-4541-b071-2bd6ab912e88/' does not have secrets get permission on key vault 'KV-genesis-prod;location=eastus2'. For help resolving this issue, please see https://go.microsoft.com/fwlink/?linkid=2125287" InnerError={"code":"AccessDenied"}
..
E0706 21:39:06.597075       1 reflector.go:138] pkg/mod/k8s.io/client-go@v0.20.2/tools/cache/reflector.go:167: Failed to watch *v1.Secret: failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:csi-storage:secrets-store-csi-driver" cannot list resource "secrets" in API group "" at the cluster scope

Lo normal es que no presente errores, sino algo como esto

Have fun!!