Catégorie : Divers

Microsoft Ignite 2020!

Bonjour,

Ci-dessous les sessions que je vous recommande pour Microsoft Ignite 2020. Cette année en raison de la pandémie la conférence se déroule en ligne et gratuitement vous pouvez assister à l’ensemble des sessions ainsi qu’aux nombreuses annonces! 🙂

Inside Azure Datacenter Architecture with Mark Russinovich
https://myignite.microsoft.com/sessions/40aca11c-8e28-4914-a6d8-b3a7efb4eee1

Mark Russinovich on Azure innovation and more!
https://myignite.microsoft.com/sessions/627f7573-7dd5-407e-8349-0165132aeb64

What’s new in Azure Security Center
https://myignite.microsoft.com/sessions/d40bd0a5-485e-455d-ac28-882b85de8dfb

Achieve resilience with security, compliance, and identity
https://myignite.microsoft.com/sessions/6574bfc6-0954-4ca4-8fef-bfa0c5ba8a9c

Enterprise-grade Kubernetes on Azure
https://myignite.microsoft.com/sessions/01863874-feb0-4d55-aa17-07368cd3c249

Best Practices of Running Cloud Native Applications on Azure
https://myignite.microsoft.com/sessions/6f52708f-35a1-452f-947d-0530b31c8845

Azure Databricks – What’s new!
https://myignite.microsoft.com/sessions/ade75984-adc0-48a7-8761-54f7c33d5441

Detect Unknown Threats with User and Entity Behavioral Analytics in Azure Sentinel
https://myignite.microsoft.com/sessions/af230800-cfdb-4e33-96ac-fc311dda90fc

Bonne conférence!

Maxime.

Azure Storage Blob | Immuable stockage

Bonjour,

Dans cet article je vais vous présenter une nouvelle fonctionnalité d’Azure Storage afin de rendre vos données immuables.

Les cas d’utilisations sont nombreux, on peut par exemple retrouver:

  • Conformité réglementaire : Le stockage immuable pour le Stockage Blob Azure permet aux organisations de respecter entre autres les réglementations SEC 17a-4(f), CFTC 1.31(d) et FINRA
  • Conservation sécurisée des documents : avec le stockage immuable pour le Stockage Blob, les données ne sont ni modifiables ni supprimables par les utilisateurs, même s’ils disposent d’un compte avec privilèges administratifs.
  • Conservation légale : le stockage immuable pour le Stockage Blob Azure permet aux utilisateurs de stocker dans un état de protection inviolable des informations sensibles critiques dans le cadre d’une utilisation professionnelle ou portant sur un litige, pour la durée souhaitée jusqu’à ce que la conservation prenne fin.

Pour réaliser cela, je vous donne rendez-vous dans le portail Azure, plus spécifiquement au sein du service Storage Account, sélectionner votre storage account ainsi qu’un container dans cet exemple demo-maxime.

Dans ce container, nous avons un fichier maxime.txt que nous allons souhaiter rendre immuable.

Puis je vous invite à clique sur « Access Policy » dans la section « Settings ». Enfin dans la section « Immuable blob storage », je vous invite à cliquer sur « Add policy ».

Nous pouvons constater qu’il existe deux types de policy:

Legal hold:

Ainsi que Time-based retention, dans cet exemple nous allons utiliser ce type de policy avec une rétention de 2 jours. C’est à dire nos fichiers (dont le fichier maxime.txt) vont être immuables pendant 2 jours.

Une fois validé, nous pouvons voir que notre policy est présente mais avec un status : Unlocked. Pour valider l’application de cette policy et rendre notre container immuable, nous allons cliquer sur « Lock policy »

Ainsi que confirmer le lock : « yes »

Notre policy est désormais dans un état verrouillée, il n’est plus possible de modifier les fichiers du containers dont le fichier maxime.txt pendant les deux prochains jours.

Si par exemple, j’essayer de supprimer mon fichier « maxime.txt », j’obtiens l’erreur suivante: « Failed to delete 1 out 1 blobs:maxime.txt This operation is not permitted as the blob is immutable due to a policy » »

Maxime.

AKS |Azure Kubernetes Service: Node disk DOS by writing to container /etc/hosts (CVE-2020-8557)

Hi,

In this article I would like share with you a new vulnerability against Azure Kubernetes.

Title: Node disk DOS by writing to container /etc/hosts

CVE: CVE-2020-8557

Description:

The /etc/hosts file mounted in a pod by kubelet is not included by the kubelet eviction manager when calculating ephemeral storage usage by a pod. If a pod writes a large amount of data to the /etc/hosts file, it could fill the storage space of the node and cause the node to fail.

Any clusters allowing pods with sufficient privileges to write to their own /etc/hosts files are affected. This includes containers running with CAP_DAC_OVERRIDE in their capabilities bounding set (true by default) and either UID 0 (root) or a security context with allowPrivilegeEscalation: true (true by default).

Affected versions:

kubelet v1.18.0-1.18.5
kubelet v1.17.0-1.17.8
kubelet < v1.16.13

Fixed versions:

AKS v1.15.11*, v1.15.12* .
AKS v1.16.10* and v1.16.13+
AKS v1.17.7* and v1.17.9+
AKS v1.18.6+

Maxime.