L'installation de Container Linux by CoreOS nécessite qu'un fichier de configuration soit fourni : le fichier ignition.json.

Celui-ci comporte les informations permettant de créer les utilisateurs et de fabriquer les fichiers de configuration du serveur ssh, du pare feu Iptables, des unités systemd, et bien plus encore.

Fichier de configuration Container Linux

Le fichier ignition.json est généré à partir d'un fichier de configuration Container Linux au format YAML.

Le workflow est le suivant :

Voici un exemple de fichier de configuration :

passwd:
  users:
    - name: core
      ssh_authorized_keys:
        - ssh-rsa AAAAAb3a...............

systemd:
  units:
    - name: iptables-restore.service
      enable: true
    - name: docker.service
      enable: true

locksmith:
  reboot_strategy: reboot
  window_start: 04:00
  window_length: 1h

storage:
  files:
    - path: /etc/ssh/sshd_config
      filesystem: root
      mode: 0600
      contents:
        inline: |
          # Supported HostKey algorithms by order of preference.
          HostKey /etc/ssh/ssh_host_ed25519_key
          HostKey /etc/ssh/ssh_host_rsa_key
          HostKey /etc/ssh/ssh_host_ecdsa_key

          KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

          Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

          MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

          # Password based logins are disabled - only public key based logins are allowed.
          AuthenticationMethods publickey

          # LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in.
          LogLevel VERBOSE

          # Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.
          Subsystem sftp  /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO

          # Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user:
          #
          # On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH.
          # Additionally, only tools such as systemd and auditd record the process session id.
          # On other OSes, the user session id is not necessarily recorded at all kernel-side.
          # Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track.
          PermitRootLogin No

          # Use kernel sandbox mechanisms where possible in unprivileged processes
          # Systrace on OpenBSD, Seccomp on Linux, seatbelt on MacOSX/Darwin, rlimit elsewhere.
          UsePrivilegeSeparation sandbox

          AllowUsers core
    - path: /var/lib/iptables/rules-save
      filesystem: root
      mode: 0644
      contents:
        inline: |
          *filter
          :INPUT DROP [0:0]
          :FORWARD DROP [0:0]
          :OUTPUT ACCEPT [0:0]
          -A INPUT -i lo -j ACCEPT
          -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
          -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
          -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
          -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
          -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
          -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
          -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
          COMMIT
          #

Dans cet exemple :

  • un utilisateur est créé avec une clé ssh publique,
  • 2 fichiers de configurations sont créés : /etc/ssh/sshd_config et /var/lib/iptables/rules-save,
  • les unités systemd iptables-restore.service et docker.service sont lancées automatiquement au démarrage du système : la première permet d'activer Iptables, la seconde permet le redémarrage automatique des conteneurs Docker lorsque le système est rebooté,
  • la stratégie de redémarrage "reboot" est appliquée : CoreOS a le droit de rebooter entre 4h et 5h du matin une fois ses mises à jour installées.

D'autres exemples sont disponibles ici : https://coreos.com/os/docs/latest/clc-examples.html.

Remarque : pour provisionner un cluster Container Linux by CoreOS, l'utilitaire matchbox est plus adapté que la méthode manuelle décrite dans cet article : https://github.com/coreos/matchbox/.

Transpilation

La génération du fichier ignition à partir du fichier de configuration peut se faire de plusieurs manières.

Méthode simple et rapide avec Docker

La méthode la plus simple et la plus rapide est de passer par Docker. Si Docker est installé sur votre poste de travail, il vous suffit de lancer la commande suivante :

docker run -i quay.io/coreos/ct:latest-dev --pretty < container_linux_config.yml > ignition.json

Méthode classique

Il est aussi possible de récupérer directement le binaire "Config Transpiler" adapté à votre système d'exploitation sur cette page : https://github.com/coreos/container-linux-config-transpiler/releases.

Sous Linux

wget https://github.com/coreos/container-linux-config-transpiler/releases/download/v0.9.0/ct-v0.9.0-x86_64-unknown-linux-gnu -O ct

chmod u+x ct

