Sécuriser les clusters Kubernetes avec un Cloud Penetration Testing

Vous avez probablement entendu l'expression : « Kubernetes est le système d'exploitation du cloud ». Pour beaucoup d'entre nous dans le domaine du DevOps et de la sécurité, c'est tout à fait vrai. C'est puissant, ça s'adapte comme dans un rêve et ça gère l'orchestration des conteneurs d'une manière qui rend le déploiement d'applications complexes gérable. Mais voici le problème : Kubernetes est aussi incroyablement complexe. Lorsque vous avez un système avec autant de pièces mobiles (pods, nœuds, services, ingresses et un serveur d'API massif), la surface d'attaque est énorme.

La plupart des équipes commencent avec une configuration par défaut ou suivent un guide de démarrage rapide. Cela fonctionne pour mettre l'application en ligne, mais rarement pour empêcher les méchants d'entrer. Une simple politique de contrôle d'accès basé sur les rôles (RBAC) mal configurée ou un conteneur fonctionnant en tant que root peut donner à un attaquant un chemin direct d'un serveur web public à tous les secrets de votre cluster. C'est un scénario cauchemardesque, mais cela arrive plus souvent qu'on ne veut bien l'admettre.

C'est là où le cloud Penetration Testing entre en jeu. Vous ne pouvez pas simplement exécuter un scanner de réseau standard et considérer que c'est suffisant. Les clusters modernes ont besoin d'un type d'examen spécifique, qui comprenne comment les conteneurs communiquent entre eux et comment la couche d'orchestration peut être trompée. En simulant des attaques réelles de manière contrôlée, vous trouvez les failles avant que quelqu'un d'autre ne le fasse.

Dans ce guide, nous allons plonger en profondeur dans la façon de sécuriser vos clusters Kubernetes. Nous examinerons les vulnérabilités spécifiques qui affectent les environnements K8s et pourquoi une approche native du cloud en matière de Penetration Testing est la seule façon de garder une longueur d'avance.

Comprendre la surface d'attaque de Kubernetes

Avant de parler de la façon de tester, nous devons comprendre ce que nous testons réellement. Kubernetes n'est pas seulement un logiciel ; c'est un écosystème. Si vous le traitez comme une VM traditionnelle, vous passez à côté de la plupart des risques.

Le plan de contrôle : le cerveau de l'opération

Le plan de contrôle est la partie la plus sensible de votre cluster. Si un attaquant accède au serveur d'API, c'est la fin. Il peut créer des pods, voler des secrets et arrêter toute votre infrastructure. Les risques courants ici incluent :

