SIA

no task description

no task description

Scheduler:

• Depuis Ansible, déploiment de Cron/Timer Systemd
  • (+) Randomisation of timers
  • (+) Indépendant d'un système externe
  • (-) Logs et alertes à mettre en place séparement (mais théoriqement à faire de toute façon)
  • (-) Risque d'artéfacts (anciens timers/service/scripts/config non supprimés | dépend du bon dévellopement du rôle)
• Depuis AWX, jobs
  • Interface ?
  • Logs intégrés (non centralisés)
  • Alertes intégrées
  • Push button backup ?
  • (-) Tous les backups démarrés en même temps ?
  • (-) Dépendance à un système tiers pour le fonctionnement
• Depuis OpenShift: CronJobs
  • (-) Dépendance à un système tiers pour le fonctionnement (qui plus est très complexe)
  • (-) Logs ?

Software: BorgBackup

• Déduplication (moins d'espace utilisé)
• Incrémental (seul les données modifiés sont envoyées)
• Compression
• Gestion de la politique de rétention intégré
• Vérification de l'intégrité des backups

Implémentation serveur

• Un repo par VM
  • évite d'avoir à reload le cache sur la VM --> plus rapide
  • permet potentiellement de limiter l'accès à certains path pour chaque VM
• Utilisateur 'backup' unique
  • facilité de gestion
  • emplacement unique pour toutes les backups de VMs
  • filtrage par clé SSH possible (compliqué à gérer)

Implémentation clients

• Installation d'une clé SSH sur chaque VM
  • différente selon chaque hôte si l'on souhaite faire du filtrage
• Utilisateur executant le backup: root (assure un accès à tout le système de fichier)

Ansible playbooks

• Détection des hôtes pour les backups
  • Groupe spécifique ('backup')
  • Groupes existant (VM, machines physiques)
  • Variable hôte
• Initialisation
  • Création des repos
  • Déploiment des clés SSH (EC)
  • (si scheduler systemd timers) Déploiment des timers + services (+ script)
  • (si scheduler CronJobs) Déploiement du CronJob
• Exécution
  • (si scheduler AWX) Exécution d'un script de backup
• Update
  • /!\ Ne pas laisser d'artéfact sur les hôtes (script, services systemd)
  • Si suppression d'un dossier, suppression du dossier dans l'archive ?

Variables Ansible:

• Liste des paths par hôtes (+ par défaut)
• Liste des serveurs de backup
• Politique de rétention par hôte (+ par défaut)

Questionnements

• Filesystem snapshot ? or LVM ?
• Possibilité de backup vers deux systèmes différents depuis le client très facile (simple ajout d'URL)

Conformément aux principes des alertes, il est possible de monitorer avec les objectifs suivants:

Symptomes:

• Backup non crée sur le(s) serveur(s) de backup

Causes:

• Echec / Erreur du service
• Service systemd non présent

Dans un premier temps (par souci de rapidité); seul l'erreur du service déclenchera une alerte, depuis le node-exporter de prometheus.

no task description

Actuellement, les utilisateurs sont synchronisés via le LDAP, mais il n'existe pas d'utilisateur rescue dans le cas où le LDAP tombe.

Cela peut se voir avec un `oc get users`.

Il est impératif de créer un utilisateur de fallback et de l'indiquer dans le keepass

Question: devrait-on mettre les noms de VLANs dans le nom de domaine ?

Par exemple:

machine.prod.uttnetgroup.net
machine.admin.uttnetgroup.net

Cela concernerait-il uniquement le réseau interne ?

Cela implique de rajouter des search-domain pour les différents VLANs (potentiellement selon le profil d'utilisateur)

Met-on en place des CNAME vers les services en production et les machines du VLAN admin ?

Comment gère-t-on les NDD (nom de domaine) externe (uttnetgroup.fr).

Datastore 1:

• sdh: Raw_Read_Error_Rate: 11485

Datastore 2:

• sda ?: Raw_Read_Error_Rate: 163

Datastore 2 n'a pas l'air de tester ses disques régulièrement

Vérification: smartctl -a /dev/sdX

Avec Ansible, mise en place sur les hôtes

• Installation smartmontools
• Activation smartd (systemd)
• Alertes (erreur smart)
  • mails / prometheus
• Alerte (service non installé erreur)
  • enregistrement de l'hôte dans la liste des machines à surveiller

Ce qu'il manque au wiki actuel: notifications, copy and paste images

Features:

• Notifications (Missing Slack ?)
• No DB ? (fichiers textes direct)
• UI:
  • CLI Edits (git ?)
  • WebUI (+live preview)
• Copy and paste images (Missing): https://www.dokuwiki.org/plugin:imgpaste
• RBAC
• Intégration LDAP / SSO
• Git backend (https://www.dokuwiki.org/plugin:gitbacked)
• Section editing

L'objectif est de déployer les VMs depuis Ansible, afin de mettre en place un PRA. Cela implique donc la création des VMs sur Proxmox, l'installation des logiciels, et la restauration des backups.

Listes des VMs:

• FreeIPA (https://github.com/freeipa/ansible-freeipa)
• HA-Proxy
• Wiki
• ZoneMinder
• Prometheus (+ Alertmanager et PushGateway)

Il serait intéressant de visualiser les VMs déployées depuis Ansible vs déployées manuellement

Le but est de mettre en place un proxy des depots apt / yum afin de fluidifier les opérations de maj/installation.

Plusieurs projets opensources permettent de simplifier le job:

- Nexus3 https://github.com/ansible-ThoTeam/nexus3-oss

- Pulp3

no task description

Objectifs:

  - Assurer un fonctionnement d'urgence du SIA

  - Emplacement de backup suplémentaire (proche en terme de réseau, distant en terme d'alimentation et de climatisation)

Elements:

  - Virtualisation: Proxmox

  - Stockage: ? (NFS [NetAPP] + Ceph)

Services:

  - Logs

  - Repo Git

  - AWX

  - Netbox

DONE - Timeout dû à HA-Proxy sur Openshift

https://bugzilla.redhat.com/show_bug.cgi?id=1382730

Timeout dû à HA-Proxy (reverse-proxy principal)

https://www.haproxy.com/blog/websockets-load-balancing-with-haproxy/

Besoin de mettre à jour le rôle Ansible HA-Proxy: https://github.com/Oefenweb/ansible-haproxy

/!\ Consider setting up staging haproxy env before

https://github.com/Oefenweb/ansible-haproxy

Besoins de considérer les modifications custom faites (https://github.com/ungdev/ansible-infra/commits/master/roles/haproxy) :

• Upgrade page
  • https://github.com/ungdev/ansible-infra/commit/f0cf97398e27e63fb4c7df0c6410a772a38969b2#diff-a34e2a6d8ae0c8ae3aefa8051f36ffcb
• Maintenance page
  • https://github.com/ungdev/ansible-infra/commit/ab217921916438aa4a20dffc495610919a4df5b6#diff-a34e2a6d8ae0c8ae3aefa8051f36ffcb
  • https://github.com/ungdev/ansible-infra/commit/93d7e76bdd5bc6a6088817bea62526c8f4b26c54#diff-a34e2a6d8ae0c8ae3aefa8051f36ffcb
  • https://github.com/ungdev/ansible-infra/commit/e38bd2449ceca09701cb894b74486d7b30fcd55b#diff-a34e2a6d8ae0c8ae3aefa8051f36ffcb
• OSO Error page
  • https://github.com/ungdev/ansible-infra/commit/a7318d971284bbcb93819c624e86e45a9da94d91#diff-a34e2a6d8ae0c8ae3aefa8051f36ffcb
• Fix module error with dirty integration
  • https://github.com/ungdev/ansible-infra/commit/a971de2fc1783cf1cfb5efd93aa3130da464ef9a#diff-a34e2a6d8ae0c8ae3aefa8051f36ffcb
• Disable firewalld integration (Already removed in latest versions)
  • https://github.com/ungdev/ansible-infra/commit/e93eb8b6f6e55b2f098538a471c8a9489ced6540#diff-a34e2a6d8ae0c8ae3aefa8051f36ffcb

Gestion des comptes locaux

Monitoring des machines

  Alertes

    Accès root

    Modification de la configuration depuis la machine (VS Ansible)

Monitoring réseau (IDS)

  Gestion des logs des paquets

  Alertes sur firewall rule 'block'

Vulnerability scanner

WAF

Idée en vrac:

Transmettre la liste des administrateurs du SIA au CRI

Liste des timers (utilisateurs)

Liste des crons (utilisateurs)

Liste des cronjobs

Compte Root

• SSH Public Key:  clés SSH des admins (sur le LDAP)
• Password: Unique ou généré aléatoirement ?

utile en cas de soucis de règle sudo)

Comptes administrateurs

• Sync des comptes FreeIPA du groupe `admins`:
  • Username: <ldap_username>_admin
  • SSH public key: public key from ldap
  • Password: hash from ldap
• Accès sudo passwordless

Compte ansible

• Password: ?
• Clé SSH: Clé sur LDAP

Custom field has been created for:

• device_ansible_groups
• vm_ansible_groups

Need to update:

• netbox inventory script
• netbox sync playbook

Besoin de demander le NDD au CRI

Il est possible de se connecter sur osticket avec le ldap, mais il n'y a pas de gestion des groupes administrateurs.

Il faut donc faire une synchronisation entre le serveur ldap et la db d'osticket.

Conf DNS
 * -> haproxy sur uttnetgroup.net
*.staging -> haproxy sur uttnetgroup.net
*.staging -> haproxy sur uttnetgroup.fr avec un header d'authentification relié en statique puis à terme au LDAP

no task description

Make openshift-backup remove projects not present on the cluster anymore.

no task description

Loadbalancing IP

L'OSD 33 est tombé début avril 2020.

Il serait interessant d'investuguer dessus, voire éventuellement de le remplacer.

Négocier un accès SSH au CRI, en passant par un bastion dont ils auraient le contrôle.

Faire un prototype avant pour leur montrer.

Host on Openshift

One section per association, with ACLs per association

no task description

Solutions possibles :

  - Mattermost : Pas d'intégration LDAP, possible de passer par gitlab

  - Zulip : Nice threading feature

  - Rocketchat

Needs to implement :

  - notifications

  - roles throught LDAP / SSO

Possible solutions

• Redmine
• Openproject
  • Kanboard only entreprise feature
• Kanboard ?

Implement SSO

Solution : Keycloak

no task description

no task description

https://github.com/aquasecurity/kube-hunter

no task description

no task description

Actuellement, prometheus n'est pas monitoré, cela implique que si aucune alerte n'apparaît, cela peut être parce que prometheus est down.

Déployer un prometheus sur vps1 semble être la solution la plus adéquate

Rename switches to a better naming system (location, usage), in DNS + Hostname

• switch
• switch1
• switch2
• switch3

Faire un playbook Ansible pour déployer le système de logs:

• installation du serveur de log ? (sauf si déployé sur Openshift)
• configuration des hôtes et des VMs pour centraliser les logs

no task description

no task description

Effectuer des backups régulier des repos git ( herbergés au SIA, sur Github et sur Gitlab)

Serveurs git sur les serveurs de backup

WARNING: Don't deploy before setting root password through Ansible 

L'objectif est de migrer le portail captif du réseau UNG vers une VM dédiée.

Besoins :

• Support des groupes LDAP
• Authorisation MAC
• Attribution IP en fonction du groupe LDAP

La première étape est de déployer une solution de portail captif intégrant un DHCP sur le VLAN CRI_UNG

La deuxième étape est soit de:

• mettre la gateway par défaut dans le DHCP comme étant le portail captif, et de n'authoriser (par le firewall)  sur le routeur UNG que les paquets issus du portail captif
• mettre un réseau dédié entre le routeur UNG et le portail captif, et enlever le routeur UNG du réseau CRI_UNG

Rajout de la zone DNS campus3.fr en tant que slave sur VPS1

no task description