Sécurisation

La solution permettant de monitorer l’infrastructure de Picasoft il est important qu’elle soit sécurisée.

Elasticsearch nous permet de gérer les permissions des differents services et beats (kibana, metricbeat, curator…). Ces permissions s’effectuent par le biais de users spécifiques. Chaque users possède un rôle qui lui donne des permissions.

Il faut donc établir un rôle à la fois pour les utilisateurs, mais aussi pour les services de l’infra de monitoring (Metricbeat, Kibana, File beat, …). On leur assigne donc un user, et un password, qui sont stockés dans un fichier secrets de la machine hote.

Note: Le users picasoft sont géré directement depuis kibana. La configuration expliquée ci-dessous est utilisé pour créer les users des beats et differents agents de la solution. Néanmoins en cas de problème avec kibana il est possible de gérer les users via les commandes elasticsearch-users comme expliqué ici.

Dans le docker-compose.yml de elasticsearch on bind le fichier user et le fichier users_role de config afin de pouvoir modifier ces paramètres en dehors du docker.

volumes:
      - type: bind
        source: ./elasticsearch/config/users
        target: /usr/share/elasticsearch/config/users
        read_only: true
      - type: bind
        source: ./elasticsearch/config/users_roles
        target: /usr/share/elasticsearch/config/users_roles
        read_only: true

Prenons ensuite le cas où l’on veut créer un utilisateur pour une instance de metricbeat.

On va run la commande de création d’un user dans le docker d’elasticsearch

docker exec -it <nom_du_docker_es> elasticsearch-users useradd <nom_beat> -p <password> -r <role>

Il faut ensuite permettre à l’instance du beats de s’authentifier avec le user elasticsearch que l’on vient de créer.

Pour ce faire on créer le dossier /secrets dans le dossier qui contient le docker-compose du beats. Dans ce dossier secret on va créer le fichier secrets_beats.secrets et son contenu est par exemple pour metricbeat:

METRICBEAT_USERNAME=<nom_beat>
METRICBEAT_PASSWORD=<password>

Note: Pour curator, le comportement du yml de curator supporte mal les variables d’environnement. Pour pouvoir tout de même les utiliser, on va écrire directement la ligne du yaml. Il faut donc écrire:

CURATOR_AUTH_LINE=<nom_curator>:<password>

Ensuite il suffit de gérer l’authentification dans le docker-compose en donnant le fichier que l’on vient de créer comme fichier contenant les variables d’environnement:

env_file:
      - ./secrets/secrets_beats.secrets

Ensuite on peut utliser la variable d’environnement dans le fichier de config du beats.

On l’utilise en y faisant référance avec ${METRICBEAT_USERNAME} par exemple pour metricbeat.

Note: Les differents users elasticsearch possèdent ici tous le rôle de “superuser” néanmoins il existe différents types de rôle si besoin.

Les différents rôles sont définis sur cette page

WARNING: Pas possible avec la version community elasticsearch

Config du fichier elasticsearch.yml

xpack:
  security:
    authc:
      realms:
        ldap:
          ldap1:
            order: 0
            url: "ldap://ldap.picasoft.net:389"
            bind_dn: "cn=elasticsearch, ou=Services, dc=picasoft, dc=net"
            user_search:
              base_dn: "dc=picasoft ,dc=net"
              filter: "(cn={0})"
            group_search:
              base_dn: "dc=picasoft,dc=net"
            files:
              role_mapping: "./role_mapping.yml"
            unmapped_groups_as_roles: false

Il suffit ensuite de créer le fichier role_mapping.yml pour faire le lien entre les utilisateur d’un groupe ldap et les utilisateurs elasticsearch.

superuser:
  - "cn=admin,ou=Group,dc=picasoft,dc=net" 

Cette ligne permet par exemple de mapper tous les utilisateurs du groupe admin du ldap et de leur donner les droits superuser sur elasticsearch.

Notre solution marche globalement seulement en interne (elastalert, kkibana et elasticsearch communiquent sur un réseau docker spécifique). Néanmoins, deux ports sont exposé pour permettre la communication vers l’extérieur de ce réseau: Le port permettant de faire des requêtes à la BDD de elasticsearch,et le port permettant de se connecter à l’interface web de Kibana. Ces deux ports sont donc exposés via Traefik, qui nous permet de déléguer le chiffrement ssl, et la gestion des certificats.
Les adresses retenues sont kibana.picasoft.net pour kibana et monitoring.es.picasoft.net pour elasticsearch.