Accès API non authentifié : Parfois, le serveur d'API est accidentellement exposé à l'internet public sans authentification appropriée.
Configurations Kubelet non sécurisées : Si le Kubelet (l'agent sur chaque nœud) n'est pas sécurisé, un attaquant peut exécuter des commandes directement sur le nœud.
Vulnérabilités Etcd : Etcd est l'endroit où K8s stocke toutes ses données. Si la base de données etcd n'est pas chiffrée ou restreinte, les secrets de votre cluster sont essentiellement en clair.

Le plan de données : là où le travail se fait

C'est là que vivent vos pods et vos conteneurs. Alors que le plan de contrôle est le cerveau, le plan de données est le muscle, et c'est là que se produisent la plupart des violations initiales.

Communication Pod-à-Pod : Par défaut, K8s permet à n'importe quel pod de parler à n'importe quel autre pod. Si un pod frontal est compromis, l'attaquant peut se déplacer latéralement vers un pod de base de données backend sans aucune résistance.
Conteneurs privilégiés : Certains conteneurs sont exécutés en tant que « privilégiés », ce qui signifie qu'ils ont presque le même accès que la machine hôte. Si ce conteneur est violé, l'attaquant peut « sortir » du conteneur et prendre le contrôle du nœud réel.
Registres d'images non sécurisés : Si vous téléchargez des images à partir d'un registre public sans les vérifier, vous pourriez déployer un conteneur qui a déjà une porte dérobée installée.

La couche réseau : l'autoroute invisible

La mise en réseau de Kubernetes est une bête. Entre le CNI (Container Network Interface), les contrôleurs Ingress et les Service meshes, il y a beaucoup d'endroits où les choses peuvent mal tourner. Un Ingress mal configuré peut exposer des services internes au monde, et un manque de Network Policies signifie que votre trafic « interne » est grand ouvert.

Pourquoi l'analyse de sécurité traditionnelle n'est pas suffisante

Si vous avez un scanner de vulnérabilités qui vérifie les versions de logiciels obsolètes, vous faites le strict minimum. C'est bien pour la conformité, mais ce n'est pas de la sécurité. Voici pourquoi l'analyse traditionnelle échoue dans un monde Kubernetes.

Risque statique vs. dynamique

Une analyse statique vous indique que votre image a un CVE (Common Vulnerabilities and Exposures) connu. C'est utile, mais cela ne vous dit pas si cette vulnérabilité est réellement accessible. Par exemple, une bibliothèque peut avoir une faille, mais si votre application n'appelle jamais cette bibliothèque, le risque est nul. Inversement, votre logiciel peut être 100 % à jour, mais vos permissions RBAC peuvent permettre à n'importe quel utilisateur de supprimer l'ensemble de l'espace de noms. Un scanner statique ne trouvera jamais cela.

La complexité du trafic « Est-Ouest »

La plupart des pare-feu traditionnels se concentrent sur le trafic « Nord-Sud » : ce qui entre de l'internet et ce qui en sort. Mais dans K8s, le vrai danger est le trafic « Est-Ouest », la communication entre les pods. Les scanners traditionnels se trouvent généralement à l'extérieur du cluster. Ils ne peuvent pas voir ce qui se passe à l'intérieur du réseau de pods. Le cloud Penetration Testing, cependant, simule un attaquant qui a déjà pris pied, vous permettant de voir exactement jusqu'où il peut se déplacer.

Éphémérité et dérive

Les conteneurs sont censés être de courte durée. Ils se lancent, font leur travail et meurent. Cela crée un problème de « dérive ». Vous pouvez scanner votre image dans le pipeline CI/CD et constater qu'elle est propre. Mais une fois qu'elle est en cours d'exécution dans le cluster, un exploit d'exécution pourrait modifier l'état de ce conteneur. Si vous ne faites pas de tests actifs basés sur le cloud, vous vous fiez à un instantané de la sécurité d'il y a trois semaines.

Plongée en profondeur : Vulnérabilités Kubernetes courantes et comment les tester

Pour vraiment sécuriser un cluster, vous devez penser comme un attaquant. Voici les façons les plus courantes dont les clusters sont violés et comment un testeur de pénétration (ou une plateforme comme Penetrify) les identifierait.

1. RBAC Sur-Permissionnement

Le Role-Based Access Control (RBAC) est au cœur de la sécurité K8s. Le problème est qu'il est difficile de bien le configurer. De nombreuses équipes attribuent le rôle cluster-admin aux comptes de service juste pour que "ça marche".

Le Scénario d'Attaque : Un attaquant trouve une vulnérabilité dans une application web s'exécutant dans un pod. Il découvre que le compte de service du pod a les permissions pour list secrets à travers tout le cluster. Il utilise cela pour voler le jeton API d'un compte plus privilégié, escaladant ainsi ses privilèges à l'administrateur du cluster.

Comment Tester :

Auditez tous les ClusterRoleBindings.
Recherchez tout compte de service avec des permissions * (caractère générique).
Utilisez des outils comme kubectl auth can-i pour vérifier ce qu'un pod spécifique peut réellement faire.
Essayez de passer d'un pod à faible privilège au serveur API pour voir si vous pouvez extraire des secrets d'autres namespaces.

2. Évasions de Conteneur (Échappée vers l'Hôte)

Le but principal d'un conteneur est l'isolation. Mais si le conteneur est mal configuré, cette isolation est un mensonge.

Le Scénario d'Attaque : Un conteneur est exécuté avec des montages hostPath, ce qui signifie qu'il peut voir le système de fichiers de l'hôte. L'attaquant obtient l'accès au pod et se rend compte qu'il peut voir /etc/shadow sur le nœud physique réel. Il vole le mot de passe root du nœud et maintenant il contrôle le matériel.

Comment Tester :

Vérifiez si des pods sont exécutés en tant que privileged: true.
Recherchez les montages hostPath, en particulier ceux pointant vers des répertoires sensibles comme /etc ou /var/run/docker.sock.
Tentez d'exécuter un processus dans le conteneur qui peut accéder aux interfaces réseau ou à la liste des processus de l'hôte.

3. Accès Non Sécurisé au Serveur API

Le serveur API est le "cerveau". S'il est exposé, le cluster est une cible facile.

Le Scénario d'Attaque : Un développeur ouvre le port du serveur API (6443) au monde entier pour faciliter le débogage depuis chez lui. Il oublie de le désactiver. Un attaquant trouve le port ouvert, essaie des mots de passe par défaut courants ou découvre un endpoint non authentifié, et commence à manipuler le cluster.

Comment Tester :

Effectuez un scan de port sur les adresses IP publiques du cluster.
Testez l'accès non authentifié aux endpoints /api ou /healthz.
Vérifiez que TLS est correctement implémenté et que les certificats ne sont pas expirés ou auto-signés d'une manière qui permet les attaques de l'homme du milieu.

4. Manque de Segmentation Réseau

Par défaut, K8s est un réseau "plat". Le Pod A peut communiquer avec les Pod B, C et Z.

Le Scénario d'Attaque : Un pod frontend exposé au public est compromis. L'attaquant utilise un outil comme nmap à l'intérieur du pod pour scanner le reste du réseau interne. Il trouve un cache Redis non protégé contenant des jetons de session et une base de données sans mot de passe parce qu'elle "n'accepte que le trafic interne".

Comment Tester :

Déployez un "pod attaquant" dans un namespace.
Essayez de curl ou ping des pods dans d'autres namespaces.
Vérifiez si les NetworkPolicies sont réellement appliquées ou si elles sont juste "recommandées" dans un document quelque part.

Un Cadre Étape par Étape pour le Penetration Testing Kubernetes

Si vous êtes chargé de sécuriser votre cluster, ne vous contentez pas de cliquer sur des boutons. Vous avez besoin d'une méthodologie. Voici une approche structurée du cloud Penetration Testing pour Kubernetes.

Phase 1 : Reconnaissance et Collecte d'Informations

Avant d'attaquer, vous devez savoir à quoi vous avez affaire.

Identifier la Distribution : Est-ce EKS, GKE, AKS ou un cluster auto-géré ? Chacun a des paramètres de sécurité par défaut différents.
Cartographier la Surface : Listez tous les points d'entrée Ingress exposés au public, les LoadBalancers et l'adresse du serveur API.
Analyser les Images : Si vous avez accès au registre, scannez les images pour les vulnérabilités connues.

Phase 2 : Accès Initial

Comment un acteur malveillant met-il le pied dans la porte ?

Exploits d'Application : Recherchez les injections SQL ou l'exécution de code à distance (RCE) dans les applications s'exécutant sur le cluster.
Informations d'Identification Divulguées : Recherchez sur GitHub, GitLab ou les wikis internes les fichiers kubeconfig ou les jetons de compte de service divulgués.
Attaques de la Chaîne d'Approvisionnement : Vérifiez si des charts Helm ou des images tiers utilisés ne sont pas fiables.

Phase 3 : Post-Exploitation et Mouvement Latéral

Une fois à l'intérieur d'un pod, le but est de se déplacer.

Vol de Jeton de Compte de Service : Recherchez dans /var/run/secrets/kubernetes.io/serviceaccount/token. C'est le "ticket d'or" pour se déplacer dans le cluster.
Scan Interne : Utilisez netcat ou curl pour trouver d'autres services s'exécutant sur la plage d'adresses IP interne du cluster.
Énumération DNS : Utilisez le CoreDNS interne pour trouver les noms des autres services dans le cluster.

Phase 4 : Escalade de Privilèges

Maintenant, passez de "Je suis un pod" à "Je suis l'administrateur".

Énumération RBAC : Utilisez le jeton volé pour voir quelles permissions vous avez. Pouvez-vous créer des pods ? Pouvez-vous lister les secrets ?
Évasion de Nœud : Si vous êtes dans un conteneur privilégié, essayez d'accéder au système de fichiers de l'hôte.
Usurpation de Jeton : Vérifiez si vous pouvez utiliser kubectl pour usurper l'identité d'autres utilisateurs.

Phase 5 : Exfiltration de Données et Impact

L'étape finale consiste à prouver le risque.

Vol de Secret : Pouvez-vous extraire le mot de passe de la base de données ou les clés API d'un K8s Secret ?
Manipulation des Ressources : Pouvez-vous déployer un pod de crypto-minage sans être détecté ?
Déni de Service : Pouvez-vous planter le serveur API ou supprimer des namespaces critiques ?

Implémentation d'un Modèle de Sécurité Continu

Les tests de Penetration Testing ponctuels sont excellents, mais ils ne sont qu'un instantané dans le temps. Dans un monde où vous déployez une douzaine de fois par jour, un test du mois dernier est fondamentalement inutile. Vous avez besoin d'un moyen de rendre la sécurité continue.

Intégration des tests dans le CI/CD

L'objectif est de déplacer la sécurité vers la "gauche". Cela signifie trouver les failles avant même que le code n'atteigne le cluster de production.

Infrastructure as Code (IaC) Scanning : Utilisez des outils pour analyser vos fichiers Terraform ou YAML à la recherche d'erreurs de configuration (comme les conteneurs privilégiés) avant qu'ils ne soient appliqués.
Image Signing : Utilisez des outils comme Cosign pour vous assurer que seules les images signées par votre pipeline de construction peuvent être déployées.
Admission Controllers : Mettez en œuvre un moteur de politiques (comme OPA Gatekeeper ou Kyverno) qui rejette automatiquement tout pod qui ne répond pas aux normes de sécurité (par exemple, "Aucun pod ne s'exécute en tant que root").

Le rôle du Penetration Testing automatisé dans le cloud

C'est là que l'équilibre change. Vous ne pouvez pas raisonnablement exécuter un Penetration Test manuel complet à chaque fois que vous poussez un commit. Mais vous ne pouvez pas non plus vous fier uniquement aux scanners statiques.

C'est précisément pour cela que nous avons créé Penetrify. Au lieu de choisir entre des "tests manuels lents" et des "analyses automatisées superficielles", Penetrify fournit une plateforme native du cloud qui automatise les parties complexes du Penetration Testing. Il peut simuler les mouvements latéraux et les chemins d'élévation de privilèges dont nous avons parlé, mais il le fait d'une manière qui s'adapte à votre infrastructure.

En utilisant une plateforme basée sur le cloud, vous n'avez pas à passer des semaines à mettre en place l'infrastructure pour tester votre cluster. Vous pouvez lancer des évaluations à la demande, voir exactement comment un attaquant se déplacerait dans vos pods et obtenir un plan de correction clair qui indique à vos développeurs exactement ce qu'il faut corriger.

Comparaison des approches de sécurité : Scanner vs. Pentest vs. Penetrify

Il peut être déroutant de savoir quel outil utiliser et quand. Voici une ventilation simple.

Fonctionnalité	Scanner de vulnérabilités	Pentest manuel	Penetrify
Vitesse	Rapide / Instantané	Lent / Semaines	Rapide / À la demande
Profondeur	Niveau superficiel (CVEs)	Profond (Chaînes complexes)	Élevée (Chaînes automatisées)
Coût	Faible / Abonnement	Élevé / Par projet	Modéré / Évolutif
Fréquence	Continue	Annuelle / Trimestrielle	Continue / À la demande
Contexte	Faible (Ne connaît pas la logique K8s)	Élevé (Intuition humaine)	Élevé (Logique K8s-aware)
Correction	Générique "Mettre à jour la version"	Rapport détaillé	Conseils pratiques

Erreurs courantes lors de la sécurisation de Kubernetes

Même les équipes expérimentées commettent ces erreurs. Si vous les voyez dans votre environnement, vous devez donner la priorité à leur correction immédiate.

Erreur 1 : Faire confiance au réseau interne

Beaucoup de gens pensent : "Une fois que le trafic est à l'intérieur du cluster, il est sûr." C'est la plus grande erreur que vous puissiez faire. Une fois qu'un attaquant pénètre dans un pod, il se trouve dans une position "de confiance". Si vous n'avez pas de NetworkPolicies en place, vous avez essentiellement donné à l'attaquant une clé pour chaque pièce de la maison.

Erreur 2 : Dépendance excessive aux Namespaces pour la sécurité

Les Namespaces sont parfaits pour l'organisation, mais ils ne constituent pas une limite de sécurité. Par défaut, les pods dans namespace-a peuvent communiquer avec les pods dans namespace-b. Si vous utilisez des namespaces pour isoler "Prod" de "Dev" sur le même cluster, vous jouez un jeu dangereux. Utilisez des clusters séparés ou des NetworkPolicies très strictes.

Erreur 3 : Ignorer Kubelet et Etcd

Tout le monde se concentre sur le serveur API, mais le Kubelet (sur le nœud) et Etcd (la base de données) sont souvent laissés complètement ouverts. Si un attaquant accède à un nœud, il peut communiquer avec le Kubelet localement et contourner souvent complètement les restrictions du serveur API.

Erreur 4 : Exécution en tant que Root

Il est étonnamment courant de voir des conteneurs s'exécuter en tant qu'utilisateur root. S'il existe une vulnérabilité dans l'application, l'attaquant dispose immédiatement des privilèges root à l'intérieur du conteneur, ce qui facilite considérablement une évasion d'hôte. Spécifiez toujours un runAsUser dans votre SecurityContext.

Liste de contrôle de correction : Renforcement de votre cluster

Vous avez trouvé un tas de trous lors de votre dernier test ? Voici une liste de contrôle pratique pour remettre votre cluster dans un état sécurisé.

Gains immédiats (Faible effort, fort impact)

Désactiver Root : Définissez runAsNonRoot: true dans vos contextes de sécurité de pod.
Restreindre l'accès à l'API : Placez le serveur API derrière un VPN ou utilisez une liste blanche d'adresses IP.
Activer les Network Policies : Mettez en place une politique de "tout refuser" et autorisez explicitement uniquement le trafic qui est réellement nécessaire.
Nettoyer RBAC : Supprimez tous les rôles cluster-admin des comptes de service qui n'en ont pas réellement besoin.

Renforcement à moyen terme

Implémenter un moteur de politiques : Installez Kyverno ou OPA pour appliquer automatiquement les règles de sécurité.
Rotation des secrets : Mettez en place un système de rotation régulière des secrets K8s et des API tokens.
Vérification des images : Implémentez un processus de signature afin que seules les images vérifiées puissent s'exécuter.
Renforcement des nœuds : Utilisez un système d'exploitation optimisé pour les conteneurs (comme Talos ou Bottlerocket) afin de réduire la surface d'attaque du nœud.

Stratégie à long terme

Architecture Zero Trust : Évoluez vers un service mesh (comme Istio ou Linkerd) pour le TLS mutuel (mTLS) entre tous les pods.
Évaluation continue : Intégrez une plateforme comme Penetrify dans votre cycle de sécurité mensuel ou trimestriel.
Chaos Security Engineering : Commencez à briser intentionnellement les contrôles de sécurité dans un environnement de staging pour voir si vos alertes se déclenchent réellement.

Scénario réel : La brèche "Hop-by-Hop"

Pour illustrer pourquoi le cloud Penetration Testing est si important, examinons un scénario de brèche hypothétique (mais très courant).

La configuration : Une entreprise exécute une application de vente au détail sur un cluster EKS. Elle dispose d'un frontend (React), d'une API backend (Node.js) et d'une base de données (MongoDB). Elle utilise un LoadBalancer standard pour le frontend.

Le chemin de la brèche :

L'entrée : L'attaquant trouve un package NPM obsolète dans le backend Node.js qui permet une attaque Server-Side Request Forgery (SSRF).
Le premier saut : En utilisant SSRF, l'attaquant interroge le service de métadonnées K8s interne et trouve le service account token pour le pod backend.
L'escalade : L'attaquant découvre que le service account du pod backend a les permissions get secrets pour l'ensemble du namespace. Il récupère le mot de passe MongoDB.
Le pivot : L'attaquant utilise le mot de passe pour se connecter à la base de données. Une fois à l'intérieur, il trouve un exploit dans la version de la base de données qui lui permet d'exécuter du code sur le nœud sous-jacent.
La prise de contrôle : À partir du nœud, l'attaquant accède à l'API Kubelet et commence à déployer des pods malveillants à travers le cluster pour miner de la cryptomonnaie et voler les données des clients.

Comment un Penetration Test aurait pu arrêter cela : Un cloud Penetration Test aurait signalé la vulnérabilité SSRF dans le backend. Même si le SSRF avait été manqué, le test aurait identifié que le service account avait des permissions get secrets excessives. De plus, l'absence de NetworkPolicy a permis au pod backend de communiquer avec la base de données sans restriction. En trouvant ces "maillons de la chaîne", Penetrify vous aide à briser la chaîne avant que l'attaquant ne puisse terminer le voyage.

FAQ : Cloud Penetration Testing pour Kubernetes

Q : Le Penetration Testing ralentit-il les performances de mon cluster ? Généralement, non. Le cloud Penetration Testing professionnel est conçu pour ne pas être perturbateur. Bien que certains scans lourds puissent provoquer des pics mineurs, la plupart des tests se concentrent sur les défauts de configuration et de logique plutôt que sur le "stress testing" du matériel. Cependant, nous recommandons toujours de tester dans un environnement de staging qui reflète la production.

Q : À quelle fréquence dois-je effectuer une évaluation de sécurité Kubernetes ? Si vous déployez quotidiennement, vous devriez avoir un scanning automatisé quotidiennement. Mais un Penetration Test complet devrait avoir lieu au moins trimestriellement, ou chaque fois que vous apportez une modification importante à votre architecture (comme le passage à un nouveau CNI ou la modification de votre structure RBAC).

Q : Ne puis-je pas simplement utiliser un "Security Group" dans AWS/Azure/GCP pour sécuriser mon cluster ? Les Security Groups ne gèrent que le "périmètre" - le trafic Nord-Sud. Ils ne peuvent pas voir ce qui se passe à l'intérieur de votre cluster. Si un pod est compromis, un Security Group n'empêchera pas ce pod d'attaquer d'autres pods dans le même cluster. Vous avez besoin de contrôles internes comme les NetworkPolicies et RBAC.

Q : Quelle est la différence entre un vulnerability scan et un Penetration Test ? Un scan, c'est comme vérifier si la porte d'entrée est verrouillée. Un Penetration Test, c'est comme essayer de crocheter la serrure, de grimper par la fenêtre et de voir si vous pouvez trouver la boîte à bijoux dans la chambre. L'un trouve les défauts ; l'autre prouve comment ces défauts peuvent être utilisés pour causer des dommages réels.

Q : Ai-je besoin d'une équipe de sécurité dédiée pour utiliser une plateforme comme Penetrify ? Pas nécessairement. Bien qu'il soit utile d'avoir de l'expertise, Penetrify est conçu pour combler le fossé. Il offre la profondeur d'un pentester professionnel, mais fournit les résultats d'une manière que les ingénieurs DevOps et les responsables informatiques peuvent comprendre et sur laquelle ils peuvent agir sans avoir besoin d'un doctorat en cybersécurité.

Tout mettre en œuvre

Sécuriser Kubernetes n'est pas une tâche "ponctuelle". C'est un processus continu de serrage des boulons et de vérification des fissures. La complexité du cloud signifie que les erreurs sont inévitables. L'objectif n'est pas d'avoir un cluster "parfait" - car cela n'existe pas - mais d'en avoir un résilient.

Un cluster résilient est un cluster où l'API est verrouillée, où les pods ont le minimum de permissions dont ils ont besoin pour fonctionner, et où le réseau est segmenté de sorte qu'une seule brèche n'entraîne pas un effondrement total.

La chose la plus dangereuse que vous puissiez faire est de supposer que vous êtes en sécurité parce que vous avez suivi un guide de configuration. La seule façon d'en être sûr est d'essayer de vous introduire vous-même - ou mieux encore, d'utiliser un outil conçu pour le faire à votre place.

Si vous en avez assez de deviner si votre cluster est réellement sécurisé, il est temps de dépasser le scanning de base. Que vous ayez une petite équipe ou une infrastructure d'entreprise massive, vous avez besoin d'un moyen de simuler de véritables attaques sans les frais généraux d'un projet de consulting massif.

Prêt à trouver les failles de votre sécurité Kubernetes avant que les méchants ne le fassent ?

Découvrez Penetrify. Nous fournissons les capacités de Penetration Testing cloud-native dont vous avez besoin pour identifier, évaluer et corriger les vulnérabilités en temps réel. Arrêtez d'espérer que vos configurations soient correctes et commencez à savoir qu'elles le sont. Sécurisez votre infrastructure, protégez vos données et dormez mieux en sachant que votre cluster est réellement résilient.

Retour au blog