Contrôleur d'entrée Citrix ADC

Utilisation des informations d’identification Citrix ADC stockées dans un serveur Vault pour le Citrix ingress controller

Dans la plupart des entreprises, les appareils Citrix ADC Ingress de niveau 1 et les clusters Kubernetes sont gérés par des équipes distinctes. En général, les administrateurs réseau gèrent les appareils Citrix ADC Ingress de niveau 1, tandis que les développeurs gèrent les clusters Kubernetes. Le Citrix ingress controller nécessite des informations d’identification Citrix ADC telles que le nom d’utilisateur et le mot de passe Citrix ADC pour configurer Citrix ADC. Vous pouvez spécifier les informations d’identification Citrix ADC dans le cadre de la spécification du Citrix ingress controller et stocker les informations d’identification ADC en tant que secrets Kubernetes. Toutefois, vous pouvez également stocker les informations d’identification Citrix ADC dans un serveur Vault et transmettre les informations d’identification au Citrix ingress controller afin de minimiser tout risque de sécurité. Cette rubrique fournit des informations d’identification Citrix ADC stockées sur un serveur Vault pour le Citrix ingress controller.

Le schéma suivant explique les étapes d’utilisation des informations d’identification Citrix ADC qui sont stockées dans un serveur Vault avec le Citrix ingress controller.

vault-auto-authentication

Conditions préalables

Assurez-vous que vous avez configuré un serveur Vault et que le magasin de secrets clé-valeur (KV) est activé. Pour plus d’informations, consultez la documentation Vault.

Utilisation des informations d’identification Citrix ADC d’un serveur Vault pour le Citrix ingress controller

Effectuez les tâches suivantes pour utiliser les informations d’identification Citrix ADC d’un serveur Vault pour le Citrix ingress controller.

  1. Créez un compte de service pour l’authentification Kubernetes.

  2. Créez un secret Key Vault et configurez l’authentification Kubernetes sur le serveur Vault.

  3. Tirez parti de la fonctionnalité Auto-Auth de Vault pour récupérer les informations d’identification Citrix ADC pour le Citrix ingress controller.

Créez un compte de service pour l’authentification Kubernetes

Créez un compte de service pour l’authentification Kubernetes en suivant les étapes suivantes :

  1. Créez un compte de service cic-k8s-role et fournissez les autorisations nécessaires au compte de service pour accéder à l’API Kubernetes TokenReview à l’aide de la commande suivante.

    $ kubectl apply -f cic-k8s-role-service-account.yml
             
            
    serviceaccount/cic-k8s-role created
    clusterrole.rbac.authorization.k8s.io/cic-k8s-role configured
    clusterrolebinding.rbac.authorization.k8s.io/cic-k8s-role configured
    clusterrolebinding.rbac.authorization.k8s.io/role-tokenreview-binding configured
    

    Following is a part of the sample cic-k8s-role-service-account.yml file.

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
    name: role-tokenreview-binding
    namespace: default
    roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: system:auth-delegator
    subjects:
    - kind: ServiceAccount
    name: cic-k8s-role
    namespace: default
    
  2. Définissez la variable d’environnement VAULT_SA_NAME sur le nom du compte de service que vous avez déjà créé.

         export VAULT_SA_NAME=$(kubectl get sa cic-k8s-role -o jsonpath="{.secrets[*]['name']}")
    <!--NeedCopy-->
    
  3. Définissez la variable d’environnement SA_JWT_TOKEN sur le JWT du compte de service que vous avez utilisé pour accéder à l’API TokenReview.

         export SA_JWT_TOKEN=$(kubectl get secret $VAULT_SA_NAME -o jsonpath="{.data.token}" | base64 --decode; echo)
    <!--NeedCopy-->
    
  4. Obtenez un certificat signé par une autorité de certification Kubernetes pour communiquer avec l’API Kubernetes.

         export SA_CA_CRT=$(kubectl get secret $VAULT_SA_NAME -o jsonpath="{.data['ca.crt']}" | base64 --decode; echo)
    <!--NeedCopy-->
    

