Vor einiger Zeit (muss mehrere Jahre her sein) habe ich ein paar Azure Automation PowerShell Runbooks auf GitHub und hier veröffentlich, um VMs Zeit- und Tag- gesteuert starten und stoppen zu können und um heruntergefahren, nicht-deallokierte VMs zu deallokieren. Diese basierten auf AzureRM PowerShell Cmdlets / Modulen und einer etwas komplizierten Herangehensweise. Ich habe die Runbooks nun massiv überarbeitet, so dass diese erstens das neuere Az Modul verwenden und auch vom Aufbau her wesentlich einfacher sind. U.a. verwenden die Runbooks jetzt lokale Deutsche Zeit und sind robuster bei der Schreibweise der Tags (Groß-/Kleinschreibung).
Ihr findet diese Runbooks wie immer in meinem GitHub Repo, konkret genau hier:
Die Azure Firewall hat ein für mich zunächst nicht nachvollziehbares, aber dann verständliches, wenn auch nicht erwartetes Verhalten. Allerdings steht es, wenn man dann genau nachliest, auch genau so, wie es passiert in der Doku. Aber nochmal langsam…
Ich habe auf einer Azure Firewall einige DNAT Rules, um auf Jump-Hosts zu kommen, die in unterschiedlichen Netzwerken stehen:
Hier ist also für zwei VMs aus dem freien Internet über die Public IP der Azure Firewall und zwei höhere Ports der Durchgriff auf RDP TCP/3389 konfiguriert.
Zwischen den beiden Netzwerken, in denen sich die VMs befinden, soll der Traffic aber stark reglementiert sein. Daher sind dort nur einige Ports explizit erlaubt, für den Rest sollte die Azure Firewall „per default“ blockieren:
Jedoch ist es dennoch so, dass zwischen den beiden VMs, die ja in getrennten Netzen stehen, weiterhin Kommunikation möglich ist, auch jenseits von ICMP und HTTP(S). Getestet hatte ich es mit RDP – das geht noch, obwohl das nach meiner Meinung nicht so sein sollte.
Und das hatte mich sehr verwundert. Zunächst hatte ich das als Fehlverhalten interpretiert. Ein kurzer Call mit dem Support hat aber geklärt, dass dieses Verhalten so ganz normal ist. Das wiederum war für mich unerwartet.
Die Lösung hier ist, dass eine DNAT Rule eine implizite Network Rule nach sich zieht. Dabei werden allerdings nicht Port und Destination IP sondern Translated Adress und Translated Port für die Destination verwendet. So steht es auch in der Doku:
Weihnachten 2020 ist nun Geschichte und damit endete auch mein Azure Adventskalender in diesem Jahr. Jeden Tag ein neues Video für euch – das hat mir viel Spaß, aber auch einiges an Arbeit bereitet. Daher möchte ich natürlich, dass die Videos auch nach der Weihnachtszeit weiterhin zu eurem Nutzen sind. Und deswegen fasse ich euch hier nochmal alle Videos kurz zusammen:
01. Dezember 2020
Hinter Tür Nummer eins verbarg sich ein Video zu den Diagnostic Settings in Azure. Ihr findet es hier: https://youtu.be/cAjqU0202X4
02. Dezember 2020
Das zweite Türchen hielt einen Überblick zu den verschiedenen VM-Größen in Azure und eine Erklärung selbiger bereit. Es ist hier zu finden: https://youtu.be/mTZbOxKrlrM
03. Dezember 2020
Hinter diesem Türchen war ein Video zu den Resource Locks zu finden. Hier geht es zum Video: https://youtu.be/X0IHwU6EA_E
04. Dezember 2020
Das vierte Türchen verbarg einen Überblick zum Azure Advisor und Erklärungen zu seinen Empfehlungen. Das Video gibt es hier: https://youtu.be/RmTaXwZfP6o
05. Dezember 2020
Am fünften Tag gab es ein Video zur Datenbank-Migration in Azure. Es ist über diesen Link zu erreichen: https://youtu.be/c1xfZqY-eyM
06. Dezember 2020
Am Nikolaustag ging es im täglichen Video um die Azure Firewall (verbunden mit VNET-Peering). Das Video findet ihr hier: https://youtu.be/EsX2B1DZvzA
07. Dezember 2020
Für das siebte Türchen habe ich ein Video zu einem netten Sicherheitsfeature des Security Center bzw. Defender aufgezeichnet – es geht um Just-in Time (JIT) VM Access. Das Video ist über diesen Link zu sehen: https://youtu.be/k2LUYmMxOx4
08. Dezember 2020
Für diesen Tag gab es ein Video zu den Network Security Groups (NSG) und den Application Secruity Groups (ASG). Ihr findet es hier: https://youtu.be/FBmInxpkSEM
09. Dezember 2020
Das neunte Türchen hat ein Video zu den verschiedenen Disk-Typen für Azure VMs beschert. Schaut es euch hier an: https://youtu.be/oANdFp21W9k
In einer Woche ist es soweit – mit dem 01.12. beginnt die jährliche Saison der Adventskalender. Ich habe mir für dieses Jahr etwas Besonderes überlegt. ich werde jeden Tag ein virtuelles Türchen auf meinem YouTube-Kanal bereithalten, hinter dem sich dann jeweils ein neues Video verbergen wird! Also seid gespannt, abonniert meinen Kanal und schaut euch die täglichen Videos an.
Microsoft hat mich erneut als „Most Valuable Professional“ (MVP) ausgezeichnet – dieses mal aber für den Bereich Azure. Ich bin stolz und glücklich, weit Teil dieser großartigen Gemeinschaft zu sein!
Geht es um den Aufbau automatisierter CI/CD Pipelines für Azure, so denken die meisten wohl eher an Azure DevOps. Aber auch mit GitHub lässt sich so etwas erreichen – und zwar völlig kostenlos. Das Werkzeug dazu heißt GitHub Actions. Zu GitHub Actions selbst will ich hier gar nicht so viel schreiben – es gibt bereits einige Blogartikel und co. dazu. Ich verweise aber gerne auf mein Video, welches ich dazu gemacht habe:
Mein YouTube Video zu GitHub Actions
Nun kam von einem meiner geschätzten Kollegen zu Recht die Frage, wie man denn in dieser (ersten, im Video gezeigten) Variante mehrere ARM Templates bereitstellen kann. Und dazu möchte ich hier die passende Antwort liefern…
Microsoft stellt ein schönes PowerBI Tooling bereit, mit dem man für seine Azure AD location und die verwendeten Services feststellen kann, wo die Daten tatsächlich gespeichert werden:
Es geht hier also vor allem um das Speichern der Telefonnummern und UPNs in Amerika. Diese Tatsache war mir – und ich vermute da geht es einigen von euch ähnlich – so nicht bewusst…
Weil es die Tage bei einem meiner Kunden wieder mal ein Thema war, möchte ich es hier nun mal im Detail beleuchten. Und zwar geht es um die Anforderung, Virtuelle Maschinen in Azure starten und stoppen zu können, ohne beispielsweise die VM löschen zu können oder ihre SKU zu verändern. Natürlich gibt es den „Virtual Machine Contributor“ als built-in Role, aber diese darf eben deutlich zu viel.
Wie geht man nun an das Thema heran? Zunächst muss man zwei Dinge in Erfahrung bringen:
Den Namen des Resource-Providers um den es geht
Die Operationen auf diesem Provider, die man erlauben oder verbieten möchte
Wie Microsoft in seinem Blog-Artikel angekündigt hat, ist das „Account Failover“ Feature für den Storage Account nun in der Public Preview. Aber worum handelt es sich hier überhaupt?
Schon seit Längerem bieten Storage Accounts die Möglichkeit, die Daten georedundant vorzuhalten. Dabei werden in den Optionen ZRS, GRS und RA-GRS (und neuerdings auch GZRS) die Daten (die am primären Speicherort schon 3-fach vorgehalten werden) in ein anderes Azure Rechenzentrum in der selben Region (ZRS) oder in einer anderen Region gespiegelt. Dies geschieht allerdings asynchron, d.h., bei einem Ausfall in der Ursprungsregion kann es sein, dass nicht alle Daten vollständig gespiegelt worden, somit kann es zu Datenverlust kommen.
