chore: update README

README.md

@@ -5,9 +5,18 @@
 
 Bastions are a cluster of machines used as the unique entry point by operational teams (such as sysadmins, developers, database admins, ...) to securely connect to devices (servers, virtual machines, cloud instances, network equipment, ...), usually using `ssh`.
 
-Bastions provides mechanisms for authentication, authorization, traceability and auditability for the whole infrastructure.
+Bastions provide mechanisms for authentication, authorization, traceability and auditability for your whole infrastructure.
 
-Learn more by reading the blog post series that announced the release:
+Being between your users and your infrastructure devices, bastions add a layer of abstraction in-between so that your infrastructure doesn't need to know your operational team members individually.
+It also means that you can lock your devices firewall down by only allowing bastions access to their SSH port. For ancient devices that might only support old low-security cryptography algorithms or only allow telnet altogether, you can hide them from the Internet and let The Bastion handle this on the egress connection, while still allowing only high-security grade connections on the ingress side.
+
+Each of your team member has an individual account on The Bastion, and may be a member of one or several bastion groups that may give them access to one or more infrastructures. The infrastructure devices only need to know and trust the bastion group(s) they may be a part of.
+
+The Bastion fine-grained RBAC makes it possible to delegate some responsibilities to any account, group-scoped or bastion-wide, including to accounts that might be used by your automation to e.g. managing the lifecycle of the accounts (linked to your human resources management system, your LDAP or AD), ensure a group's ACL is up to date (linked to your CMDB), etc. Automated processes are easy to implement through the [JSON API over SSH](https://ovh.github.io/the-bastion/using/api.html).
+
+Authentication features include support for MFA/2FA (password, TOTP) in addition to publickey authentication, and support for hardware-based keys (including PIV support).
+
+Want to know more while viewing some nice drawings? Here is a series of blog posts that dig more into the core functionalities and principles of The Bastion:
 - [Part 1 - Genesis](https://blog.ovhcloud.com/the-ovhcloud-bastion-part-1/)
 - [Part 2 - Delegation Dizziness](https://blog.ovhcloud.com/the-ovhcloud-ssh-bastion-part-2-delegation-dizziness/)
 - [Part 3 - Security at the Core](https://blog.ovhcloud.com/the-bastion-part-3-security-at-the-core/)
@@ -17,6 +26,23 @@ Learn more by reading the blog post series that announced the release:
 
 [![asciicast](https://asciinema.org/a/369555.png)](https://asciinema.org/a/369555?autoplay=1)
 
+## :godmode: Quick non-exhaustive features list
+
+- Personal and group access schemes with group roles delegation to ensure teams autonomy without security trade-offs
+- SSH protocol break between the ingress and egress connections
+- Self-reliance achieved through virtually no external dependencies (network or otherwise, including for authentication)
+- Interactive session recording (in standard ttyrec files)
+- Non-interactive session recording (stdout and stderr through ttyrec)
+- Extensive logging support through syslog for easy SIEM consumption
+- Supports [mosh](https://github.com/mobile-shell/mosh) on the ingress connection side
+- Supports scp, sftp and rsync passthrough, to upload and/or download files from/to remote servers
+- Supports netconf SSH subsystem passthrough
+- Supports Yubico PIV keys attestation checking and enforcement on the ingress connection side
+- Supports realms, to create a trust between two bastions of possibly two different companies, splitting the authentication and authorization phases while still enforcing local policies
+- Supports SSH password autologin on the egress side for legacy devices not supporting pubkey authentication, while still forcing proper pubkey authentication on the ingress side
+- Supports telnet password autologin on the egress side for ancient devices not supporting SSH, while still forcing proper SSH pubkey authentication on the ingress side
+- Supports HTTPS proxying with man-in-the-middle authentication and authorization handling, for ingress and egress password decoupling (mainly useful for network device APIs)
+
 ## :wrench: Installing, upgrading, using The Bastion
 
 Please see the [online documentation](https://ovh.github.io/the-bastion/), or the corresponding text-based version found in the `doc/` folder.
@@ -73,8 +99,8 @@ Also don't forget to customize your `bastion.conf` file, which can be found in `
 Linux distros below are tested with each release, but as this is a security product, you are **warmly** advised to run it on the latest up-to-date stable version of your favorite OS:
 
 - Debian 12 (Bookworm), 11 (Bullseye), 10 (Buster)
-- RockyLinux 8.x, 9.x
-- Ubuntu LTS 22.04, 20.04, 18.04
+- RockyLinux 9.x, 8.x
+- Ubuntu LTS 24.04, 22.04, 20.04, 18.04
 - OpenSUSE Leap 15.5\*
 
 \*: Note that these versions have no out-of-the-box MFA support, as they lack packaged versions of `pamtester`, `pam-google-authenticator`, or both. Of course, you may compile those yourself.
@@ -162,6 +188,12 @@ Even with the most conservative, precautionous and paranoid coding process, code
 - [the-bastion-ansible-wrapper](https://github.com/ovh/the-bastion-ansible-wrapper) - a wrapper to make it possible to run Ansible playbooks through The Bastion
 - [debian-cis](https://github.com/ovh/debian-cis) - a script to apply and monitor the hardening of Debian hosts as per the [CIS](https://www.cisecurity.org/benchmark/debian_linux/) recommendations
 
+### Community tools
+
+A non-exhaustive list of related tools that are maintained by the community:
+
+- [chef-cookbook](https://github.com/axl89/ovh_the_bastion) - a chef cookbook to install the-bastion and setup its default configuration
+
 ## :memo: License
 
 Licensed under the Apache License, Version 2.0 (the "License");