Kubernetes DISA STIG

Configurer un système Kubernetes pour être conforme à DISA STIG.

Basé sur Kubernetes DISA STIG Version 1, Rel 8 publié le 26 janvier 2023

À la recherche de soutien ?

Lockdown Enterprise

Soutien Ansible

Communauté

Rejoignez-nous sur notre serveur Discord pour poser des questions, discuter des fonctionnalités, ou simplement discuter avec d'autres utilisateurs d'Ansible-Lockdown.

Précautions

Ce rôle apportera des modifications au système qui peuvent avoir des conséquences imprévues. Ce n'est pas un outil d'audit mais plutôt un outil de remédiation à utiliser après un audit.

Le mode vérification n'est pas supporté ! Le rôle se complètera en mode vérification sans erreurs, mais ce n'est pas supporté et doit être utilisé avec prudence.

Ce rôle a été développé contre une installation propre de Kubernetes. Si vous l'appliquez à un système existant, merci de revoir ce rôle pour tout changement spécifique au site qui pourrait être nécessaire.

Pour utiliser la version de publication, veuillez pointer vers la branche principale et la publication pertinente pour la référence STIG que vous souhaitez utiliser.

Correspondance d'un niveau de sécurité pour STIG

Il est possible d'exécuter uniquement les contrôles basés sur un niveau de sécurité particulier pour STIG. Cela est géré à l'aide de balises :

• CAT1
• CAT2
• CAT3

Le contrôle trouvé dans defaults main doit également refléter vrai afin que cela permette aux contrôles de s'exécuter lors du lancement du playbook.

Passer d'une version précédente

Les versions STIG contiennent toujours des changements, il est fortement recommandé de revoir les nouvelles références et les variables disponibles. Cela a beaucoup changé depuis la première version d'ansible-lockdown. C'est désormais compatible avec python3 si il est trouvé comme interpréteur par défaut. Cela vient avec des pré-requis qui configurent le système en conséquence.

D'autres détails peuvent être consultés dans le Changelog

Auditing (nouveau)

Actuellement, cette version ne dispose pas d'un outil d'audit.

Documentation

• Lire la documentation
• Commencer
• Personnaliser les rôles
• Configuration par hôte
• Tirer le meilleur parti du rôle

Exigences

Général :

• Connaissance de base d'Ansible, ci-dessous quelques liens vers la documentation Ansible pour vous aider à commencer si vous n'êtes pas familier avec Ansible.

  • Page principale de documentation Ansible
  • Ansible pour les débutants
  • Guide de l'utilisateur Tower
  • Informations sur la communauté Ansible

• Installation, configuration et fonctionnement d'Ansible et/ou Tower. Cela inclut toutes les configurations de base d'Ansible/Tower, les packages nécessaires installés et l'infrastructure mise en place.

• Veuillez lire les tâches dans ce rôle pour comprendre ce que fait chaque contrôle. Certaines tâches sont perturbatrices et peuvent avoir des conséquences imprévues dans un système de production en direct. Familiarisez-vous également avec les variables dans le fichier defaults/main.yml.

Dépendances techniques :

• Kubernetes 1.16.7 ou supérieur - D'autres versions ne sont pas supportées.
• Mise en place d'Ansible/Tower (ce rôle est testé sur la version Ansible 2.9.1 et plus récente)
• Environnement d'exécution Ansible Python3
• python-def (devrait être inclus dans RHEL/CentOS 7) - La première tâche configure les pré-requis (Tag pré-reqs) pour python3 et python2 (où requis)
  • libselinux-python
  • python3-rpm (package utilisé par py3 pour utiliser le package rpm)

Variables de rôle

Ce rôle est conçu pour que l'utilisateur final n'ait pas à modifier les tâches lui-même. Toute personnalisation doit se faire via le fichier defaults/main.yml ou avec des variables supplémentaires dans le projet, le travail, le flux de travail, etc.

Balises

Il existe plusieurs balises disponibles pour un contrôle précis. Chaque contrôle a son propre ensemble de balises indiquant à quel niveau il appartient, s'il est noté ou non noté, quel élément du système d'exploitation il concerne, s'il s'agit d'un patch ou d'un audit, et le numéro de règle.

Voici un exemple de section de balises d'un contrôle dans ce rôle. En utilisant cet exemple, si vous définissez votre exécution pour ignorer tous les contrôles ayant la balise kernel, cette tâche sera ignorée. L'inverse peut aussi se produire où vous exécutez uniquement les contrôles étiquetés avec kernel.

tags:
      - CNTR-K8-001620
      - CAT1
      - CCI-001084
      - SRG-APP-000233-CTR-000585
      - SV-242434r864009_rule
      - V-242434
      - kubelet
      - kernel

Contribution de la communauté

Nous encourageons vous (la communauté) à contribuer à ce rôle. Merci de lire les règles ci-dessous.

• Votre travail se fera dans votre propre branche individuelle. Assurez-vous de signer et de signer numériquement tous les commits que vous souhaitez fusionner.
• Toutes les demandes de tirage de la communauté sont intégrées dans la branche de développement.
• Les demandes de tirage dans le développement confirmeront que vos commits ont une signature GPG, un enregistrement et un test fonctionnel avant d'être approuvés.
• Une fois vos changements fusionnés et un examen plus approfondi terminé, un membre autorisé fusionnera vos changements dans la branche principale pour une nouvelle sortie.

Test de pipeline

utilise :

• ansible-core 2.12
• collections ansible - tire la dernière version basée sur le fichier de exigences
• exécute l'audit en utilisant la branche de développement
• Il s'agit d'un test automatisé qui se produit lors des demandes de tirage dans le développement