Étiquettes de charge de travail
Les étiquettes (parfois appelées balises, annotations, attributs, métadonnées ou contexte, bien que ces termes ne soient pas toujours complètement synonymes) sont la clé de la puissance de Cisco Secure Workload.
Des étiquettes lisibles par un humain décrivent vos charges de travail selon leur fonction, leur emplacement et d'autres critères.
Cisco Secure Workload prend en charge les méthodes suivantes pour l’ajout d’étiquettes d’utilisateur :
-
Découverte par les agents Cisco Secure Workload exécutés sur les éléments de l’inventaire
-
Importation manuelle à partir de fichiers de valeurs séparées par des virgules (CSV)
-
Affectation manuelle au moyen de l’interface utilisateur
-
Importation automatisée à l’aide des connecteurs de points terminaux
-
Importation automatisée à l’aide des connecteurs pour l’enrichissement de l'inventaire
-
Importation automatisée des étiquettes générées et personnalisées par l’orchestrateur (voir Orchestrateur externes)
-
Importation automatisée à partir de connecteurs infonuagiques (voir Connecteurs infonuagiques)
-
Vous pouvez spécifier des étiquettes d’inventaire lors de la création du script d’installation. Tous les agents installés à l’aide du script reçoivent automatiquement ces étiquettes. Seuls les déploiements de charges de travail Linux et Windows prennent en charge cette fonctionnalité.
Importance des étiquettes
Les étiquettes vous permettent de définir une politique logique. Par exemple :
autoriser le trafic du consommateur hr_department au fournisseur employee_db
Plutôt que de préciser les membres des groupes de charges de travail de consommateurs et de fournisseurs, nous pouvons définir la politique logique à l’aide des étiquettes, comme le montre la figure suivante. Notez que cela permet de modifier dynamiquement les membres des groupes de consommateurs et de fournisseurs sans qu’il soit nécessaire de modifier la politique logique. Au fur et à mesure que des charges de travail sont ajoutées et retirées, Cisco Secure Workload est averti par les services que vous avez configurés, tels que les orchestrateurs externes et les connecteurs infonuagiques. Cela permet à Cisco Secure Workload d’évaluer l’appartenance au groupe de consommateurs hr_department et au groupe de fournisseurs employee_db.
![Exemple de politique avec des étiquettes](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467340.jpg)
Héritage d’étiquette basé sur le sous-réseau
L’héritage d’étiquette basé sur le sous-réseau est pris en charge. Les adresses IP et les sous-réseaux plus restreints héritent des étiquettes des sous-réseaux plus importants dont ils relèvent lorsque l’une des conditions suivantes est satisfaite :
-
L’étiquette ne figure pas dans la liste des étiquettes pour le sous-réseau ou l’adresse de niveau inférieur.
-
La valeur d’étiquette pour le sous-réseau/adresse de niveau inférieur est vide.
Considérez l’exemple suivant :
IP |
Nom |
Objectif |
Environnement |
Esprit-animal |
---|---|---|---|---|
10.0.0.1 |
Serveur 1 |
Trafic Web |
production |
|
10.0.0.2 |
grenouille |
|||
10.0.0.3 |
aigle |
|||
10.0.0.0/24 |
vlan Web |
intégration |
||
10.0.0.0/16 |
Trafic Web |
blaireau |
||
10.0.0.0/8 |
test |
ours |
Les étiquettes pour l’adresse IP 10.0.0.3 sont {« nom » : « Vlan Web », « objectif » : « trafic Web », « environnement » : « intégration », « esprit-animal »: « aigle »}.
Préfixes d’étiquettes
Les étiquettes sont automatiquement affichées, avec un préfixe qui identifie la source des renseignements.
Toutes les étiquettes d’utilisateur sont précédées de * dans l’interface utilisateur (user_ dans OpenAPI). En outre, les étiquettes importées automatiquement à partir d’orchestrateurs externes ou de connecteurs infonuagiques portent le préfixe orchestrator_. Pour les étiquettes importées à partir de connecteurs de point terminal, consultez les renseignements détaillés dans la section Connecteurs pour points terminaux. Ces étiquettes peuvent inclure des étiquettes précédées de ldap_.
Par exemple, une étiquette avec une clé de department (service) importée à partir de fichiers CSV téléversés par l’utilisateur apparaît dans l’interface utilisateur en tant que * department et dans OpenAPI en tant que user_department. Une étiquette avec une clé location (emplacement) importée d’un orchestrateur externe apparaît dans l’interface utilisateur en tant que * orchestrator_location et dans OpenAPI en tant que user_orchestrator_location.
La figure suivante montre un exemple de recherche dans l’inventaire utilisant l’étiquette générée par l’orchestrateur en utilisant le préfixe :
orchestrator_system/os_image:
![Exemple de recherche d’inventaire avec des étiquettes générées par l’orchestrateur](/c/dam/en/us/td/i/400001-500000/460001-470000/467001-468000/467341.jpg)
Étiquettes générées par les connecteurs infonuagiques
env: prod
et la balise de l’interface réseau est, env: prod
la valeur de l’étiquette dans Cisco Secure Workload est, prod,test
qui s’affiche dans la colonne orchestrator_env sur la page du connecteur respective.
Pour connaître les étiquettes propres à AKS, EKS et GKE, consultez également les étiquettes relatives aux grappes Kubernetes.
Clé |
Valeur |
---|---|
orchestrator_system/orch_type |
AWS ou Azure |
orchestrator_system/cluster_name |
<Cluster_name est le nom donné par l'utilisateur pour la configuration de ce connecteur> |
orchestrator_system/name |
<Nom du connecteur> |
orchestrator_system/cluster_id |
<ID du réseau virtuel> |
Étiquettes spécifiques à l’instance
Les étiquettes suivantes sont propres à chaque nœud :
Clé |
Valeur |
---|---|
orchestrator_system/workload_type |
vm |
orchestrator_system/machine_id |
<Numéro d'instance attribué par la plateforme> |
orchestrator_system/machine_name |
<PublicDNS(Nom de domaine complet) attribué à ce nœud par AWS>-ou-<Nom d'instance dans Azure> |
orchestrator_system/segmentation_enabled |
<Indicateur permettant de déterminer si la segmentation est activée sur l'inventaire> |
orchestrator_system/virtual_network_id |
<ID du réseau virtuel auquel l'inventaire appartient> |
orchestrator_system/virtual_network_name |
<Nom du réseau virtuel auquel appartient l'inventaire> |
orchestrator_system/interface_id |
<Identifiant de l'interface réseau élastique attachée à cet inventaire> |
orchestrator_system/region |
<Région à laquelle appartient l'inventaire> |
orchestrator_system/resource_group |
(Cette balise s’applique uniquement à l’inventaire Azure) |
orchestrator_‘<Tag Key>‘ |
<Valeur de l'étiquette>Paire valeur-clé pour un nombre quelconque de balises personnalisées affectées à l’inventaire dans le portail infonuagique. |
Étiquettes liées aux grappes Kubernetes
Les informations suivantes s’appliquent à Kubernetes standard, OpenShift et à Kubernetes exécuté sur les plateformes infonuagique prises en charge (EKS, AKS et GKE).
Pour chaque type d'objet, Cisco Secure Workload importe l'inventaire en direct à partir d'une grappe Kubernetes, y compris les étiquettes associées à l'objet. Les clés et les valeurs d’étiquettes sont importées telles quelles.
En plus d’importer les étiquettes définies pour les objets Kubernetes, 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.
Générer des étiquettes pour toutes les ressources
Cisco Secure Workload ajoute les étiquettes suivantes à tous les nœuds, pods et services récupérés du serveur d’API Kubernetes/OpenShift/EKS/AKS/GKE.
Clé |
Valeur |
---|---|
orchestrator_system/orch_type |
kubernetes |
orchestrator_system/cluster_id |
<L’identifiant unique UUID de la configuration de la grappe dans Cisco Secure Workload> |
orchestrator_system/cluster_name |
<Nom de la grappe Kubernetes> |
orchestrator_system/name |
<Nom du connecteur> |
orchestrator_system/namespace |
<L'espace de noms Kubernetes/OpenShift/EKS/AKS/GKE de cet élément> |
Étiquettes propres au nœud
Les étiquettes suivantes sont générées pour les nœuds uniquement.
Clé |
Valeur |
---|---|
orchestrator_system/workload_type |
Machine |
orchestrator_system/machine_id |
<UUID attribué par Kubernetes/OpenShift> |
orchestrator_system/machine_name |
<Nom donné à ce nœud> |
orchestrator_system/kubelet_version |
<Version du kubelet fonctionnant sur ce nœud> |
orchestrator_system/container_runtime_version |
<La version du conteneur en cours d'exécution sur ce nœud> |
Étiquettes spécifiques aux pods
Les étiquettes suivantes sont générées pour les pods uniquement.
Clé |
Valeur |
---|---|
orchestrator_system/workload_type |
pod |
orchestrator_system/pod_id |
<UUID attribué par Kubernetes/OpenShift> |
orchestrator_system/pod_name |
<Nom donné à ce pod> |
orchestrator_system/hostnetwork |
<vrai|faux>indiquant si le pod est en cours d’exécution dans le réseau hôte |
orchestrator_system/machine_name |
<Nom du nœud sur lequel le pod est exécuté> |
orchestrator_system/service_endpoint |
[Liste des noms de services fournis par ce pod] |
Étiquettes propres au service
Les étiquettes suivantes sont générées pour les services uniquement.
Clé |
Valeur |
---|---|
orchestrator_system/workload_type |
service |
orchestrator_system/service_name |
<Nom donné à ce service> |
-
(Pour Kubernetes géré infonuagique uniquement) Les services de type ServiceType : Équilibreur de charge sont pris en charge uniquement pour la collecte de métadonnées, et non pour la collecte de données de flux ou pour l'application de politiques.
![]() Tip |
Le filtrage des éléments à l’aide de orchestrator_system/service_name n’est pas la même chose que l’utilisation de orchestrator_system/service_endpoint. Par exemple, l’utilisation du filtre orchestrator_system/service_name=web sélectionne tous les services avec le nom web tandis que orchestrator_system/service_endpoint=web sélectionne tous les pods qui fournissent un service avec le nom web. |
Exemple d’étiquettes pour les grappes Kubernetes
L'exemple suivant montre une représentation YAML partielle d'un nœud Kubernetes et les étiquettes correspondantes importées par Cisco Secure Workload.
- apiVersion: v1
kind: Node
metadata:
annotations:
node.alpha.kubernetes.io/ttl: "0"
volumes.kubernetes.io/controller-managed-attach-detach: "true"
labels:
beta.kubernetes.io/arch: amd64
beta.kubernetes.io/os: linux
kubernetes.io/hostname: k8s-controller
Clés d’étiquette importées |
---|
orchestrator_beta.kubernetes.io/arch |
orchestrator_beta.kubernetes.io/os |
orchestrator_kubernetes.io/hostname |
orchestrator_annotation/node.alpha.kubernetes.io/ttl |
orchestrator_annotation/volumes.kubernetes.io/controller-managed-attach-detach |
orchestrator_system/orch_type |
orchestrator_system/cluster_id |
orchestrator_system/cluster_name |
orchestrator_system/namespace |
orchestrator_system/workload_type |
orchestrator_system/machine_id |
orchestrator_system/machine_name |
orchestrator_system/kubelet_version |
orchestrator_system/container_runtime_version |
Importation d’étiquettes personnalisées
Vous pouvez téléverser ou attribuer manuellement des étiquettes personnalisées pour associer des données définies par l’utilisateur à des hôtes spécifiques. Ces données définies par l’utilisateur sont utilisées pour annoter les flux et l’inventaire associés.
Il y a des limites sur le nombre d’adresses IPv4/IPv6 et de sous-réseaux qui peuvent être étiquetés dans toutes les portées racine, quelle que soit la source de l’étiquette (saisie manuellement ou téléversée, intégrée à l’aide de connecteurs ou d’orchestrateurs externes, etc.). Pour en savoir plus, consultez Limites d’étiquettes.
Lignes directrices pour le chargement de fichiers d’étiquettes
Procedure
Step 1 |
Pour afficher un exemple de fichier, dans le volet gauche, sélectionnez Download a Sample (Télécharger un exemple). (Chargement d'étiquettes définies par l'utilisateur) , puis cliquez sur |
Step 2 |
Les fichiers CSV utilisés pour charger les étiquettes utilisateur doivent inclure une clé d’étiquette (adresse IP). |
Step 3 |
Pour utiliser des caractères non latins dans les étiquettes, le fichier CSV doit être au format UTF-8. |
Step 4 |
Assurez-vous que les fichiers CSV respectent les directives décrites dans la section Schéma de clé d’étiquette. |
Step 5 |
Tous les fichiers téléversés doivent suivre le même schéma. |
Schéma de clé d’étiquette
Lignes directrices régissant les noms de colonne
-
Il doit y avoir une colonne avec un en-tête « IP » dans le schéma de clé d’étiquette. En outre, il doit y avoir au moins une autre colonne avec des attributs pour l’adresse IP.
-
La colonne « VRF » revêt une signification particulière dans le schéma d’étiquette. Si elle figure, elle doit correspondre à la portée racine dans laquelle vous téléversez les étiquettes. Elle est obligatoire lors du chargement du fichier CSV à l’aide d’une API indépendante de la portée.
-
Les noms de colonne ne peuvent contenir que les caractères suivants : des lettres, des chiffres, des espaces, des tirets, des traits de soulignement et des barres obliques.
-
Les noms de colonne ne peuvent pas dépasser 200 caractères.
-
Les noms de colonnes ne peuvent pas comporter le préfixe « orchestrator_ », « TA_ », « ISE_ », « SNOW_ » ou « LDAP_ », car ils peuvent entrer en conflit avec les étiquettes des applications internes.
-
Le fichier CSV ne doit pas contenir de noms de colonnes en double.
Directives régissant les valeurs de colonne
-
Le nombre de caractères du nom est limité à 255. Toutefois, ils doivent être aussi courts que possible tout en restant clairs, caractéristiques et significatifs pour les utilisateurs.
-
Les clés et les valeurs ne sont pas sensibles à la casse. Cependant, une cohérence est recommandée.
-
Les adresses figurant dans la colonne « IP » doivent être conformes au format suivant :
-
Les adresses IPv4 peuvent être au format « x.x.x.x » et « x.x.x.x/32 ».
-
Les sous-réseaux IPv4 doivent être du format « x.x.x.x/<netmask>, où netmask est un entier compris entre 0 et 31.
-
Les adresses IPv6 au format long (« x:x:x:x:x:x:x:x » ou « x:x:x:x:x:x:x:x/128 ») et au format canonique ( « x:x::x » ou « x:x::x/128 ») sont pris en charge.
-
Les sous-réseaux IPv6 au format long (« x:x:x:x:x:x:x:x/<netmask> ») et le format canonique (« x:x::x/<netmask> » sont pris en charge. Le masque réseau doit être un entier compris entre 0 et 127.
-
L’ordre des colonnes n’a pas d’importance. Les 32 premières colonnes définies par l’utilisateur seront automatiquement activées en vue de l'étiquetage. Si plus de 32 colonnes sont téléversées, vous pouvez en activer jusqu’à 32 en utilisant les cases à cocher à droite de la page.
Charger des étiquettes personnalisées
Les étapes suivantes expliquent comment les utilisateurs ayant un rôle d’ administrateur de site, d'assistance à la clientèle ou de propriétaire de portée racine peuvent charger des étiquettes.
Before you begin
Pour charger les étiquettes personnalisées, créez un fichier CSV selon les directives de la section sur le chargement des fichiers d'étiquettes.
Procedure
Step 1 |
Dans le volet gauche, sélectionnez Upload New Labels(Télécharger de nouvelles étiquettes), cliquez sur Select File (Sélectionner un fichier). , puis sous |
||
Step 2 |
Dans le volet gauche, sélectionnez Upload New Labels (Télécharger de nouvelles étiquettes), cliquez sur Select File (Sélectionner un fichier). , puis sous |
||
Step 3 |
Sélectionnez l’opération Ajouter, Fusionner ou Supprimer.
Important : La fonction de suppression, lors du chargement des étiquettes personnalisées, supprimera TOUTES les étiquettes associées aux adresses IP ou aux sous-réseaux précisés, et ne se limitera pas aux colonnes répertoriées dans le fichier CSV. Par conséquent, l’opération Delete (Supprimer) doit être utilisée avec prudence. |
||
Step 4 |
Cliquez sur Upload (Téléverser). |
Rechercher des étiquettes
Les utilisateurs ayant un rôle d’ administrateur de site, de service d'assistance à la clientèle ou de propriétaire de portée racine peuvent rechercher, afficher et modifier les étiquettes attribuées à une adresse IP ou à un sous-réseau.
Procedure
Step 1 |
Dans la page Label Management (Gestion des étiquettes), cliquez sur Search and Assign (Rechercher et attribuer). |
Step 2 |
Dans le champ IP or Subnet (adresse IP ou sous-réseau), saisissez l’adresse IP ou le sous-réseau, puis cliquez sur Next (suivant). Dans la page Assign Labels (Attribuer des étiquettes), les étiquettes existantes saisies pour l’adresse IP ou le sous-réseau sont affichées. |
Attribuer ou modifier manuellement des étiquettes personnalisées
Les utilisateurs ayant le rôle d’ administrateur de site, de service d'assistance à la clientèle ou de propriétaire de portée racine peuvent affecter manuellement des étiquettes à une adresse IP ou à un sous-réseau donné.
Procédure
Étape 1 |
Dans la page Label Management (Gestion des étiquettes), cliquez sur Search and Assign (Rechercher et attribuer). |
Étape 2 |
Dans le champ IP or Subnet (adresse IP ou sous-réseau), saisissez l’adresse IP ou le sous-réseau, puis cliquez sur Next (suivant). La page Assign Labels (Affecter des étiquettes) s'affiche. Notez que les étiquettes existantes seront affichées et peuvent être modifiées. |
Étape 3 |
Pour ajouter une nouvelle étiquette, dans la section Étiquettes de <IP address/subnet> , saisissez le nom et la valeur de l’étiquette, puis cliquez sur Confirm (Confirmer). Cliquez sur Next (suivant). |
Étape 4 |
Passez en revue les modifications et cliquez sur Assign (Affecter) pour les valider. |
Télécharger des étiquettes
Les utilisateurs ayant un rôle d’ administrateur de site, de service d'assistance à la clientèle ou de propriétaire de portée racine peuvent télécharger des étiquettes précédemment définies appartenant à une portée racine.
Procedure
Step 1 |
Dans la page Label Management (gestion des étiquettes), cliquez sur User Defined Label Upload (téléverser les étiquettes définies par l’utilisateur). |
Step 2 |
Dans la section Download Existing Labels (Télécharger les étiquettes existantes), cliquez sur Download Labels (Télécharger les étiquettes). Les étiquettes utilisées par Cisco Secure Workload sont téléchargées dans un fichier CSV. |
Modifier les étiquettes
![]() Avertissement |
Si vous devez modifier une étiquette, faites-le avec prudence, car cela modifie les membres et les effets des requêtes, des filtres, des portées, des grappes, des politiques et du comportement appliqué existants qui reposent sur cette dernière. |
Procédure
Étape 1 |
Dans la page Label Management (Gestion des étiquettes), cliquez sur l’onglet Search and Assign (Rechercher et attribuer). |
Étape 2 |
Dans le champ IP or Subnet (adresse IP ou sous-réseau), saisissez l’adresse IP ou le sous-réseau, puis cliquez sur Next (suivant). Les étiquettes utilisées par Cisco Secure Workload pour l’adresse IP ou le sous-réseau saisi s’affichent. |
Étape 3 |
Dans la colonne Actions, cliquez sur l’icône Edit (modifier) pour modifier le nom et la valeur de l’étiquette requise. |
Étape 4 |
Cliquez sur Confirm (Confirmer) puis sur Next (suivant). |
Étape 5 |
Passez en revue les modifications et cliquez sur Assign (Attribuer). |
Désactiver les étiquettes
Une façon de modifier le schéma consiste à désactiver les étiquettes. Procédez avec prudence.
Procédure
Étape 1 |
Accédez à la page Label Management (gestion des étiquettes). |
Étape 2 |
Pour l’étiquette requise, dans la colonne Actions, sélectionnez Disable (désactiver) et confirmez pour supprimer l’étiquette de l’inventaire en cliquant sur Yes (Oui). Si vous décidez ultérieurement d’activer l’étiquette, cliquez sur Enable(Activer) pour utiliser l’étiquette. |
Supprimer des étiquettes
![]() Avertissement |
Une façon de modifier le schéma consiste à désactiver les étiquettes et à les supprimer. Procédez avec prudence. Cette action supprime l’étiquette sélectionnée, ce qui a une incidence sur tous les filtres et toutes les portées qui en dépendent. Assurez-vous que ces étiquettes ne sont pas utilisées. Cette action ne peut pas être annulée. |
Procédure
Étape 1 |
Désactivez les étiquettes. Consultez la section désactiver_étiquettes. |
Étape 2 |
Cliquez sur l'icône de la corbeille et confirmez en cliquant sur Yes (oui) pour supprimer l’étiquette. |
Afficher l’utilisation des étiquettes
L’inventaire des adresses IP ou des sous-réseaux est mis à jour avec les étiquettes personnalisées téléversées à l’aide de fichiers CSV ou attribuées manuellement par les utilisateurs. Les étiquettes sont ensuite utilisées pour définir les portées et les filtres, et les politiques d’application sont créées en fonction de ces filtres. Par conséquent, la compréhension de l’utilisation des étiquettes est essentielle, car toute modification apportée aux étiquettes a une incidence directe sur les portées, les filtres et les politiques de Cisco Secure Workload.
Pour afficher l’utilisation des étiquettes :
Procédure
Étape 1 |
Dans la page Label Management (Gestion des étiquettes), les clés d’étiquette, les cinq principales valeurs des étiquettes utilisées, l’inventaire, les portées, les filtres et les grappes utilisant les étiquettes personnalisées sont affichés. |
||
Étape 2 |
Dans la colonne Usages (utilisations), cliquez sur les valeurs de décompte de l’inventaire, des portées ou des filtres. Par exemple, pour afficher les portées à l’aide de l’étiquette « Location » (Emplacements), cliquez sur le nombre de requêtes sur la portée. ![]() La page Scopes and Inventory (Portées et inventaire) s’affiche et la requête filtre automatiquement les portées avec l’étiquette sélectionnée.
|
Créer un processus pour la tenue des étiquettes
Votre réseau et votre inventaire changeront, et vous devez planifier de mettre à jour les étiquettes pour refléter ces changements.
Par exemple, si une charge de travail est supprimée et que son adresse IP est réaffectée à une charge de travail avec un objectif différent, vous devez mettre à jour les étiquettes associées à cette charge de travail. Cela est vrai pour les étiquettes téléversées manuellement et pour les étiquettes conservées dans d’autres systèmes et acquises à partir d’autres systèmes, comme une base de données de gestion de configuration (CMDB).
Créez un processus pour vous assurer que vos étiquettes sont mises à jour régulièrement et en permanence, et ajoutez ce processus à votre routine d'entretien du réseau.