Créez un secret de coffre de clés et configurez l’authentification Kubernetes sur le serveur Vault

Connectez-vous au serveur Vault et effectuez les étapes suivantes pour créer un secret Key Vault et configurer l’authentification Kubernetes.

  1. Consultez l’exemple de fichier de stratégie de coffre citrix-adc-kv-ro.hcl et créez une stratégie en lecture seule, citrix-adc-kv-ro dans Vault.

    $ tee citrix-adc-kv-ro.hcl <<EOF 
    # If working with K/V v1
    path "secret/citrix-adc/*"
    {
        capabilities = ["read", "list"]
    }
    # If working with K/V v2
    path "secret/data/citrix-adc/*" 
    {
        capabilities = ["read", "list"]
    }
    EOF
    
    #  Create a policy named citrix-adc-kv-ro
    $  vault policy write citrix-adc-kv-ro citrix-adc-kv-ro.hcl
    
  2. Créez un secret KV avec des informations d’identification Citrix ADC sur le secret/citrix-adc/ chemin d’accès.

    vault kv put secret/citrix-adc/credential   username='<ADC username>' \
    password='<ADC password>' \
    ttl='30m'
    
  3. Activez l’authentification Kubernetes sur le chemin d’accès par défaut (auth/kubernetes).

    # $ vault auth enable kubernetes
    
  4. Spécifiez comment communiquer avec le cluster Kubernetes.

    $ vault write auth/kubernetes/config \
    token_reviewer_jwt="$SA_JWT_TOKEN" \
    kubernetes_host="https://<K8S_CLUSTER_URL>:<API_SERVER_PORT>" \
    kubernetes_ca_cert="$SA_CA_CRT"      
    
  5. Créez un rôle pour mapper le compte de service Kubernetes aux stratégies du coffre-fort et à la durée de vie du jeton par défaut. Ce rôle autorise le compte de cic-k8s-role service dans l’espace de noms par défaut et mappe le compte de service à la citrix-adc-kv-ro stratégie.

    $ vault write auth/kubernetes/role/cic-vault-example\
    bound_service_account_names=cic-k8s-role \
    bound_service_account_namespaces=default \
    policies=citrix-adc-kv-ro \
    ttl=24h
    

    Remarque :

    L’autorisation avec le back-end d’authentification Kubernetes est basée sur les rôles. Avant qu’un jeton ne soit utilisé pour la connexion, il doit être configuré dans le cadre d’un rôle.

Exploitez l’authentification automatique de l’agent Vault pour le Citrix ingress controller

