Accéder à la page des orchestrateurs externes
La page principale pour les orchestrateurs externes est accessible en sélectionnant
dans la barre de menus à gauche.Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco peut fournir des traductions du présent contenu dans la langue locale pour certains endroits. Veuillez noter que des traductions sont fournies à titre informatif seulement et, en cas d’incohérence, la version anglaise du présent contenu prévaudra.
Les orchestrateurs externes sont utilisés pour rassembler les métadonnées existantes décrivant vos charges de travail à partir des systèmes de votre réseau. Certains orchestrateurs externes peuvent également appliquer la politique de segmentation.
Pour les déploiements pour lesquels un système d’enregistrement autorisé avec des étiquettes pour les charges de travail existe, nous offrons un moyen d’importer automatiquement les étiquettes au moyen d’intégrations d’orchestrateurs externes. Toute modification dans le système d’enregistrement sera apprise automatiquement par Cisco Secure Workload et utilisée pour la mise à jour des étiquettes de votre inventaire.
Pour des renseignements détaillés sur la puissance et les utilisations des étiquettes, consultez Étiquettes de charge de travail.
En raison des récentes mises à jour de l'interface graphique, certaines images ou captures d'écran utilisées dans le guide de l'utilisateur peuvent ne pas refléter pleinement la conception actuelle du produit. Nous recommandons d'utiliser ce guide en conjonction avec la dernière version du logiciel pour obtenir la référence visuelle la plus précise.
La page principale pour les orchestrateurs externes est accessible en sélectionnant
dans la barre de menus à gauche.La page External Orchestrateurs (Orchestrateurs externes) affiche les orchestrateurs externes existants et fournit des fonctions pour les modifier et les supprimer ainsi que pour en créer de nouveaux :
Type |
Description/Quand l’utiliser |
---|---|
VMware vCenter |
Pour importer les données de la machine virtuelle, tels que le nom d’hôte, l’adresse IP et les étiquettes, d’un serveur vCenter vers Cisco Secure Workload. Les étiquettes générées peuvent être utilisées pour créer des portées et des politiques d’application Cisco Secure Workload. |
Amazon Web Services |
(Vous ne pouvez pas créer de nouveaux orchestrateurs AWS; créez plutôt des connecteurs AWS. Consultez la section Connecteur AWS. Tous les orchestrateurs AWS existants sont en lecture seule). Pour importer les données des instances de serveur EC2, telles que le nom d’hôte, l’adresse IP et les étiquettes, depuis le compte AWS vers Cisco Secure Workload. Les étiquettes générées sont utiles pour créer des portées et des politiques Cisco Secure Workload. |
Kubernetes/OpenShift |
Pour importer les entités de Kubernetes, telles que les nœuds, les pods, les services et les étiquettes. Ces étiquettes peuvent être utilisées au sein de Cisco Secure Workload pour définir des portées et des politiques. |
DNS |
Pour importer des enregistrements A/AAAA et CNAME à partir d’un serveur DNS par transfert de zone. Cela produit des noms DNS sous forme d’étiquettes, qui sont utiles pour définir les portées et les politiques Cisco Secure Workload. |
Infoblox |
Pour importer des réseaux, des hôtes et des enregistrements A/AAAA avec des attributs extensibles à partir d’un appareil Infoblox avec IPAM/DNS activé. Les attributs extensibles importés peuvent être utilisés comme étiquettes dans les portées et les politiques Cisco Secure Workload. |
F5 BIG-IP |
Pour lire les configurations de serveur virtuel à partir d’un équilibreur de charge F5 donné et générer des étiquettes pour les services fournis, qui peuvent être utilisés pour définir les politiques d’application dans Cisco Secure Workload. La fonction d’application de la politique les traduira en règles F5 à l’aide de l’API REST F5. |
Citrix Netscaler |
Pour lire les configurations de serveur virtuel à partir d'un équilibreur de charge Netscaler donné et générer des étiquettes pour les services fournis, qui peuvent être utilisés pour définir des politiques d’application dans Cisco Secure Workload. La fonctionnalité d’application des politiques les traduira en ACL Netscaler via son API REST. |
Cisco Secure Firewall Management Center |
Pour déployer les politiques sur tous les périphériques Cisco Secure Firewall Threat Defense (anciennement Firepower Threat Defense ou FTD) enregistrés sur Cisco Secure Firewall Management Center à l’aide de l’API REST. |
Chaque ligne affiche une version abrégée de l’orchestrateur externe comportant son nom, son type, sa description, son application, son statut Créé à, l’état de la connexion et l’état du connecteur sécurisé Secure Connector. L’état de la connexion indique si une connexion à une source de données externe a pu être établie avec succès. Secure Connector Status (État du connecteur sécurisé) affiche l’état du tunnel Secure Connector (succès ou échec). Si le tunnel n’est pas activé, N/A s’affiche.
Activez le tunnel du connecteur sécurisé lors de la création d’une configuration d’orchestrateur externe. Si le tunnel de connecteur sécurisé est activé, « l’état de la connexion » de l’orchestrateur externe dépend à la fois de l’état d’authentification et de l’état du connecteur sécurisé. Si le tunnel du connecteur sécurisé n’est pas activé, « l’état de la connexion » de l’orchestrateur externe dépend uniquement de l’état d’authentification. Quel que soit l’état (réussite ou échec), vous pouvez cliquer sur la ligne respective pour obtenir plus de détails. Pour plus de détails sur les mesures du client du connecteur sécurisé, cliquez sur la ligne Status (État) ou, dans le volet gauche, accédez à
.Un orchestrateur externe peut être créé en cliquant sur le bouton Create New Configuration (Créer une nouvelle configuration) dans la page principale des orchestrateurs externes. Une boîte de dialogue modale s'ouvre, dans laquelle vous pouvez saisir un nom et choisir un type d'orchestrateur externe. L’image ci-dessous montre la page de configuration de base :
Le tableau suivant décrit les champs communs aux orchestrateurs externes. Selon le type sélectionné, la page de configuration de base nécessite la saisie de paramètres supplémentaires. Ceux-ci seront couverts par la section respective des orchestrateurs externes individuels ci-dessous.
Champs communs |
Obligatoire |
Description |
---|---|---|
Type |
Oui |
Sélectionnez un orchestrateur externe dans la liste. |
Nom |
Oui |
Nom de l’orchestrateur externe, qui doit être unique pour le détenteur actif. |
Description |
Non |
Description de l’orchestrateur externe. |
Intervalle(s) complet(s) de l’instantané |
Oui |
Intervalle en secondes pendant lequel l’orchestrateur externe tentera d’importer l’instantané complet de la configuration à partir du Type sélectionné. |
Accept Self-signed Cert (Accepter le certificat autosigné) |
Non |
Cochez cette option pour accepter les certificats de serveur autosignés pour la connexion HTTPS utilisée par Cisco Secure Workload afin de récupérer les données de configuration du Type. Par défaut, les certificats de serveur autosignés ne sont pas autorisés. |
Secure Connector Tunnel (Tunnel du connecteur sécurisé) |
Non |
Cochez cette option pour définir les connexions à la grappe Cisco Secure Workload pour qu’elles soient acheminées par un tunnel de connecteur sécurisé. |
![]() Note |
Les champs Intervalle différentiel et Mesures TSDB détaillées, comme le montre l’image ci-dessus sont facultatifs et applicables uniquement à certains orchestrateurs externes, qui sont présentés dans les descriptions respectives ci-dessous. |
À l’exception du type d’orchestrateur externe AWS, la Hosts List (Liste des hôtes) doit être fournie. Elle spécifie les adresses réseau de la source de données externe à partir de laquelle l’orchestrateur externe récupérera les données et générera des étiquettes. Pour ce faire, cliquez sur l’onglet Hosts List (liste des hôtes) sur le côté gauche, comme le montre l’image suivante :
Pour ajouter une nouvelle entrée à la liste d’hôtes, cliquez sur le signe +. Chaque ligne doit contenir un nom d’hôte DNS valide, une adresse IPv4 ou IPv6 et un numéro de port. Selon le type d’orchestrateur externe choisi, vous pouvez saisir plusieurs hôtes à des fins de haute disponibilité ou de redondance. Pour en savoir plus, consultez la description de l’orchestrateur externe choisi.
Pour définir l’alerte pour l’orchestrateur externe, vous pouvez le faire en cliquant sur l’onglet Alerte sur le côté gauche, comme le montre l’image suivante :
Pour chaque orchestrateur externe, la configuration des alertes nécessite que des paramètres supplémentaires soient fournis. Ceux-ci seront couverts par la section respective des orchestrateurs externes individuels ci-dessous.
Pour activer les alertes pour cet orchestrateur externe, cochez la case Alert Enabled (alerte activée).
![]() Note |
Assurez-vous que les alertes du connecteur sont également activées sur la page (gestion des configurations d’alertes des charges de travail). |
Sélectionnez le niveau de Alert Severity (gravité de l’alerte) et la Disconnect Duration (durée de la déconnexion) en minutes pour la configuration de l’alerte de l’orchestrateur externe.
Champ |
Description |
---|---|
Gravité |
Sélectionnez le niveau de gravité de cette règle :LOW (faible), MEDIUM (moyenne), HIGH (élevée), CRITICAL (critique) ou IMMEDIATE ACTION (Action immédiate) |
Durée de la déconnexion (m) |
La durée pendant laquelle une connexion est déconnectée. |
Cliquez sur le bouton Create (créer) pour créer le nouvel orchestrateur externe, dont les détails de configuration peuvent être consultés en cliquant sur la ligne correspondante dans la vue de liste :
![]() Note |
Étant donné que la première récupération complète d’instantané à partir d’un orchestrateur externe est une opération asynchrone, comptez environ une minute pour que le champ d’état de la connexion soit mis à jour. |
Cliquez sur le bouton en forme de crayon à droite d’une ligne d’un orchestrateur externe, comme illustré ci-dessous, pour ouvrir une boîte de dialogue modale similaire à celle utilisée pour la création d’un orchestrateur externe, où la configuration peut être modifiée.
![]() Note |
|
Cliquez sur le bouton Update (mettre à jour) pour enregistrer les modifications apportées à la configuration.
![]() Caution |
La suppression d’un orchestrateur externe entraîne également la suppression des étiquettes fournies par cet orchestrateur, ce qui aura une incidence sur les politiques. Pour supprimer un orchestrateur externe, cliquez sur la corbeille comme indiqué ci-dessous : |
Cisco Secure Workload ajoute les étiquettes suivantes à toutes les instances AWS.
Clé |
Valeur |
---|---|
orchestrator_system/orch_type |
AWS |
orchestrator_system/cluster_name |
<Nom de la grappe Kubernetes> |
orchestrator_system/name |
<Nom du connecteur> |
orchestrator_system/cluster_id |
<UUID de la configuration de l'orchestrateur dans |produit|> |
Pour que Cisco Secure Workload puisse importer des balises utilisateur ou appliquer des politiques sur les orchestrateurs externes (voir Orchestrateurs externes), Cisco Secure Workload doit établir des connexions sortantes vers les serveurs d’API des orchestrateurs (vCenter, Kubernetes, F5 BIG-IP, etc.). Parfois, il n’est pas possible d’autoriser les connexions entrantes directes vers les orchestrateurs à partir de la grappe Cisco Secure Workload. Le connecteur sécurisé résout ce problème en établissant une connexion sortante du même réseau que l’orchestrateur vers la grappe Cisco Secure Workload. Cette connexion est utilisée comme tunnel inverse pour renvoyer les demandes de la grappe au serveur d’API de l’orchestrateur.
Pour chaque portée racine, un seul tunnel à la fois peut être actif. Les tentatives de démarrage de tunnels supplémentaires seront rejetées avec un message d’erreur indiquant qu’un tunnel est déjà actif. Le tunnel actif peut être utilisé pour se connecter à plusieurs orchestrateurs qui sont accessibles à partir du réseau dans lequel le client fonctionne. Une configuration par orchestrateur est utilisée pour indiquer si les connexions à cet orchestrateur doivent passer par le tunnel du connecteur sécurisé.
Toutes les communications entre le client Connecteur sécurisé et la grappe Cisco Secure Workload sont authentifiées et chiffrées mutuellement à l’aide de TLS.
Pour une sécurité accrue, il est conseillé aux clients d’installer le client Secure Connector (Connecteur sécurisé) sur un ordinateur isolé correctement sécurisé. L’ordinateur doit avoir des règles de pare-feu pour autoriser les connexions sortantes uniquement vers la grappe Cisco Secure Workload et tous les serveurs API externes de l'orchestrateur Cisco Secure Workload doivent être autorisés à y accéder.
Pour configurer les orchestrateurs en vue de l’utilisation du tunnel du connecteur sécurisé, consultez les instructions de configuration de l’orchestrateur externe pour votre produit.
Pour en savoir plus sur les points terminaux OpenAPI pour le connecteur sécurisé, consultez : Points d’accès d’API du connecteur sécurisé
Pour amorcer le tunnel, le client connecteur sécurisé crée une paire de clés publique ou privée et signe son certificat de clé publique à distance par le serveur. Un jeton cryptographique à usage unique d’une durée limitée est utilisé pour sécuriser ce processus de signature à distance et pour identifier la portée racine à laquelle le client appartient. Du côté du serveur, chaque portée racine possède un certificat unique que le client utilise pour authentifier le serveur. Ces certificats sont régulièrement renouvelés pour assurer le secret de communication.
Le client connecteur sécurisé est composé d’un client de tunnel et d’un serveur SOCKS5. Une fois le tunnel démarré, le client attend les connexions par tunnellisation entrantes de la grappe Cisco Secure Workload. Les connexions entrantes sont gérées par le serveur SOCKS5 et transférées à l’hôte de destination.
Voici les exigences pour le client Connecteur sécurisé :
RHEL ou CentOS 7 (x86_64)
2 cœurs de CPU
4 Go de RAM
Une bande passante réseau suffisante pour gérer les données des orchestrateurs sur site qui utilisent le connecteur sécurisé.
Connectivité sortante vers la grappe Cisco Secure Workload sur le port 443 (directe ou par l’intermédiaire d’un serveur mandataire HTTP(S)).
Connectivité sortante vers les serveurs d’API Orchestrator internes (directe)
[Service]
Environment="HTTPS_PROXY=<Proxy Server Address>"
Le connecteur sécurisé crée un tunnel inverse de la grappe Cisco Secure Workload à votre réseau interne afin d’atteindre les serveurs d’API de votre orchestrateur.
Le démarrage du client du connecteur sécurisé nécessite le téléchargement du RPM Secure Connector et la génération d’un jeton d’enregistrement à usage unique.
Téléchargez et installez le paquet logiciel client du connecteur sécurisé sur une plateforme prise en charge.
Copiez le jeton généré sur l’hôte pour démarrer le client.
Étape 1 |
Dans le volet de navigation, cliquez sur . |
Étape 2 |
Cliquez sur Download Latest RPM (Télécharger le dernier RPM). |
Étape 3 |
Copiez l’ensemble RPM sur l’hôte Linux pour le déploiement, puis exécutez la commande suivante avec les privilèges racine : |
Étape 1 |
Cliquez sur . |
Étape 2 |
Cliquez sur Generate Registration Token (Générer un jeton d'enregistrement). |
Après avoir généré un jeton d’enregistrement sur la page Secure Connector (connecteur sécurisé), vous obtiendrez un fichier registration.token (jeton d'enregistrement) qui contient le jeton à usage unique à durée limitée pour le démarrage du client. Arrêtez le client connecteur sécurisé sur l’hôte et copiez le fichier de jeton à l'emplacement où vous avez installé le paquet client connecteur sécurisé.
Pour arrêter le client, exécutez la commande suivante : systemctl stop tetration-secure-connector
Copiez le fichier registration.token dans le dossier /etc/tetration/cert/.
Pour redémarrer le client, exécutez la commande suivante : systemctl start tetration-secure-connector
Étape 1 |
Téléchargez une version précise du client connecteur sécurisé RPM. |
Étape 2 |
Récupérez un nouveau jeton à l’aide de l’API. Les jetons du connecteur sécurisé peuvent également être récupérés par le biais de l'OpenAPI (Get Tokenendpoint). Les extraits de code Python et Bash suivants peuvent être utilisés pour récupérer un nouveau jeton. Notez que la clé API utilisée doit avoir la capacité external_integration et avoir un accès en écriture à la portée racine spécifiée. Consultez la section OpenAPI Authentification (Authentification OpenAPI) pour obtenir des renseignements sur l’installation de OpenAPI client Cisco Secure Workload pour Python et la création d’une nouvelle clé API.
|
Étape 3 |
Copier le jeton et démarrer le client. Pour plus de renseignements sur les instructions, consultez Copier le jeton et démarrer le client. |
Pour vérifier si le client Connecteur sécurisé est installé, interrogez la base de données RPM pour trouver le paquet tet- secureconnector-client-site en exécutant la commande suivante : rpm -q tet-secureconnector-client-site
Pour vérifier l’état du client installé, vous pouvez vérifier l’état du service tetration-secure-connector systemd en exécutant la commande suivante : systemctl status tetration-secure-connector
Dans la page External Orchestrateurs, l’état des orchestrateurs externes configurés et du tunnel du connecteur sécurisé s’affiche. Si le connecteur sécurisé est activé lors de la configuration des orchestrateurs externes, vous pouvez afficher les métriques du client Secure Connector dans la page Secure Connector (connecteur sécurisé ).
Cependant, si l’état du tunnel de Cisco Secure Connector est Actif mais que les métriques du client ne sont pas visibles, cela signifie qu’une version plus ancienne de Cisco Secure Connector est installée. Un message de mise à niveau dans la version de Secure Connector Client s’affiche comme suit :
![]() Note |
Pour obtenir des instructions sur l’installation du dernier RPM client du connecteur sécurisé, consultez la section Télécharger et installer le dernier RPM client du connecteur sécurisé. |
Pour afficher les mesures du client :
Step 1 |
Sous Configure Details (Détails de la configuration), cliquez sur la ligne Status (État). La page Secure Connector (Connecteur sécurisé) s’affiche.
|
||||||||
Step 2 |
Sélectionnez les onglets General (General), Interface (Interface) ou Routes (routes) pour accéder à plus de détails sur l’état de la connectivité entre le client et la grappe Cisco Secure Workload.
|
L’alerte est générée lorsque le connecteur sécurisé cesse de fonctionner ou en l’absence de pulsations au cours de la dernière minute.
Étape 1 : Pour activer l’alerte, cliquez sur Manage (Gestion) Workloads (Charges de travail) > Secure Connector (Connecteur sécurisé).
Étape 2 : Cliquez sur l’onglet Alerts (alertes).
Étape 3 : Cochez la case Enable Alert (activer l’alerte).
Étape 4 : Choisissez une valeur de Severity (gravité) dans le menu déroulant.
Étape 5 : Cliquez sur Update Config (Mettre à jour la configuration).
![]() Remarque |
Assurez-vous que les alertes des connecteurs sont activées dans la page Manage (Gestion) > Alerts - Configuration Configuration des alertes). |
Accédez à Investigate (Enquêter) > Alerts (Alertes) et cliquez sur une alerte pour en savoir plus.
Texte d’alerte : : Secure Connector(connecteur sécurisé) : <motif de l'échec de la connexion>
Champ |
Type |
Description |
---|---|---|
Nom |
Chaîne |
Nom du connecteur sécurisé |
Type |
Chaîne |
Type du connecteur sécurisé |
Last Checkin At |
Chaîne |
Dernière heure connue de pulsation |
Hostname (Nom d’hôte) |
Chaîne |
Nom de la machine hébergeant ce connecteur sécurisé |
Total Memory (GB) |
Chaîne |
RAM en Go |
No. vCPU's |
Chaîne |
Nombre de CPU |
VM IPs |
Chaîne |
Liste des interfaces réseau sur l’hôte client du connecteur sécurisé |
Le client Secure Connector (Connecteur sécurisé) ne prend pas en charge les mises à jour automatiques. Pour déployer une nouvelle version :
Exécutez la commande suivante pour désinstaller la version actuelle : rpm -e tet-secureconnector-client-site
Déployez la nouvelle version. Pour plus de renseignements sur les instructions, consultez Déployer le client connecteur sécurisé.
Le client connecteur sécurisé peut être désinstallé à l’aide de la commande suivante rpm -e tet-secureconnector-client-site
![]() Note |
La fonctionnalité d’orchestrateur externe d’AWS fait désormais partie de la nouvelle fonctionnalité de connecteur infonuagique AWS. Si vous avez effectué une mise à niveau vers cette version, vos orchestrateurs externes AWS existants sont maintenant en lecture seule; si vous devez apporter des modifications, créez un nouveau connecteur AWS. Pour en savoir plus, consultez Connecteur AWS. |
Cisco Secure Workload prend en charge l’acquisition automatisée de l’inventaire en direct à partir d’une région AWS. Lorsqu’une configuration d’orchestrateur externe est ajoutée pour le type « aws », l’appareil Cisco Secure Workload se connecte au point terminal AWS et récupère les métadonnées pour toutes les instances à l’état d’exécution ou d’arrêt.
Les jetons de sécurité (clé d’accès et clé secrète) utilisés doivent avoir le type de privilèges IAM approprié pour permettre la récupération des informations de l’orchestrateur.
Attribut |
Description |
||
---|---|---|---|
Identifiant |
Identifiant unique de l’orchestrateur. |
||
Nom |
Nom spécifié par l’utilisateur de l’orchestrateur. |
||
Type |
Type d’orchestrateur - (aws dans ce cas) |
||
Description |
Une brève description de l’orchestrateur. |
||
ID de la clé d'accès AWS |
CLÉ D’ACCÈS associée au compte pour lequel la configuration de l’orchestrateur est en cours de création. |
||
Clé d'accès secrète AWS |
CLÉ SECRÈTE associée au compte que vous créez pour la configuration de l’orchestrateur.
|
||
Région AWS |
La région dans laquelle la charge de travail a été déployée. Si une charge de travail est répartie sur plusieurs régions, une configuration distincte est requise pour chaque région. Consultez le lien ci-dessous pour connaître les valeurs de région correctes. :ref:https://docs.aws.amazon.com/general/latest/gr/rande.html. |
||
Accept Self-signed Cert (Accepter le certificat autosigné) |
Est automatiquement marqué comme vrai pour AWS. L’utilisateur ne peut pas le modifier. |
||
Intervalle complet entre les instantanés |
Intervalle de l’instantané complet en secondes. Le gestionnaire d'inventaire de l'orchestrateur effectuera une interrogation d'actualisation complète à partir de l'orchestrateur. |
||
Intervalle différentiel entre les instantanés |
Intervalle de l’instantané différentiel en secondes. Le gestionnaire d’inventaire de l’orchestrateur récupérera uniquement les mises à jour incrémentielles de l’orchestrateur. |
||
Liste d’hôtes |
Le type d’orchestrateur AWS ne nécessite pas de liste d’hôtes. Le point terminal pour AWS sera dérivé du champ AWS Region (région AWS) ci-dessus. Ce champ doit être laissé vide. |
||
Mesures TSDB détaillées |
Si cette option est activée, les mesures tsdb pour chaque orchestrateur individuel seront rapportées. Sinon, une agrégation de toutes les mesures de l’orchestrateur sera rapportée. |
||
Secure Connector Tunnel (Tunnel du connecteur sécurisé) |
Tunneliser les connexions vers les hôtes de cet orchestrateur par l’intermédiaire du tunnel de Connecteur sécurisé. |
Configurez un orchestrateur AWS avec les champs de configuration ci-dessus.
Cisco Secure Workload ajoute les étiquettes suivantes à toutes les instances AWS.
Clé |
Valeur |
---|---|
orchestrator_system/orch_type |
AWS |
orchestrator_system/cluster_name |
<Nom de la grappe Kubernetes> |
orchestrator_system/name |
<Nom du connecteur> |
orchestrator_system/cluster_id |
<UUID de la configuration de l'orchestrateur dans |produit|> |
Les étiquettes suivantes sont propres à l’instance.
Clé |
Valeur |
---|---|
orchestrator_system/workload_type |
vm |
orchestrator_system/machine_id |
<Numéro d'instance attribué par AWS> |
orchestrator_system/machine_name |
<PublicDNS(nom de domaine complet (FQDN)) donné à ce nœud par AWS> |
orchestrator_‘<Clé d'étiquette AWS>‘ |
<Valeur de l'étiquette AWS> |
Confusion entre la région AWS et la zone de disponibilité
Ces deux valeurs sont interdépendantes et ne doivent pas être confondues. Par exemple, us-ouest-1 pourrait être la région et la zone de disponibilité peut être us-ouest-1a ou us-ouest-1b, etc. Lors de la configuration de l’orchestrateur, la région doit être utilisée. Reportez-vous à https://docs.aws.amazon.com/general/latest/gr/rande.html pour toutes les régions.
Problème de connectivité et de renseignements d’authentification après la mise à jour de la configuration de l’orchestrateur
Les clients doivent soumettre de nouveau la clé secrète AWS chaque fois que la configuration est mise à jour.
![]() Note |
Les fonctionnalités des orchestrateurs externes EKS et AKS font désormais partie des nouvelles fonctionnalités des connecteurs infonuagiques AWS et Azure, respectivement. Si vous avez effectué la mise à niveau vers cette version, vos orchestrateurs externes EKS et AKS existants sont maintenant en lecture seule; si vous devez apporter des modifications, créez un nouveau connecteur AWS ou Azure. Pour des renseignements complets, consultez les rubriques pertinentes sous Connecteurs pour l'informatique infonuagique. L’orchestrateur externe pour Kubernetes et OpenShift standard n’a pas été modifié. |
Cisco Secure Workload prend en charge l’acquisition automatisée de l’inventaire en direct à partir d’une grappe Kubernetes. Lorsqu’une configuration d’orchestrateur externe est ajoutée pour une grappe Kubernetes/OpenShift, Cisco Secure Workload se connecte au serveur d’API de la grappe et suit l’état des nœuds, des pods et des services dans cette grappe. Pour chaque type d'objet, Cisco Secure Workload importe toutes les étiquettes Kubernetes et les étiquettes associées à l'objet. Toutes les valeurs sont importées en l'état.
En plus d’importer les étiquettes définies pour les objets Kubernetes/OpenShift, Cisco Secure Workload génère également des étiquettes qui facilitent l’utilisation de ces objets dans les filtres d’inventaire. Ces étiquettes supplémentaires sont particulièrement utiles pour définir les portées et les politiques.
Pour en savoir plus sur toutes ces étiquettes, consultez Étiquettes relatives aux grappes Kubernetes.
Si l'application est activée sur les nœuds Kubernetes (les agents d'application sont installés et le profil de configuration active l'application sur ces agents), les politiques d'application seront installées à la fois sur les nœuds et à l'intérieur des espaces de noms des pods en utilisant les informations acquises sur les entités Kubernetes par le biais de cette intégration.
À propos de Kubernetes sur les plateformes infonuagiques
Pour les services Kubernetes gérés suivants qui s’exécutent sur des plateformes infonuagiques prises en charge, la fonctionnalité de cet orchestrateur est fournie à l’aide de connecteurs infonuagiques :
Elastic Kubernetes Service (EKS) s’exécutant sur Amazon Web Services (AWS)
Azure Kubernetes Service (AKS) s’exécutant sur Microsoft Azure
Google Kubernetes Engine (GKE) s’exécutant sur Google Cloud Platform (GCP)
Pour plus de détails sur l’obtention de données à partir de grappes Kubernetes sur les plateformes infonuagiques, consultez les rubriques sous Connecteurs infonuagiques.
Pour les versions de Kubernetes et d’OpenShift prises en charge, consultez https://www.cisco.com/go/secure-workload/requirements/integrations
Tunnel du connecteur sécurisé, si nécessaire pour la connectivité.
Les champs de configuration suivants concernent la configuration de l'orchestrateur Kubernetes dans l'objet Orchestrateur.
Champ |
Description |
---|---|
Nom |
Nom de l’orchestrateur spécifié par l’utilisateur. |
Description |
Description de l’orchestrateur précisée par l’utilisateur. |
Intervalle différentiel |
Intervalle (en secondes) pour vérifier les modifications sur le point terminal Kubernetes |
Intervalle complet entre les instantanés |
Intervalle (en secondes) pour effectuer un instantané complet des données Kubernetes |
Username |
Nom d’utilisateur pour le point terminal de l’orchestration. |
Mot de passe |
Mot de passe du point terminal de l’orchestration. |
Certificat |
Votre certificat client servira à l’authentification. |
Clé |
Clé correspondant au certificat client. |
Jeton d’authentification |
Jeton d'authentification opaque (jeton porteur). |
Certificat de l’autorité de certification |
Certificat de l’autorité de certification pour valider le point terminal de l’orchestration. |
Accept Self-signed Cert (Accepter le certificat autosigné) |
Case pour désactiver la vérification SSL stricte du certificat du serveur d’API Kubernetes |
Mesures TSDB détaillées |
Maintenir les mesures par Kubernetesorchestrator – si la valeur est Faux (False), seules les mesures à l’échelle de la grappe Cisco Secure Workload sont conservées. |
Secure Connector Tunnel (Tunnel du connecteur sécurisé) |
Connexions de tunnel vers les hôtes de cet orchestrateur par l’intermédiaire du tunnel du connecteur sécurisé |
Liste d’hôtes |
Tableau de paires { « host_name », « port_number »,} (nom de l'hôte, numéro de port) qui précisent comment Cisco Secure Workload doit se connecter à l’orchestrateur |
Type de gestionnaire K8 |
Type de gestionnaire pour la grappe Kubernetes (aucun pour les déploiements standard/OpenShift Kubernetes) |
Nom de la grappe AWS |
Nom de l’orchestrateur comme spécifié au moment de la création de la grappe (EKS préexistant) |
ID d’accès AWS |
CLÉ D’ACCÈS associée au compte pour lequel la configuration de l’orchestrateur est créée (EKS préexistant) |
Clé d’accès secrète AWS |
La CLÉ SECRÈTE associée au compte pour lequel la configuration de l’orchestrateur est créée. Saisissez à nouveau la clé secrète chaque fois que la configuration est modifiée. (EKS pré-existant) |
Région AWS |
La région dans laquelle la charge de travail a été déployée. Si une charge de travail est répartie sur plusieurs régions, une configuration distincte est requise pour chaque région. Consultez le lien ci-dessous pour connaître les valeurs de région correctes. :ref: https://docs.aws.amazon.com/general/latest/gr/rande.html. (EKS pré-existant) |
ARN Assume Role AWS |
Numéro de ressource Amazon des rôles à assumer lors de la connexion à l’outil d’orchestration : https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html (EKS préexistant) |
ID du détenteur Azure |
Identifiant du détenteur associé à l’abonnement Azure. (AKS pré-existant uniquement) |
ID du client Azure |
Identifiant global unique associé à l’application qui doit s’authentifier auprès d’Azure AD. (AKS pré-existant uniquement) |
Code secret du client Azure |
Mot de passe associé au principal service pour l’application qui doit s’authentifier auprès d’Azure AD. (AKS pré-existant uniquement) |
Les attributs d’objet des règles d’or sont décrits ci-dessous. Ces règles d’or permettent de préciser les règles nécessaires à la grappe Kubernetes pour rester fonctionnelle une fois que la mise en application est activée sur les nœuds de la grappe Kubernetes.
Attribut |
Description |
---|---|
Port Kubelet |
Port d’API local au nœud de Kubelet |
Services |
Tableau d’objets des services Kubernetes |
Le port Kubelet est nécessaire pour créer des politiques autorisant le trafic des daemons de gestion Kubernetes vers les kubelets, par exemple pour les journaux en direct, les exécutions de pods en mode interactif, etc. La connectivité vitale entre les différents services et daemons Kubernetes est spécifiée sous la forme d'une série de services - chaque entrée du tableau de services a la structure suivante :
Description : une chaîne qui décrit le service.
Adresses : une liste d’adresses de points terminaux de service du format <IP>:<port> /<protocol>.
Consommé par : une liste des consommateurs des points terminaux (les valeurs autorisées sont les pods ou les nœuds)
![]() Note |
Si Kubernetes est choisi comme type, la configuration des règles d’or sera autorisée. |
Configurez le tunnel du connecteur sécurisé, si nécessaire, pour la connectivité de la grappe Cisco Secure Workload à un serveur ou des serveurs d’API Kubernetes.
Configurez un orchestrateur Kubernetes rempli avec les champs de configuration ci-dessus.
Configurez les règles d’or pour l’orchestrateur Kubernetes.
Le client Kubernetes tente de RECEVOIR/RÉPERTORIER/SURVEILLER les ressources suivantes. Il est fortement recommandé de NE PAS configurer la clé ou le certificat d’administrateur ou un compte de service administrateur.
Les informations d’authentification Kubernetes fournies doivent avoir un ensemble minimal de privilèges sur les ressources suivantes :
Ressources |
Verbes Kubernetes |
---|---|
points terminaux |
[obtenir la liste de surveillance] |
espaces de noms |
[obtenir la liste de surveillance] |
nodes |
[obtenir la liste de surveillance] |
pods |
[obtenir la liste de surveillance] |
services |
[obtenir la liste de surveillance] |
entrées |
[obtenir la liste de surveillance] |
contrôleurs de duplication |
[obtenir la liste de surveillance] |
jeux de répliques |
[obtenir la liste de surveillance] |
déploiements |
[obtenir la liste de surveillance] |
daemonsets |
[obtenir la liste de surveillance] |
statefulsets |
[obtenir la liste de surveillance] |
tâches |
[obtenir la liste de surveillance] |
cronjobs |
[obtenir la liste de surveillance] |
En substance, vous pouvez créer un compte de service spécial sur votre serveur Kubernetes avec ces privilèges minimaux. Vous trouverez ci-dessous un exemple de séquence de commandes kubectl qui facilitera la création de ce compte de service. Notez l’utilisation de clusterrole (non de rôle) et clusterrolebindings (non de rolebindings) - ce sont des rôles à l’échelle de la grappe et non d'un espace de nom. L’utilisation d’une liaison de rôle ou de rôle ne fonctionnera pas, car Cisco Secure Workload tente de récupérer les données de tous les espaces de noms.
$ kubectl create serviceaccount csw.read.only
Créez le rôle de grappe (clusterrole).
Un exemple de fichier clusterrole.yaml avec des privilèges minimaux est fourni ci-dessous.
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: csw.read.only
rules:
- apiGroups:
- ""
resources:
- nodes
- services
- endpoints
- namespaces
- pods
- replicationcontrollers
- ingresses
verbs:
- get
- list
- watch
- apiGroups:
- extensions
- networking.k8s.io
resources:
- ingresses
verbs:
- get
- list
- watch
- apiGroups:
- apps
resources:
- replicasets
- deployments
- statefulsets
- daemonsets
verbs:
- get
- list
- watch
- apiGroups:
- batch
resources:
- jobs
- cronjobs
verbs:
- get
- list
- watch
$ kubectl create -f clusterrole.yaml
![]() Note |
Les groupes d’API pour ces différentes ressources sont susceptibles de changer selon les versions de Kubernetes. L’exemple ci-dessus devrait fonctionner pour les versions 1.20 à 1.24 de Kubernetes et pourrait nécessiter quelques ajustements pour d’autres versions. |
Créer la liaison de rôles de grappe
$ kubectl create clusterrolebinding csw.read.only --clusterrole=csw.read.
˓→only --serviceaccount=default:csw.read.only
Pour récupérer le code secret authtoken du compte de service (utilisé dans le champ Auth Token dans l'interface graphique) et le décoder en base64, vous pouvez récupérer le nom du code secret en listant le compte de service avec la sortie yaml.
$ kubectl get serviceaccount -o yaml csw.read.only
apiVersion: v1
kind: ServiceAccount
metadata:
creationTimestamp: 2020-xx-xxT19:59:57Z
name: csw.read.only
namespace: default
resourceVersion: "991"
selfLink: /api/v1/namespaces/default/serviceaccounts/e2e.minimal
uid: ce23da52-a11d-11ea-a990-525400d58002
secrets:
- name: csw.read.only-token-vmvmz
Lister le code secret en mode de sortie yaml produira le jeton mais au format Base64 (ce qui est la procédure standard de Kubernetes pour les données secrètes). Cisco Secure Workload n'accepte pas le jeton dans ce format, vous devez le décoder à partir de Base64.
$ kubectl get secret -o yaml csw.read.only-token-vmvmz
apiVersion: v1
data:
ca.crt: ...
namespace: ZGVmYXVsdA==
token: ZXlKaGJHY2lPaUpTVX....HRfZ2JwMVZR
kind: Secret
metadata:
annotations:
kubernetes.io/service-account.name: csw.read.only
kubernetes.io/service-account.uid: ce23da52-a11d-11ea-a990-525400d58002
creationTimestamp: 2020-05-28T19:59:57Z
name: csw.read.only-token-vmvmz
namespace: default
resourceVersion: "990"
selfLink: /api/v1/namespaces/default/secrets/csw.read.only-token-vmvmz
uid: ce24f40c-a11d-11ea-a990-525400d58002
type: kubernetes.io/service-account-token
.data.token
et décoder le codage en base 64 en une seule commande, la commande suivante qui utilise l’option --template
est utile. $ kubectl get secret csw.read.only-token-vmvmz --template "{{ .data.token }}" | base64 -d
Cet authtoken peut être utilisé pour configurer un orchestrateur Kubernetes dans l’interface utilisateur Cisco Secure Workload au lieu de nom d’utilisateur/mot de passe ou de clé/certificat.
Consultez la section Considérations relatives à RBAC EKS.
Consultez la section Étiquettes liées aux grappes Kubernetes.
Analyse ou incompatibilité des informations d’authentification de la clé ou du certificat client
Celles-ci doivent être fournies au format PEM et correspondre à l’entrée correcte du fichier kubectl.conf. Nous avons rencontré des clients qui collaient des certificats d'autorité de certification dans les champs de certificats des clients, ainsi que des clés et des certificats qui ne correspondaient pas les uns aux autres.
Identifiants Gcloud au lieu des identifiants GKE
Les clients qui utilisent GKE sous la ligne de commande gcloud fournissent par erreur les informations d'authentification gcloud alors que les informations d’authentification de grappe GKE sont nécessaires.
Version de la grappe Kubernetes non prise en charge
L’utilisation d’une version incompatible de Kubernetes peut entraîner des défaillances. Vérifiez que la version de Kubernetes figure dans la liste des versions prises en charge.
Les informations d’authentification ont des privilèges insuffisants
Vérifiez que le jeton d’authentification ou la clé d’utilisateur client, ou le certificat utilisé dispose de tous les privilèges répertoriés dans le tableau ci-dessus.
L'inventaire Kubernetes n'en finit pas de basculer
Le champ hosts_list spécifie un groupe de serveurs d'API pour la même grappe Kubernetes – vous ne pouvez pas l’utiliser pour configurer plusieurs grappes Kubernetes. Cisco Secure Workload vérifiera la réactivité et sélectionnera aléatoirement l'un de ces points terminaux pour s'y connecter et récupérer les informations de l'inventaire Kubernetes. Aucun équilibrage de charge n’est effectué ici, et il n’y a aucune garantie de répartition uniforme de la charge sur ces points terminaux. S’il s’agit de grappes différentes, l’inventaire de Kubernetes continuera à basculer entre elles, selon le serveur d’API de la grappe auquel nous nous connectons.
Plusieurs méthodes d’autorisation
Plusieurs méthodes d’autorisation peuvent être saisies lors de la configuration (nom d’utilisateur ou mot de passe, authtoken, clé ou certificat client) et seront utilisées dans la connexion client établie avec le serveur d’API. Les règles standard de Kubernetes concernant les méthodes d’autorisation simultanée valides s’appliquent ici.
La validation du certificat SSL échoue
Si le point de terminaison de l’API Kubernetes se trouve derrière un NAT ou un équilibreur de charge, le numéro de répertoire (NR) dans le certificat SSL généré sur les nœuds du plan de contrôle Kubernetes peut ne pas correspondre à l’adresse IP configurée dans Cisco Secure Workload. Cela entraînera un échec de validation SSL même si le certificat de l’autorité de certification est fourni et valide. Le bouton Insecure (Non sécurisé) contourne la validation stricte des certificats SSL du serveur et aidera à contourner ce problème, mais peut entraîner des problèmes de MITM. Le correctif correct consiste à modifier le certificat de l’autorité de certification pour fournir des entrées SAN (Subject Alternative Name) pour toutes les entrées DNS ou IP qui peuvent être utilisées pour se connecter à la grappe Kubernetes.
L’intégration de vCenter permet à l’utilisateur de récupérer les attributs sans système d’exploitation et de machine virtuelle du vCenter configuré.
Lorsqu’une configuration d’orchestrateur externe est ajoutée pour le type « vCenter », Cisco Secure Workload récupère les attributs de machines sans système d’exploitation et de VM pour toutes les machines sans système d’exploitation et les machines virtuelles contrôlées par cette instance de vCenter. Cisco Secure Workload importera les attributs suivants d’une machine virtuelle ou d’une machine sans système d’exploitation : a) le nom d’hôte b) les adresses IP c) l’UUID BIOS d) les catégories/étiquettes.
Un nouvel inventaire sera créé dans Cisco Secure Workload avec les attributs de machines sans système d’exploitation et des machines virtuelles ci-dessus, si l’inventaire n’est pas présent dans l’appareil. Si l’inventaire est déjà présent dans l’appareil (créé par le capteur de visibilité Cisco Secure Workload fonctionnant sur l’ordinateur sans système d’exploitation/la machine virtuelle), l’inventaire existant sera étiqueté avec la liste des catégories/étiquettes d'ordinateurs sans système d’exploitation/de VM récupérés.
Tunnel du connecteur sécurisé, si nécessaire pour la connectivité.
La version de vCenter prise en charge est la 6.5+
En plus des champs de configuration courants, décrits dans la section Créer un orchestrateur externe, les champs suivants peuvent être configurés :
La liste des hôtes est un tableau de paires de noms d’hôte/adresse IP et de ports pointant vers le serveur vCenter à partir duquel les attributs de machines sans système d’exploitation/de machines virtuelles seront extraits.
Tout d’abord, l’utilisateur doit vérifier que le serveur vCenter est accessible sur cette adresse IP/ce port à partir de la grappe Cisco Secure Workload.
Pour TaaS ou dans les cas où le serveur vCenter n’est pas accessible directement, l’utilisateur doit configurer un tunnel de connecteur sécurisé pour fournir la connectivité.
Cisco Secure Workload ajoute les étiquettes suivantes à toutes les machines virtuelles apprises du serveur vCenter.
Clé |
Valeur |
---|---|
orchestrator_system/orch_type |
vCenter |
orchestrator_system/cluster_name |
<Nom donné à la configuration de cette grappe> |
orchestrator_system/cluster_id |
<L’identifiant unique UUID de la configuration de la grappe dans Cisco Secure Workload> |
Les étiquettes suivantes sont propres à l’instance.
Clé |
Valeur |
---|---|
orchestrator_system/workload_type |
vm |
orchestrator_system/machine_id |
UUID BIOS de machine sans système d’exploitation/VM |
orchestrator_system/machine_name |
Nom d’hôte de la machine sans système d’exploitation/de la machine virtuelle |
orchestrator_‘<Category Name>‘ |
<Tag Value> |
Lorsqu’une configuration d’orchestrateur externe est ajoutée à vCenter, le logiciel Cisco Secure Workload se connecte au serveur vCenter spécifié dans la liste d’hôtes. Une fois la connexion au serveur réussie, le logiciel Cisco Secure Workload importera les noms d’hôte, les adresses IP et les catégories ou étiquettes pour toutes les machines sans système d’exploitation et les machines virtuelles présentes sur le serveur vCenter. Pour importer les noms d’hôte et les adresses IP de la machine sans système d’exploitation et des machines virtuelles, les outils de VM doivent être installés sur l’ensemble de la machine sans système d’exploitation et les machines virtuelles. Si les outils VM ne sont pas installés pour une machine virtuelle ou sans système d’exploitation, le logiciel Cisco Secure Workload n’affichera pas les catégories ou les étiquettes pour cette machine virtuelle ou sans système d’exploitation en particulier.
Le logiciel Cisco Secure Workload n’importe pas les attributs personnalisés du logiciel sans système d’exploitation ou de la machine virtuelle.
Il est recommandé de fixer la durée de minuterie de l'intervalle Delta à plus de 10 minutes afin de réduire la charge sur le serveur vCenter. Toute modification de l’inventaire ou des étiquettes sur le serveur vCenter aura un délai de propagation d’au moins 10 min, une fois la minuterie mentionnée ci-dessus modifiée.
Problèmes de connexion
Si le dispositif Cisco Secure Workload ne peut pas se connecter ou atteindre le serveur vCenter, l’onglet Connection Status (État de la connexion) de l’orchestrateur externe affichera l’état de l’échec ainsi que l’erreur appropriée, le cas échéant.
Contrôle de l’intégrité du logiciel Cisco Secure Workload.
Consultez la page MAINTENANCE/Service Status (MAINTENANCE/état de service) pour voir si un service est en panne. Vérifiez si OrchestratorInventoryManager est opérationnel et fonctionne.
L’intégration du DNS permet à Cisco Secure Workload d’annoter un inventaire connu avec des renseignements DNS tels que les noms d’hôte des enregistrements CNAME et A/AAAA.
Lorsqu’une configuration d’orchestrateur externe est ajoutée pour le type « dns », l’appareil Cisco Secure Workload tente de se connecter au(x) serveur(s) DNS et effectue un téléchargement de transfert de zone des enregistrements DNS. Ces enregistrements (uniquement les enregistrements A/AAAA et CNAME) seront analysés et utilisés pour enrichir l’inventaire dans les pipelines Cisco Secure Workload (comme appartenant au détenteur sous lequel l'orchestrateur est configuré) avec une seule étiquette à valeurs multiples appelée « orchestrator_system/dns_name », dont la valeur correspond aux entrées DNS qui pointent (directement ou indirectement) vers cette adresse IP.
Tunnel du connecteur sécurisé, si nécessaire pour la connectivité
Serveurs DNS pris en charge : BIND9, serveurs prenant en charge AXFR (RFC 5936), Microsoft Windows Server 2016
Les zones DNS sont un tableau de chaînes, dont chacune représente une zone DNS à transférer à partir du serveur DNS. Toutes les zones DNS doivent être précédées d’un point (« . »).
La liste d’hôtes est un tableau de paires de noms d’hôte/adresse IP et de paires de ports pointant vers le ou les serveurs DNS à partir duquel récupérer les enregistrements DNS. Plusieurs serveurs DNS peuvent être configurés ici à des fins de haute disponibilité uniquement. Le comportement de haute disponibilité sur plusieurs serveurs DNS spécifiés dans hosts_list est celui de « premier serveur intègre » et favorisera les entrées les plus anciennes de hosts_list. Les zones ne peuvent pas être fractionnées sur les serveurs DNS.
Tout d’abord, l’utilisateur doit vérifier que le serveur DNS est accessible sur cette adresse IP/ce port à partir de la grappe Cisco Secure Workload.
Pour le TaaS ou dans les cas où le serveur DNS n’est pas accessible directement, l’utilisateur doit configurer un tunnel de connecteur sécurisé pour fournir la connectivité.
Configurez correctement les ACL/la configuration des transferts de zone DNS sur le serveur DNS. Reportez-vous à la documentation du logiciel de serveur DNS correspondant pour obtenir de plus amples renseignements.
orchestrator_system/dns_name -> un champ à valeurs multiples dont les valeurs sont tous les noms d’hôte CNAME et A/AAAA pointant vers cette adresse IP.
Le flux de l’orchestrateur DNS est un flux de métadonnées : les adresses IP apprises lors d’un transfert de zone DNS ne créeront pas d’éléments d’inventaire dans Cisco Secure Workload. Au contraire, les étiquettes d’une adresse IP existante seront mises à jour avec les nouvelles métadonnées DNS. Les données DNS des adresses IP inconnues sont rejetées en mode silencieux. Afin d'annoter les métadonnées DNS des IP qui n'ont pas été apprises par un capteur ou via d'autres intégrations d'orchestrateur, les adresses IP doivent être téléversées via le mécanisme de téléversement en bloc de la CMDB afin de créer des entrées d'inventaire pour ces adresses. Les sous-réseaux appris des téléchargements CMDB ne créent pas d’entrées d’inventaire.
Seuls les enregistrements CNAME et A/AAAA du serveur DNS sont traités. Les enregistrements CNAME seront transformés en enregistrements IPv4/IPv6 finaux via les enregistrements A/AAAA vers lesquels ils pointent. Un seul niveau de déférencement est pris en charge (c.-à-d. les chaînes CNAME -> CNAME -> A/AAAA ou plus ne sont pas déférencées) tant que CNAME pointe vers un enregistrement A/AAAA du même orchestrateur. Le déférencement CNAME sur différents orchestrateurs DNS n’est pas pris en charge.
Problèmes de connexion
Cisco Secure Workload tentera de se connecter au nom d’adresse IP/nom d’hôte et au numéro de port fournis en utilisant une connexion TCP provenant de l’un des serveurs d’appareils Cisco Secure Workload, du nuage dans le cas de TaaS, ou de la machine virtuelle hébergeant le service de tunnel VPN de connecteur sécurisé Cisco Secure Workload. Afin d’établir correctement cette connexion, les pare-feu doivent être configurés pour autoriser ce trafic.
Problèmes de privilège DNS AXFR
De plus, la plupart des serveurs DNS (BIND9 ou Windows DNS ou Infoblox) nécessitent une configuration supplémentaire lorsque les adresses IP des clients tentent des transferts de zone DNS (requêtes AXFR selon les codes d’opération du protocole DNS), car ceux-ci sont plus exigeants en ressources et privilégiés que de simples requêtes DNS pour résoudre des enregistrements DNS individuels. Ces erreurs s’affichent généralement comme un refus AXFR, avec le code de raison 5 (REFUSÉ).
Ainsi, tout test manuel visant à établir que le serveur DNS est configuré correctement ne doit pas dépendre de recherches réussies de nom d’hôte, mais doit plutôt tester spécifiquement les requêtes AXFR (à l’aide d’un outil comme dig).
Tout échec lors d’un transfert de zone AXFR à partir du serveur DNS sera signalé dans le champ « authentication_failure_error » par l’appareil Cisco Secure Workload.
En outre, notez que Cisco Secure Workload tentera des transferts de zone à partir de toutes les zones DNS configurées et que toutes doivent réussir pour que les données DNS soient insérées dans la base de données d’étiquettes Cisco Secure Workload.
Les champs de nom d’hôte de l’inventaire ne sont pas remplis par DNS. Le « nom d’hôte » est toujours appris à partir du capteur Cisco Secure Workload. Si l’inventaire a été téléversé par le téléchargement dans la CMDB et non à partir du capteur, il manque peut-être le nom d’hôte. Toutes les données du flux de travail de l’orchestrateur DNS ne s’affichent que sous l’étiquette « orchestrator_system/dns_name » et ne rempliront jamais le champ du nom d’hôte.
L’intervalle par défaut des instantanés complets est de 24 heures
L’intervalle par défaut des instantanés différentiels est de 60 minutes
Il s’agit également des valeurs minimales autorisées pour ces minuteurs.
Les enregistrements DNS ne changent que rarement. Ainsi, pour un comportement de récupération optimale, à chaque intervalle d’instantané différentiel, Cisco Secure Workload vérifie si les numéros de série de l’une des zones DNS ont été modifiés par rapport à l’intervalle précédent. Si aucune zone n’a changé, aucune action n’est nécessaire.
Si des zones ont été modifiées, nous effectuerons un transfert de zone à partir de toutes les zones DNS configurées (pas seulement de la zone qui a été modifiée).
À chaque intervalle d'instantané complet, les transferts de zone sont téléchargés à partir de toutes les zones et injectés par Cisco Secure Workload dans la base de données des étiquettes, que les numéros de série des zones aient changé ou non.
![]() Warning |
|
L’intégration Infoblox permet à Cisco Secure Workload d’importer des sous-réseaux Infoblox, des hôtes (Record:host) et des enregistrements A/AAAA dans la base de données d’inventaire de Cisco Secure Workload. Les noms et les valeurs des attributs extensibles sont importés tels quels et peuvent être utilisés comme étiquettes Cisco Secure Workload pour définir la portée et les politiques d’application.
![]() Note |
Seuls les objets Infoblox avec des attributs extensibles sont pris en compte, c.-à-d. ceux auxquels aucun attribut extensible n’est attaché seront exclus de l’importation. |
L'image ci-dessous montre un exemple d'étiquettes générées pour un objet hôte importé d'Infoblox avec l'attribut extensible Department :
Point terminal d’API REST Infoblox prenant en charge WAPI version 2.6, 2.6.1, 2.7 et 2.7.1 (recommandé)
En plus des champs de configuration courants, décrits dans la section Créer un orchestrateur externe, les champs suivants peuvent être configurés :
Champs communs |
Obligatoire |
Description |
---|---|---|
Liste d’hôtes |
Oui |
La liste des hôtes indique une grille Infoblox, c'est-à-dire que plusieurs membres de la grille avec accès à l'API REST peuvent être ajoutés, et l'orchestrateur externe passera à la grille suivante dans la liste en cas d'erreurs de connexion. Si vous souhaitez importer des étiquettes d’une autre grille Infoblox, créez un nouvel orchestrateur externe pour celle-ci. |
![]() Note |
Pour les orchestrateurs externes Infoblox, les adresses IPv4 et IPv6 (mode pile double) sont prises en charge. Cependant, notez que la prise en charge de la double pile est une fonctionnalité bêta. |
Tout d’abord, l’utilisateur doit vérifier que le point terminal de l’API REST Infoblox est accessible à partir de la grappe Cisco Secure Workload.
Dans l cas du TaaS ou lorsque le serveur Infoblox n’est pas accessible directement, l’utilisateur doit configurer un tunnel de connecteur sécurisé pour fournir la connectivité.
Créez un orchestrateur externe de type Infoblox. Selon le volume des données Infoblox, c'est-à-dire le nombre de sous-réseaux, d'hôtes et d'enregistrements A/AAAA, il peut s'écouler jusqu'à une heure avant que le premier instantané complet soit disponible dans Cisco Secure Workload.
Lors de la création de la configuration Infoblox, l’utilisateur a la possibilité de désélectionner n’importe quel type d’enregistrement (sous-réseau, hôte, enregistrements A/AAAA).
Cisco Secure Workload ajoute les étiquettes système suivantes à tous les objets extraits d’Infoblox.
Clé |
Valeur |
---|---|
orchestrator_system/orch_type |
infoblox |
orchestrator_system/cluster_id |
UUID de l'orchestrateur externe dans Cisco Secure Workload |
orchestrator_system/cluster_name |
<Nom donné à cet orchestrateur externe> |
orchestrator_system/machine_id |
<Référence/identifiant de l'objet Infoblox> |
orchestrator_system/machine_name |
<nom de l'hôte Infoblox (DNS)> |
Tous les attributs extensibles Infoblox seront importés en tant qu’étiquettes Cisco Secure Workload avec le préfixe orchestrator_. Par exemple, un hôte avec un attribut extensible appelé Department (service) peut être appelé dans la recherche d’inventaire Cisco Secure Workload en tant que service_orchestrateur.
Clé |
Valeur |
---|---|
orchestrator_<extensible attribute> |
<valeur(s) de l'attribut extensible telle(s) qu'extraite(s) d'Infoblox> |
Le nombre maximal de sous-réseaux pouvant être importés à partir d’Infoblox est de 50 000.
Le nombre maximal d’hôtes et d’enregistrements A/AAAA qui peuvent être importés à partir d’Infoblox est de 400 000 au total.
Problème de connectivité, Cisco Secure Workload tentera de se connecter à l’adresse IP/au nom d’hôte et au numéro de port fournis à l’aide d’une connexion HTTPS provenant de l’un des serveurs d’appareils Cisco Secure Workload ou du nuage dans le cas de TaaS , ou de la machine virtuelle hébergeant le service de tunnel de Connecteur sécurisé Cisco Secure Workload. Afin d’établir correctement cette connexion, les pare-feu doivent être configurés pour autoriser ce trafic. Assurez-vous également que les informations d’authentification fournies sont correctes et que vous disposez des privilèges pour envoyer des demandes d’API REST à l’appareil Infoblox.
Tous les objets attendus ne sont pas importés. Cisco Secure Workload importe uniquement des sous-réseaux, des hôtes et des enregistrements A/AAAA auxquels des attributs extensibles sont attachés. Notez qu’il y a une limite au nombre d’objets qui peuvent être importés d’Infoblox, consultez Mises en garde.
Impossible de trouver des sous-réseaux dans l'inventaire. Il n'est pas possible d'utiliser la recherche dans l'inventaire pour trouver des sous-réseaux Infoblox car l'inventaire Cisco Secure Workload par conception ne comporte que des adresses IP, c'est-à-dire des hôtes et des enregistrements A/AAA.
Impossible de trouver un hôte ou un enregistrement A/AAAA, Cisco Secure Workload importe tous les attributs extensibles tels qu’ils ont été récupérés d’Infoblox. N'oubliez pas d’ajouter le préfixe orchestrator_ au nom de l’attribut extensible, dans p. ex. la recherche d’inventaire. Notez que les attributs extensibles des sous-réseaux, s'ils ne sont pas marqués comme hérités dans Infoblox, ne font pas partie des hôtes et ne peuvent donc pas être recherchés dans Cisco Secure Workload.
L’intégration F5 BIG-IP permet à Cisco Secure Workload d’importer les serveurs virtuels à partir d’un dispositif d’équilibreur de charge F5 BIG-IP et d’en dériver des inventaires de services. Un inventaire de service correspond à un serveur virtuel F5 BIG-IP, dont le service se caractérise par la VIP (adresse IP virtuelle), le protocole et le port. Une fois importé dans Cisco Secure Workload, cet inventaire de service aura des étiquettes telles que service_name, qui peuvent être utilisées dans la recherche d’inventaire ainsi que pour créer des portées et des politiques Cisco Secure Workload.
Un des gros avantages de cette fonctionnalité est l’application des politiques, car l’ orchestrateur externe pour F5 BIG-IP traduit les politiques Cisco Secure Workload en règles de sécurité attribuées au serveur virtuel et les déploie sur l’équilibreur de charge F5 BIG-IP au moyen de son API REST.
Tunnel du connecteur sécurisé, si nécessaire pour la connectivité
Point de terminaison d’API REST F5 BIG-IP, version 12.1.1
En plus des champs de configuration courants, décrits dans la section Créer un orchestrateur externe, les champs suivants peuvent être configurés :
Champ |
Obligatoire |
Description |
---|---|---|
Liste d’hôtes |
Oui |
Ceci spécifie le point de terminaison de l’API REST pour l’équilibreur de charge F5 BIG-IP. Si la haute disponibilité est configurée pour F5 BIG-IP, saisissez le nœud membre de secours de sorte qu’en cas de basculement, l’orchestrateur externe bascule sur le nœud actuel. Si vous souhaitez importer des étiquettes d’un autre équilibreur de charge F5 BIG-IP, vous devez créer un nouvel orchestrateur externe. |
Activer l’application |
Non |
La valeur par défaut est faux (non cochée). Si cette option est cochée, cette option permet à Cisco Secure Workload l’application des politiques afin de déployer les règles de politique de sécurité sur l’équilibreur de charge F5 BIG-IP correspondant. Notez que les renseignements d’authentification fournis doivent avoir un accès en écriture sur l’API REST F5 BIG-IP. |
Domaine de routage |
Non |
La valeur par défaut est 0 (zéro). Le domaine de routage spécifie quels serveurs virtuels doivent être pris en compte par l’orchestrateur externe. Le nombre est déterminé par la liste des partitions affectées à un domaine de routage donné, et seuls les serveurs virtuels définis dans ces partitions seront importés dans Cisco Secure Workload. |
Tout d’abord, l’utilisateur doit vérifier que le point terminal de l’API REST F5 BIG-IP est accessible à partir de Cisco Secure Workload.
Pour le TaaS ou dans les cas où l’appareil F5 BIG-IP n’est pas accessible directement, l’utilisateur doit configurer un tunnel de connecteur sécurisé pour assurer la connectivité.
Créez un orchestrateur externe de type F5 BIG-IP.
Selon la valeur de l’ intervalle, le premier instantané complet des serveurs virtuels F5 BIG-IP peut prendre jusqu’à 60 secondes (intervalle par défaut). Par la suite, les étiquettes générées peuvent être utilisées pour créer des portées et des politiques d’application Cisco Secure Workload.
Cisco Secure Workload ajoute les étiquettes système suivantes pour un orchestrateur externe pour F5 BIG-IP :
Clé |
Valeur |
---|---|
orchestrator_system/orch_type |
F5 |
orchestrator_system/cluster_id |
<UUID de l'orchestrateur externe> |
orchestrator_system/cluster_name |
<Nom donné à cet orchestrateur externe> |
orchestrator_system/workload_type |
service |
orchestrator_system/namespace |
<Partition à laquelle appartient le serveur virtuel> |
orchestrator_system/service_name |
<Nom du serveur virtuel F5 BIG-IP> |
Pour chaque serveur virtuel, l'orchestrateur externe génère les étiquettes suivantes :
Clé |
Valeur |
---|---|
orchestrator_annotation/snat_address |
<Adresse SNAT des serveurs virtuels> |
Cette fonctionnalité permet à Cisco Secure Workload de traduire les politiques logiques par des groupes de fournisseurs qui correspondent aux serveurs virtuels étiquetés F5 BIG-IP en règles de sécurité F5 BIG-IP et de les déployer sur le dispositif de l’équilibreur de charge à l’aide de son API REST. Comme mentionné ci-dessus, toute affectation de politique de sécurité existante au serveur virtuel F5 BIG-IP respectif sera remplacée par une nouvelle affectation pointant vers la politique de sécurité générée Cisco Secure Workload. Les politiques de sécurité existantes ne seront pas modifiées ni supprimées de la liste des politiques F5 BIG-IP.
Par défaut, l’application n’est pas activée dans la configuration de l’orchestrateur externe :
Cette option peut être modifiée à tout moment au besoin.
L'activation de l'application ne déploie pas les politiques sur l'équilibreur de charge tant que l'application n'est pas activée dans un espace de travail comprenant au moins une politique applicable à l'équilibreur de charge, ou suite à des mises à jour d'inventaires.
Cependant, la désactivation de l’application pour l’orchestrateur entraînera la suppression immédiate de toutes les règles de politique de sécurité déployées de l’équilibreur de charge F5 BIG-IP.
![]() Note |
|
L’état d’application de la politique OpenAPI pour l'orchestrateur externe peut être utilisé pour récupérer l’état de l’application de la politique Cisco Secure Workload sur le dispositif de l’équilibreur de charge associé à l’orchestrateur externe. Cela permet de vérifier si le déploiement des règles de politique de sécurité sur l’appareil F5 BIG-IP a réussi ou échoué.
Cisco Secure Workload applique les politiques à la fois au niveau de l’équilibreur de charge F5 BIG-IP et au niveau des pods du backend lorsque les pods sont accessibles aux clients externes à l’aide de l’objet d’entrée de Kubernetes.
Voici les étapes à suivre pour appliquer la politique à l’aide du contrôleur d’entrée F5.
Step 1 |
Créez un orchestrateur externe pour l’équilibreur de charge F5 BIG-IP , comme décrit précédemment. |
Step 2 |
Créez un orchestrateur externe pour Kubernetes/OpenShift comme décrit ici. ![]() |
Step 3 |
Créez un objet d'entrée dans la grappe Kubernetes. Un instantané du fichier yaml utilisé pour créer l’objet d’entrée est fourni dans l’image suivante. ![]() |
Step 4 |
Déployez un pod de contrôleur d’entrée F5 dans la grappe Kubernetes. ![]() |
Step 5 |
Créez un service de serveur backend (principal) auquel les consommateurs externes à la grappe accèdent. Dans l’exemple ci-dessous, nous avons créé un service nginx . ![]() |
Step 6 |
Créez une politique entre le consommateur externe et le service backend. Appliquez la politique à l’aide de l’onglet Policy Enforcement (Application des politiques). ![]() |
Step 7 |
Vérifiez les politiques sur l’équilibreur de charge F5 BIG-IP et les pods du backend. Dans le cas de F5, l’équilibreur de charge Cisco Secure Workload appliquera la règle d’autorisation/abandon appropriée où la source sera le consommateur spécifié à l’étape 6 et la destination sera la VIP [VIP du service virtuel Ingress pour F5]. Dans le cas de pods du serveur principal (backend), Cisco Secure Workload appliquera la règle autoriser/abandonner appropriée où la source sera le SNIP [dans le cas où le pool SNAT est activé] ou l'IP F5 [carte automatique activée] et la destination sera l'adresse IP du pod de backend. ![]() |
Pendant la phase de déploiement du mode F5 BIG-IP HA, activez l’option de synchronisation de la configuration . Cela garantit que l’orchestrateur externe peut récupérer la dernière liste de serveurs virtuels auprès de l’hôte actuellement connecté.
Dans le cas d’un mode de déploiement F5 BIG-IP HA, si la mise en correspondance automatique est configurée au lieu du regroupement SNAT pour la traduction d’adresses, assurez-vous que l’adresse IP BIG-IP principale est configurée avec l’adresse Self IP (Auto IP) flottante.
Seule l’adresse VIP définie comme une adresse unique est prise en charge. L’adresse VIP donnée comme sous-réseau n’est pas prise en charge.
Problème de connectivité, Cisco Secure Workload tentera de se connecter à l’adresse IP/au nom d’hôte et au numéro de port fournis à l’aide d’une connexion HTTPS provenant de l’un des serveurs d’appareils Cisco Secure Workload ou du nuage dans le cas de TaaS , ou de la machine virtuelle hébergeant le service de tunnel de Connecteur sécurisé Cisco Secure Workload. Afin d’établir correctement cette connexion, les pare-feu doivent être configurés pour autoriser ce trafic. Assurez-vous également que les informations d’authentification fournies sont correctes et que vous disposez de privilèges d’accès en lecture et en écriture pour envoyer des requêtes d’API REST à l’appareil F5 BIG-IP.
Règles de sécurité introuvables : Si aucune règle de sécurité n’est trouvée pour un serveur virtuel défini, après l’application de la politique, assurez-vous que le serveur virtuel correspondant est activé, c.-à-d. sa disponibilité/état doit être disponible/activé.
L’intégration Citrix Netscaler permet à Cisco Secure Workload d’importer les serveurs virtuels d’équilibrage de la charge à partir d’un dispositif d’équilibreur de charge Netscaler et d’en dériver des inventaires de services. Un inventaire de service correspond à un service Netscaler fourni par un serveur virtuel et possède des étiquettes telles que service_name (nom_service), qui peuvent être utilisées dans la recherche d’inventaire et pour créer des portées et des politiques pour Cisco Secure Workload.
Un des principaux avantages de cette fonctionnalité est l’application des politiques, car l’orchestrateur externe pour Citrix Netscaler traduit les politiques Cisco Secure Workload en règles de liste de contrôle d’accès Netscaler et les déploie sur l’équilibreur de charge Netscaler via son API REST.
Tunnel du connecteur sécurisé, si nécessaire pour la connectivité
Point terminal de l’API REST Netscaler version 12.0.57.19
En plus des champs de configuration courants, décrits dans la section Créer un orchestrateur externe, les champs suivants peuvent être configurés :
Champs communs |
Obligatoire |
Description |
---|---|---|
Liste d’hôtes |
Oui |
Ceci spécifie le point terminal de l’API REST pour l’équilibreur de charge Citrix Netscaler. Si la haute disponibilité est configurée sur Citrix Netscaler, saisissez un autre nœud membre de sorte qu'en cas de basculement, l'orchestrateur externe bascule sur le nœud actuel. Si vous souhaitez importer des étiquettes d’un autre équilibreur de charge Citrix Netscaler, créez un nouvel orchestrateur externe. |
Activer l’application |
Non |
La valeur par défaut est faux (non cochée). Si cette option est cochée, cela permet Cisco Secure Workload à l’application de la politique de déployer les règles ACL sur l’équilibreur de charge Citrix Netscaler correspondant. Notez que les informations d’authentification fournies doivent autoriser un accès en écriture à l’API REST Citrix Netscaler. |
Tout d’abord, l’utilisateur doit vérifier que le point terminal de l’API REST Netscaler est accessible à partir de la grappe Cisco Secure Workload.
Pour le TaaS ou dans les cas où l'appareil Netscaler n’est pas accessible directement, l’utilisateur doit configurer un tunnel de connecteur sécurisé pour fournir la connectivité.
Créez un orchestrateur externe avec le type Citrix Netscaler.
Selon la valeur de l’intervalle, cela peut prendre jusqu’à 60 secondes (intervalle par défaut) avant que le premier instantané complet des serveurs virtuels Netscaler ne se termine. Par la suite, les étiquettes générées peuvent être utilisées pour créer des portées et des politiques d’application Cisco Secure Workload.
Appliquer les politiques de Cisco Secure Workload pour déployer les règles d’ACL Netscaler.
Cisco Secure Workload ajoute les étiquettes système suivantes pour un orchestrateur externe pour Citrix Netscaler :
Clé |
Valeur |
---|---|
orchestrator_system/orch_type |
nsbalancer |
orchestrator_system/cluster_id |
<UUID de l'orchestrateur externe> |
orchestrator_system/cluster_name |
<Nom donné à cet orchestrateur externe> |
orchestrator_system/workload_type |
service |
orchestrator_system/service_name |
<Nom du serveur virtuel d'équilibrage de charge> |
Pour chaque serveur virtuel d’équilibrage de charge, l’orchestrateur externe génère les étiquettes suivantes :
Clé |
Valeur |
---|---|
orchestrator_annotation/snat_address |
<Adresse SNAT des serveurs virtuels> |
Cette fonctionnalité permet à Cisco Secure Workload de traduire les politiques logiques avec des groupes de fournisseurs qui correspondent aux serveurs virtuels étiquetés Citrix Netscaler en règles ACL Citrix Netscaler et de les déployer sur le dispositif de l’équilibreur de charge à l’aide de son API REST. Comme mentionné ci-dessus, toutes les règles ACL existantes seront remplacées par des règles de politique générées par Cisco Secure Workload.
Par défaut, le champ Enable Enforcement (Activer l'application) n’est pas coché. c'est à dire est désactivé, dans la boîte de dialogue Create Orchestrator (Créer un orchestrateur), comme le montre l’image ci-dessous :
Il suffit de cocher la case désignée pour activer l’application pour l’orchestrateur. Cette option peut être modifiée à tout moment au besoin.
Activer l’application pour l’orchestrateur, que cela se fasse en créant ou en modifiant la configuration de l’orchestrateur, ne déploiera pas immédiatement les politiques logiques actuelles sur le dispositif de l’équilibreur de charge. Cette tâche est effectuée dans le cadre de l’application de la politique d’espace de travail qui doit être déclenchée par l’utilisateur, comme le montre l’image suivante, ou en raison d'une mise à jour des inventaires. Cependant, la désactivation de l’application pour l’orchestrateur entraînera la suppression immédiate de toutes les règles ACL déployées de l’équilibreur de charge Citrix Netscaler.
![]() Note |
|
L’état d’application de la politique OpenAPI pour l'orchestrateur externe peut être utilisé pour récupérer l’état de l’application de la politique Cisco Secure Workload sur le dispositif de l’équilibreur de charge associé à l’orchestrateur externe. Cela permet de vérifier si le déploiement des règles ACL sur l’appareil Citrix Netscaler a réussi ou échoué.
Si l’application est activée, les politiques Cisco Secure Workload seront toujours déployées sur la liste globale des ACL, c.-à-d. par défaut de la partition.
Seule l’adresse VIP définie comme une adresse unique est prise en charge. L’adresse VIP donnée comme modèle d’adresse n’est pas prise en charge.
La visibilité des services détectés (serveurs virtuels Citrix Netscaler ) n’est pas prise en charge.
Problème de connectivité, Cisco Secure Workload tentera de se connecter à l’adresse IP/au nom d’hôte et au numéro de port fournis à l’aide d’une connexion HTTPS provenant de l’un des serveurs d’appareils Cisco Secure Workload ou du nuage dans le cas de TaaS , ou de la machine virtuelle hébergeant le service de tunnel de Connecteur sécurisé Cisco Secure Workload. Afin d’établir correctement cette connexion, les pare-feu doivent être configurés pour autoriser ce trafic. Assurez-vous également que les informations d’authentification fournies sont correctes et que vous disposez de privilèges d’accès en lecture et en écriture pour envoyer des requêtes d’API REST à l’appareil Citrix Netscaler.
Règles ACL introuvables. Si aucune règle ACL n’est trouvée, après l’application de la politique, assurez-vous que le serveur virtuel correspondant est activé, c.-à-d. son état doit être opérationnel.
L’intégration TAXII (Trusted Automated Exchange of Intelligence Information ) permet à Cisco Secure Workload d’acquérir les flux de données de renseignements sur les menaces des fournisseurs de sécurité pour annoter les flux réseau et les condensés de processus à l’aide d’indicateurs STIX (Structured Threat Information Expression) comme les adresses IP malveillantes, les condensés malveillants.
Lorsqu’une configuration d’orchestrateur externe est ajoutée pour le type « taxii », l’appareil Cisco Secure Workload tente de se connecter au(x) serveur(s) TAXII et interroge les collections de flux de données STIX. Les flux de données STIX (uniquement les adresses IP et les indicateurs de condensé binaires) seront analysés et utilisés pour annoter les flux réseau et les condensés de processus dans les pipelines de Cisco Secure Workload (comme appartenant au détenteur sous lequel l’orchestrateur est configuré).
Les flux réseau avec des adresses de fournisseur ou de consommateur correspondant à des adresses IP malveillantes importées seront étiquetés avec l’étiquette à valeurs multiples « orchestrator_malicious_ip_by_<nom du fournisseur> » où <nom du fournisseur> est l’entrée de configuration de l’orchestrateur d’utilisateur du fournisseur TAXII et la valeur de l’étiquette est « Yes » (Oui).
Les indicateurs de condensé binaire STIX intégrés seront utilisés pour annoter les condensés de processus de charge de travail, qui seront affichés (s’ils correspondent) dans le tableau de bord de sécurité et les détails de la note de condensé de processus, et dans le profil de charge de travail et condensés de fichier.
Tunnel du connecteur sécurisé, si nécessaire pour la connectivité
Serveurs TAXII pris en charge : 1.0
Flux TAXII pris en charge avec la version STIX : 1.x
En plus des champs de configuration courants, décrits dans la section Créer un orchestrateur externe, les champs suivants peuvent être configurés :
Champs communs |
Obligatoire |
Description |
---|---|---|
Nom |
Oui |
Nom de l’orchestrateur spécifié par l’utilisateur. |
Description |
Oui |
Description de l’orchestrateur précisée par l’utilisateur. |
Fournisseur |
Oui |
Le fournisseur fournit les flux de données de renseignements. |
Intervalle complet entre les instantanés |
Oui |
L’intervalle (en secondes) pour effectuer un instantané complet du flux TAXII. (Par défaut : 1 jour) |
URL de l’interrogation |
Oui |
Le chemin d’accès complet de l’URL d’interrogation pour interroger les données. |
Collecte |
Oui |
Le nom de la collecte de flux TAXII à interroger. |
Jours d'interrogation |
Oui |
Le nombre de données sur les menaces de jours antérieurs à interroger à partir du flux TAXII. |
Username |
Nom d’utilisateur pour l’authentification. |
|
Mot de passe |
Mot de passe d’authentification. |
|
Certificat |
Votre certificat client servira à l’authentification. |
|
Clé |
Clé correspondant au certificat client. |
|
Certificat de l’autorité de certification |
Certificat de l’autorité de certification pour valider le point terminal de l’orchestration. |
|
Accept Self-signed Cert (Accepter le certificat autosigné) |
Case pour désactiver la vérification strictSSL du certificat du serveur TAXII API |
|
Secure Connector Tunnel (Tunnel du connecteur sécurisé) |
Connexions de tunnel vers les hôtes de cet orchestrateur par l’intermédiaire du tunnel du connecteur sécurisé. |
|
Liste d’hôtes |
Oui |
Les paires nom d’hôte/adresse IP et la paire de ports pointant vers le ou les serveurs TAXII. |
Tout d’abord, l’utilisateur doit vérifier que le serveur TAXII est accessible sur cette adresse IP ou ce port à partir de la grappe Cisco Secure Workload.
Configurez le serveur TAXII adéquat avec le chemin d’interrogation et le nom du flux TAXII.
Clé |
Valeur |
---|---|
orchestrator_system/orch_type |
TAXII |
orchestrator_system/cluster_id |
L’identifiant unique UUID de la configuration de la grappe dans Cisco Secure Workload. |
orchestrator_system/cluster_name |
Nom donné à la configuration de cette grappe>. |
orchestrator_malicious_ip_by_ <vendor> |
Yes (Oui) , si l’adresse du fournisseur ou du client de flux correspond aux données d’adresses IP malveillantes TAXII importées. |
L’intégration de TAXII est prise en charge uniquement sur Cisco Secure Workload sur site.
Seuls les adresses IP et les indicateurs de condensé des flux TAXII font l'objet d'une intégration.
Le nombre maximal d’adresses IP intégrées est de 100 K (dernière mise à jour) par flux TAXII.
Le nombre maximal de condensés intégrés est de 500 K (dernière mise à jour) pour tous les flux TAXII.
Seuls les flux TAXII avec STIX version 1.x sont pris en charge.
Problèmes de connexion
Le Cisco Secure Workload tentera de se connecter au chemin d’URL d’interrogation fourni à partir de l’un des Cisco Secure Workload serveurs d’appareils ou de la machine virtuelle qui héberge le service de tunnel VPN du connecteur sécuriséCisco Secure Workload. Afin d’établir correctement cette connexion, les pare-feu doivent être configurés pour autoriser ce trafic.
L’intervalle par défaut des instantanés complets est de 24 heures
À chaque intervalle d’instantané complet, Cisco Secure Workload extrait les flux TAXII des adresses IP et des condensés de fichiers jusqu’aux limites ci-dessus dans la base de données d’étiquettes.