Änderungen an kostenlosen Azure-Pipelines-Zuschüssen

Wir ändern den Prozess vorübergehend, um kostenlose Azure Pipelines-Zuschüsse zu erwerben, um den zunehmenden Missbrauch gehosteter Agents zu beheben. Standardmäßig erhalten neue Organisationen, die in Azure DevOps erstellt wurden, möglicherweise keine kostenlose Gewährung gleichzeitiger Pipelines mehr. Neue Benutzer müssen eine E-Mail senden und zusätzliche Informationen bereitstellen, um kostenlose CI/CD zu erhalten.

Ausführliche Informationen finden Sie in der Liste "Features" weiter unten.

Azure Pipelines

• Änderungen an kostenlosen Azure-Pipelines-Zuschüssen
• Entfernen von Aufbewahrungsrichtlinien pro Pipeline in klassischen Builds
• Neue Steuerelemente für Umgebungsvariablen in Pipelines
• Generieren eines uneingeschränkten Tokens für Freihandbuilds
• Ändern von vorinstallierten Modulen in Az, Azure und Azure RM

Azure Repos

• Deaktivieren eines Repositorys

Azure Pipelines

Änderungen an kostenlosen Azure-Pipelines-Zuschüssen

Azure Pipelines bietet seit mehreren Jahren kostenlose CI/CD für öffentliche und private Projekte an. Da sich dies auf freie Berechnung beläuft, war es immer ein Ziel für Missbrauch – vor allem Krypto-Mining. Die Minimierung dieses Missbrauchs hat immer Energie aus dem Team genommen. In den letzten Monaten hat sich die Situation erheblich verschlechtert, wobei ein hoher Prozentsatz neuer Projekte in Azure DevOps für Krypto-Mining und andere Aktivitäten verwendet wird, die wir als missbräuchlich klassifizieren. Mehrere Dienstvorfälle im vergangenen Monat wurden durch diesen Missbrauch verursacht, was zu langen Wartezeiten für bestehende Kunden führt.

Um diese Situation zu beheben, haben wir einen zusätzlichen Schritt für neue Organisationen in Azure DevOps hinzugefügt, um ihre kostenlose Gewährung zu erhalten. Die folgenden Änderungen werden sofort wirksam:

• Standardmäßig erhalten neue Organisationen, die in Azure DevOps erstellt wurden, keine kostenlose Gewährung gleichzeitiger Pipelines mehr. Dies gilt sowohl für öffentliche als auch für private Projekte in neuen Organisationen.
• Um Ihre kostenlose Erteilung anzufordern, übermitteln Sie eine Anfrage und geben Sie die folgenden Details klar an:
  • Ihr Name
  • Azure DevOps-Organisation, für die Sie die kostenlose Gewährung anfordern
  • Ganz gleich, ob Sie die kostenlose Genehmigung für öffentliche Projekte oder private Projekte benötigen.
  • Links zu den Repositorys, die Sie erstellen möchten (nur öffentliche Projekte)
  • Kurze Beschreibung Ihres Projekts (nur öffentliche Projekte)

Wir werden Ihre Anfrage überprüfen und innerhalb weniger Tage antworten.

Wir entschuldigen uns für alle Unannehmlichkeiten, die dazu führen können, dass neue Kunden Azure Pipelines für CI/CD verwenden möchten. Wir sind der Meinung, dass dies notwendig ist, um allen unseren Kunden weiterhin ein hohes Serviceniveau zu bieten. Wir werden weiterhin automatisierte Methoden zur Verhinderung von Missbrauch untersuchen und das vorherige Modell wiederherstellen, sobald wir einen zuverlässigen Mechanismus zur Verhinderung von Missbrauch haben.

Entfernen von Aufbewahrungsrichtlinien pro Pipeline in klassischen Builds