Effectuez les étapes suivantes pour tirer parti de l’authentification automatique de Vault.

  1. Consultez le fichier de configuration de Vault Agent fourni, vault-agent-config.hcl.

        exit_after_auth = true
        pid_file = "/home/vault/pidfile"
    
        auto_auth {
            method "kubernetes" {
                mount_path = "auth/kubernetes"
                config = {
                    role = "cic-vault-example"
                }
            }
    
            sink "file" {
                config = {
                    path = "/home/vault/.vault-token"
                }
            }
        }
    

    Remarque :

    L’agent Vault Auto-Auth est configuré pour utiliser la méthode d’authentification Kubernetes activée sur le auth/kubernetes chemin d’accès sur le serveur Vault. L’agent Vault utilise le cic-vault-example rôle pour s’authentifier. Le bloc récepteur spécifie l’emplacement sur le disque où écrire les jetons. Le Auto-Auth récepteur Vault Agent peut être configuré plusieurs fois si vous souhaitez que Vault Agent place le jeton à plusieurs emplacements. Dans cet exemple, le lavabo est réglé sur /home/vault/.vault-token.

  2. Consultez le fichier consul-template-config.hcl du modèle Consul.

        vault {
            renew_token = false
            vault_agent_token_file = "/home/vault/.vault-token"
            retry {
                backoff = "1s"
            }
        }
    
        template {
            destination = "/etc/citrix/.env"
            contents = <<EOH
            NS_USER=
            NS_PASSWORD=
                
            EOH
        }
    

    This template reads secrets at the secret/citrix-adc/credential path and sets the user name and password values. If you are using KV store version 1, use the following template.

        template {
            destination = "/etc/citrix/.env"
            contents = <<EOH
            NS_USER=
            NS_PASSWORD=
                
            EOH
                }
    
  3. Créez une config-map Kubernetes à partir de vault-agent-config.hcl et consul-template-config.hcl.

        kubectl create configmap example-vault-agent-config --from-file=./vault-agent-config.hcl --form-file=./consul-template-config.hcl
    
  4. Créez un espace Citrix ingress controller avec Vault et un modèle de consul en tant que conteneur d’initialisation citrix-k8s-ingress-controller-vault.yaml. Vault récupère le jeton à l’aide de la méthode d’authentification Kubernetes et le transmet à un modèle de consul qui crée le .env fichier sur le volume partagé. Ce jeton est utilisé par le Citrix ingress controller pour l’authentification auprès de Citrix ADC de niveau 1.

        kubectl apply citrix-k8s-ingress-controller-vault.yaml
    

    Le fichier citrix-k8s-ingress-controller-vault.yaml se présente comme suit :

            apiVersion: v1
            kind: Pod
            metadata:
            annotations:
            name: cic-vault
            namespace: default
            spec:
            containers:
            - args:
                - --ingress-classes tier-1-vpx
                - --feature-node-watch true
                env:
                - name: NS_IP
                value: <Tier 1 ADC IP-ADDRESS>
                - name: EULA
                value: "yes"
                image: in-docker-reg.eng.citrite.net/cpx-dev/kumar-cic:latest
                imagePullPolicy: Always
                name: cic-k8s-ingress-controller
                volumeMounts:
                - mountPath: /etc/citrix
                name: shared-data
            initContainers:
            - args:
                - agent
                - -config=/etc/vault/vault-agent-config.hcl
                - -log-level=debug
                env:
                - name: VAULT_ADDR
                value: <VAULT URL>
                image: vault
                imagePullPolicy: Always
                name: vault-agent-auth
                volumeMounts:
                - mountPath: /etc/vault
                name: config
                - mountPath: /home/vault
                name: vault-token
            - args:
                - -config=/etc/consul-template/consul-template-config.hcl
                - -log-level=debug
                - -once
                env:
                - name: HOME
                value: /home/vault
                - name: VAULT_ADDR
                value: <VAULT_URL>
                image: hashicorp/consul-template:alpine
                imagePullPolicy: Always
                name: consul-template
                volumeMounts:
                - mountPath: /home/vault
                name: vault-token
                - mountPath: /etc/consul-template
                name: config
                - mountPath: /etc/citrix
                name: shared-data
            serviceAccountName: vault-auth
            volumes:
            - emptyDir:
                medium: Memory
                name: vault-token
            - configMap:
                defaultMode: 420
                items:
                - key: vault-agent-config.hcl
                    path: vault-agent-config.hcl
                - key: consul-template-config.hcl
            name: example-vault-agent-config
                name: config
            - emptyDir:
                medium: Memory
                name: shared-data        
    

Si la configuration est réussie, le serveur Vault récupère un jeton et le transmet à un conteneur de modèles Consul. Le modèle Consul utilise le jeton pour lire les informations d’identification Citrix ADC et l’écrire en tant que variable d’environnement dans le chemin d’accès /etc/citrix/.env. Le Citrix ingress controller utilise ces informations d’identification pour communiquer avec le Citrix ADC de niveau 1.

Vérifiez que le Citrix ingress controller fonctionne correctement à l’aide des informations d’identification récupérées sur le serveur Vault.

Utilisation des informations d’identification Citrix ADC stockées dans un serveur Vault pour le Citrix ingress controller