./ct --pretty < container_linux_config.yml > ignition.json

Sous MacOS

curl -L -o ct https://github.com/coreos/container-linux-config-transpiler/releases/download/v0.9.0/ct-v0.9.0-x86_64-apple-darwin

chmod u+x ct

./ct --pretty < container_linux_config.yml > ignition.json

Sous Windows

Téléchargez l'utilitaire ct à l'adresse suivante : https://github.com/coreos/container-linux-config-transpiler/releases/download/v0.9.0/ct-v0.9.0-x86_64-pc-windows-gnu.exe.

Déplacez l'exécutable ct-v0.9.0-x86_64-pc-windows-gnu.exe dans le répertoire contenant votre fichier de configuration Container Linux.

Ouvrez une invite de commande et lancez les commandes suivantes :

cd Repertoire/ContainerLinuxConfiguration

ct-v0.9.0-x86_64-pc-windows-gnu.exe --pretty < container_linux_config.yml > ignition.json

Résultat

Le fichier ignition.json résultant de la transpilation doit ressembler à :

{
  "ignition": {
    "config": {},
    "security": {
      "tls": {}
    },
    "timeouts": {},
    "version": "2.2.0"
  },
  "networkd": {},
  "passwd": {
    "users": [
      {
        "name": "core",
        "sshAuthorizedKeys": [
          "ssh-rsa AAAAAb3a..............."
        ]
      }
    ]
  },
  "storage": {
    "files": [
      {
        "filesystem": "root",
        "path": "/etc/ssh/sshd_config",
        "contents": {
          "source": "data:,%23%20Supported%20HostKey%20algorithms%20by%20order%20of%20preference.%0AHostKey%20%2Fetc%2Fssh%2Fssh_host_ed25519_key%0AHostKey%20%2Fetc%2Fssh%2Fssh_host_rsa_key%0AHostKey%20%2Fetc%2Fssh%2Fssh_host_ecdsa_key%0A%0AKexAlgorithms%20curve25519-sha256%40libssh.org%2Cecdh-sha2-nistp521%2Cecdh-sha2-nistp384%2Cecdh-sha2-nistp256%2Cdiffie-hellman-group-exchange-sha256%0A%0ACiphers%20chacha20-poly1305%40openssh.com%2Caes256-gcm%40openssh.com%2Caes128-gcm%40openssh.com%2Caes256-ctr%2Caes192-ctr%2Caes128-ctr%0A%0AMACs%20hmac-sha2-512-etm%40openssh.com%2Chmac-sha2-256-etm%40openssh.com%2Cumac-128-etm%40openssh.com%2Chmac-sha2-512%2Chmac-sha2-256%2Cumac-128%40openssh.com%0A%0A%23%20Password%20based%20logins%20are%20disabled%20-%20only%20public%20key%20based%20logins%20are%20allowed.%0AAuthenticationMethods%20publickey%0A%0A%23%20LogLevel%20VERBOSE%20logs%20user's%20key%20fingerprint%20on%20login.%20Needed%20to%20have%20a%20clear%20audit%20track%20of%20which%20key%20was%20using%20to%20log%20in.%0ALogLevel%20VERBOSE%0A%0A%23%20Log%20sftp%20level%20file%20access%20(read%2Fwrite%2Fetc.)%20that%20would%20not%20be%20easily%20logged%20otherwise.%0ASubsystem%20sftp%20%20%2Fusr%2Flib%2Fssh%2Fsftp-server%20-f%20AUTHPRIV%20-l%20INFO%0A%0A%23%20Root%20login%20is%20not%20allowed%20for%20auditing%20reasons.%20This%20is%20because%20it's%20difficult%20to%20track%20which%20process%20belongs%20to%20which%20root%20user%3A%0A%23%0A%23%20On%20Linux%2C%20user%20sessions%20are%20tracking%20using%20a%20kernel-side%20session%20id%2C%20however%2C%20this%20session%20id%20is%20not%20recorded%20by%20OpenSSH.%0A%23%20Additionally%2C%20only%20tools%20such%20as%20systemd%20and%20auditd%20record%20the%20process%20session%20id.%0A%23%20On%20other%20OSes%2C%20the%20user%20session%20id%20is%20not%20necessarily%20recorded%20at%20all%20kernel-side.%0A%23%20Using%20regular%20users%20in%20combination%20with%20%2Fbin%2Fsu%20or%20%2Fusr%2Fbin%2Fsudo%20ensure%20a%20clear%20audit%20track.%0APermitRootLogin%20No%0A%0A%23%20Use%20kernel%20sandbox%20mechanisms%20where%20possible%20in%20unprivileged%20processes%0A%23%20Systrace%20on%20OpenBSD%2C%20Seccomp%20on%20Linux%2C%20seatbelt%20on%20MacOSX%2FDarwin%2C%20rlimit%20elsewhere.%0AUsePrivilegeSeparation%20sandbox%0A%0AAllowUsers%20core%0A",
          "verification": {}
        },
        "mode": 384
      },
      {
        "filesystem": "root",
        "path": "/var/lib/iptables/rules-save",
        "contents": {
          "source": "data:,*filter%0A%3AINPUT%20DROP%20%5B0%3A0%5D%0A%3AFORWARD%20DROP%20%5B0%3A0%5D%0A%3AOUTPUT%20ACCEPT%20%5B0%3A0%5D%0A-A%20INPUT%20-i%20lo%20-j%20ACCEPT%0A-A%20INPUT%20-m%20conntrack%20--ctstate%20RELATED%2CESTABLISHED%20-j%20ACCEPT%0A-A%20INPUT%20-p%20tcp%20-m%20tcp%20--dport%2022%20-j%20ACCEPT%0A-A%20INPUT%20-p%20tcp%20-m%20tcp%20--dport%2080%20-j%20ACCEPT%0A-A%20INPUT%20-p%20tcp%20-m%20tcp%20--dport%20443%20-j%20ACCEPT%0A-A%20INPUT%20-p%20icmp%20-m%20icmp%20--icmp-type%200%20-j%20ACCEPT%0A-A%20INPUT%20-p%20icmp%20-m%20icmp%20--icmp-type%203%20-j%20ACCEPT%0A-A%20INPUT%20-p%20icmp%20-m%20icmp%20--icmp-type%2011%20-j%20ACCEPT%0ACOMMIT%0A%23",
          "verification": {}
        },
        "mode": 420
      },
      {
        "filesystem": "root",
        "path": "/etc/coreos/update.conf",
        "contents": {
          "source": "data:,%0AREBOOT_STRATEGY%3D%22reboot%22%0ALOCKSMITHD_REBOOT_WINDOW_START%3D%2204%3A00%22%0ALOCKSMITHD_REBOOT_WINDOW_LENGTH%3D%221h%22",
          "verification": {}
        },
        "mode": 420
      }
    ]
  },
  "systemd": {
    "units": [
      {
        "enable": true,
        "name": "iptables-restore.service"
      },
      {
        "enable": true,
        "name": "docker.service"
      }
    ]
  }
}

Plateforme cible

N'oubliez pas de spécifier la plateforme cible à l'utilitaire ct.

Si vous installez CoreOS sur la plateforme AWS d'Amazon, rajoutez le paramètre --platform=ec2.

./ct --pretty --platform=ec2 < container_linux_config.yml > ignition.json

Si vous installez CoreOS sur la plateforme Google Cloud Platform, rajoutez le paramètre --platform=gce.

./ct --pretty --platform=gce < container_linux_config.yml > ignition.json

Les options disponibles sont :

azure digitalocean ec2 gce packet openstack-metadata vagrant-virtualbox cloudstack-configdrive custom

Enfin si vous installez CoreOS sur un serveur physique, inutile de spécifier la plateforme.

Installation

Une fois le fichier ignition.json créé, il vous reste à l'uploader sur votre serveur et à le passer au script d'installation de CoreOS :

coreos-install -d /dev/sda -C stable -i ignition.json

Pour de plus amples informations sur l'installation de CoreOS, voir les liens suivants :

À bientôt !