Sie können jetzt Aufbewahrungsrichtlinien für klassische Builds und YAML-Pipelines in den Azure DevOps-Projekteinstellungen konfigurieren. Obwohl dies die einzige Möglichkeit ist, die Aufbewahrung für YAML-Pipelines zu konfigurieren, können Sie die Aufbewahrung auch für klassische Buildpipelines pro Pipeline konfigurieren. Wir entfernen alle Aufbewahrungsregeln pro Pipeline für klassische Buildpipelines in einer bevorstehenden Version.

Was dies für Sie bedeutet: Jede klassische Buildpipeline, die noch über Aufbewahrungsregeln pro Pipeline verfügt, wird bald von den Aufbewahrungsregeln auf Projektebene geregelt.

Um Ihnen bei der Identifizierung dieser Pipelines zu helfen, führen wir eine Änderung in dieser Version aus, um oben auf der Listenseite der Ausführungsliste ein Banner anzuzeigen.

Es wird empfohlen, Ihre Pipelines zu aktualisieren, indem Sie die Aufbewahrungsregeln pro Pipeline entfernen. Wenn Ihre Pipeline speziell benutzerdefinierte Regeln erfordert, können Sie einen benutzerdefinierten Vorgang in Ihrer Pipeline verwenden. Informationen zum Hinzufügen von Aufbewahrungsleases über eine Aufgabe finden Sie in den festgelegten Aufbewahrungsrichtlinien für Builds, Versionen und Tests.

Neue Steuerelemente für Umgebungsvariablen in Pipelines

Der Azure Pipelines-Agent überprüft die Standardausgabe auf spezielle Protokollierungsbefehle und führt sie aus. Der setVariable Befehl kann verwendet werden, um eine Variable festzulegen oder eine zuvor definierte Variable zu ändern. Dies kann potenziell von einem Akteur außerhalb des Systems ausgenutzt werden. Wenn Ihre Pipeline beispielsweise über einen Schritt verfügt, der die Liste der Dateien auf einem FTP-Server druckt, kann eine Person mit Zugriff auf den FTP-Server eine neue Datei hinzufügen, deren Name den setVariable Befehl enthält und dazu führt, dass die Pipeline ihr Verhalten ändert.

Wir haben viele Benutzer, die darauf angewiesen sind, Variablen mithilfe des Protokollierungsbefehls in ihrer Pipeline festzulegen. Mit dieser Version nehmen wir die folgenden Änderungen vor, um das Risiko unerwünschter Verwendungen des setVariable Befehls zu verringern.

• Wir haben ein neues Konstrukt für Aufgabenautoren hinzugefügt. Durch Einschließen eines Codeausschnitts wie der folgenden in task.jsonkann ein Aufgabenautor steuern, ob variablen von ihrer Aufgabe festgelegt werden.

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 

• Darüber hinaus aktualisieren wir eine Reihe integrierter Aufgaben wie ssh, sodass sie nicht ausgenutzt werden können.

• Schließlich können Sie jetzt YAML-Konstrukte verwenden, um zu steuern, ob ein Schritt Variablen festlegen kann.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Generieren eines uneingeschränkten Tokens für Freihandbuilds

GitHub-Benutzer verwenden häufig Forks, um zu einem Upstream-Repository beizutragen. Wenn Azure Pipelines Beiträge aus einer Verzweigung eines GitHub-Repositorys erstellt, schränkt es die Berechtigungen ein, die dem Auftragszugriffstoken erteilt wurden, und lässt keinen Zugriff auf Pipelineschlüssel durch solche Aufträge zu. Weitere Informationen zur Sicherheit von Baufarben finden Sie in unserer Dokumentation.

Die gleichen Einschränkungen gelten standardmäßig beim Erstellen von Forks eines GitHub Enterprise Server-Repositorys. Dies kann restriktiver als gewünscht in solchen geschlossenen Umgebungen sein, in denen Benutzer weiterhin von einem Modell für die zusammenarbeitende Interne Quelle profitieren können. Sie können eine Einstellung in einer Pipeline zwar so konfigurieren, dass geheime Schlüssel für Freihandvorgänge verfügbar gemacht werden, aber es gibt keine Einstellung zum Steuern des Auftragszugriffstokenbereichs. Mit dieser Version geben wir Ihnen die Kontrolle, ein reguläres Auftragszugriffstoken auch für Builds von Forks zu generieren.

Sie können diese Einstellung über Trigger im Pipeline-Editor ändern. Bevor Sie diese Einstellung ändern, stellen Sie sicher, dass Sie die Sicherheitsauswirkungen der Aktivierung dieser Konfiguration vollständig verstehen.

Ändern von vorinstallierten Modulen in Az, Azure und Azure RM

Wir aktualisieren den Prozess der Vorabinstallation von Az-, Azure- und AzureRM-Modulen auf Ubuntu- und Windows-gehostete Images für eine effizientere Unterstützung und Bildraumnutzung.

Während der Woche vom 29. März werden alle Versionen, mit Ausnahme der neuesten und der am häufigsten verwendeten, als Archive gespeichert und von der Azure PowerShell-Aufgabe bei Bedarf extrahiert. Die detaillierte Liste der Änderungen finden Sie unten:

1. Windows-Images

   • Alle Az-Modulversionen mit Ausnahme der neuesten Versionen (derzeit 5.5.0) werden archiviert.

   • Alle Azure-Module mit Ausnahme der neuesten Module (derzeit 5.3.0) und 2.1.0 werden archiviert.

   • Alle AzureRM-Module mit Ausnahme der neuesten Module (derzeit 6.13.1) und 2.1.0 werden archiviert.

2. Ubuntu-Bilder

   • Alle Az-Module mit Ausnahme der neuesten (derzeit 5.5.0) werden archiviert oder vollständig aus dem Image entfernt und werden von der Aufgabe bei Bedarf installiert.

Alle Pipelines, die sofort einsatzbereite Azure-Aufgaben auf gehosteten Agents verwenden, funktionieren wie vorgesehen und erfordern keine Updates. Wenn Sie diese Aufgaben nicht verwenden, setzen Sie Ihre Pipelines auf die Verwendung von Azure PowerShell-Aufgaben, um Änderungen an vorinstallierten Modulen zu vermeiden.

Azure Repos

Deaktivieren eines Repositorys

Kunden haben häufig eine Möglichkeit zum Deaktivieren eines Repositorys angefordert und benutzer am Zugriff auf ihre Inhalte gehindert. Sie können dies beispielsweise in folgenden Fällen tun:

• Sie haben einen geheimen Schlüssel im Repository gefunden.
• Ein Drittanbieter-Scantool hat ein Repository gefunden, das nicht konform ist.

In solchen Fällen können Sie das Repository vorübergehend deaktivieren, während Sie an der Lösung des Problems arbeiten. Mit diesem Update können Sie ein Repository deaktivieren, wenn Sie über Lösch-Repositoryberechtigungen verfügen. Durch Deaktivieren eines Repositorys:

• Kann das Repository in der Liste der Repositorys auflisten
• Der Inhalt des Repositorys kann nicht gelesen werden.
• Der Inhalt des Repositorys kann nicht aktualisiert werden.
• Anzeigen einer Meldung, dass das Repository deaktiviert wurde, wenn er versucht, auf das Repository in der Azure Repos-Benutzeroberfläche zuzugreifen

Nachdem die erforderlichen Entschärfungsschritte ausgeführt wurden, können Benutzer mit der Berechtigung "Repository löschen" das Repository erneut aktivieren. Um ein Repository zu deaktivieren oder zu aktivieren, wechseln Sie zu "Projekteinstellungen", wählen Sie "Repositorys" und dann das spezifische Repository aus.

Nächste Schritte

Wechseln Sie zu Azure DevOps, und sehen Sie sich an.

Senden von Feedback

Wir würden uns freuen zu hören, was Sie zu diesen Features halten. Verwenden Sie das Hilfemenü, um ein Problem zu melden oder einen Vorschlag bereitzustellen.

Sie können auch Ratschläge und Ihre Fragen von der Community in Stack Overflow beantworten lassen.

Vielen Dank,

Vijay Machiraju