Apache APISIX 3.5.0 ist jetzt allgemein verfügbar und bringt einige neue Funktionen und eine verbesserte Benutzererfahrung. Dazu gehören die dynamische Konfiguration von TLS-Versionen auf Hostebene, die Integration mit Chaitin WAF, das erzwungene Löschen von Ressourcen, die Verwendung von Umgebungsvariablen in Konfigurationsdateien bei der Bereitstellung von APISIX im Standalone-Modus und mehr. Darüber hinaus wurden einige wichtige Änderungen vorgenommen.
große Veränderungen
- Die Unterstützung des Snowflake-Algorithmus im Request-ID-Plugin wurde entfernt
Entfernen Sie die Snowflake-Unterstützung im Request-ID-Plugin. Dieser Algorithmus führt zu einer unnötigen Abhängigkeit von etcd, die die Leistung von APISIX erheblich beeinträchtigen kann, wenn etcd nicht verfügbar ist. Bitte erwägen Sie die Verwendung der Option uuid im Algorithmus.
Weitere Hintergrundinformationen finden Sie im Vorschlag auf der Mailingliste .
Siehe #9715 für die entsprechende PR.
- Einstellung der Unterstützung für OpenResty 1.19
Wenn Sie diese Version derzeit verwenden, wird empfohlen, ein Upgrade auf OpenResty Version 1.21 und höher zu planen.
Siehe #9913 für die entsprechende PR.
- Verbessern Sie die Verfügbarkeit von L4- und L7-Proxys und entfernen Sie apisix.stream_proxy.only
Verbessert die Verfügbarkeit von L4- und L7-Proxys. Durch diese Änderung wird die Option apisix.stream_proxy.only entfernt und die Verwendung zum Aktivieren und Deaktivieren von L4- und L7-Proxys vereinfacht.
L4- und L7-Proxys können config.yaml in der Datei wie folgt aktiviert werden:
-
L7-Proxy aktivieren (standardmäßig aktiviert):
apisix.proxy_mode: http -
L4-Proxy aktivieren:
apisix.proxy_mode:stream -
Aktivieren Sie L7- und L4-Proxys:
apisix.proxy_mode: http&stream
Weitere Informationen zur Verwendung von Stream-Proxys nach der Änderung finden Sie unter So aktivieren Sie Stream-Proxys .
Siehe #9607 für die entsprechende PR.
- Sowohl die Zulassungsliste als auch die Sperrliste sind im UA-Restriction-Plugin nicht zulässig
Im UA-Restriction-Plugin ist es nicht mehr erlaubt, sowohl die Zulassungsliste als auch die Sperrliste zusammen zu verwenden. Sie sollten Optionen nur für eine davon konfigurieren.
Siehe #9841 für eine entsprechende PR.
- Überarbeitete und verbesserte Plugin-Schnittstelle in der Admin-API
Die Schnittstelle , über die /apisix/admin/plugins?all=true alle Plugin-Eigenschaften abgerufen werden, wird bald veraltet sein. Zukünftig wird die Admin-API nur das Abrufen der Eigenschaften jeweils eines Plugins unterstützen. Es wird empfohlen, die folgenden Endpunkte und Parameter zu verwenden, um Ihren Anforderungen gerecht zu werden:
/apisix/admin/plugins/{plugin_name}?subsystem={subsystem}Alternativ können Sie /v1/schema verwenden, um die Schemata aller Plugins in der Control API abzurufen und zu analysieren.
Wenn Sie nur eine Liste der Plugin-Namen erhalten möchten, können Sie den folgenden Befehl verwenden:
/apisix/admin/plugins/list?subsystem={subsystem}Weitere Einzelheiten finden Sie unter Plugins in der Management-API .
Siehe #9580 für die entsprechende PR.
neue Funktion
- Unterstützt die dynamische Konfiguration der TLS-Version auf Hostebene
Unterstützt die Laufzeitkonfiguration von TLS-Versionen für einzelne SNIs. Diese Konfiguration hat Vorrang vor der statischen Konfiguration von ssl_protocols in config-default.yaml oder config.yaml und erfordert kein Neuladen von APISIX, wodurch ein detaillierterer Ansatz für die Integration in Ihre Infrastruktur bereitgestellt wird.
Mit dem folgenden Befehl können Sie beispielsweise die Domäne test.com so konfigurieren, dass sie TLS-Verbindungen für die TLS-Versionen 1.2 und 1.3 akzeptiert:
curl http://127.0.0.1:9180/apisix/admin/ssls/1 -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"cert": "$cert",
"key": "$key",
"snis": ["test.com"],
"ssl_protocols": [
"TLSv1.2",
"TLSv1.3"
]
}'Weitere Informationen zu dieser Funktionalität und Beispiele finden Sie unter SSL-Protokoll .
Siehe #9903 für eine entsprechende PR.
- Unterstützung für erzwungenes Löschen von Ressourcen
Unterstützung für das erzwungene Löschen von Ressourcen mithilfe der Admin-API. Standardmäßig prüft die Verwaltungs-API, ob Referenzen zwischen Ressourcen vorhanden sind, und lässt das Löschen von verwendeten Ressourcen nicht zu.
Mit dieser neuen Funktion können Sie einen Löschvorgang erzwingen, indem Sie eine DELETE-Anfrage mit dem URL-Parameter force=true senden, etwa so:
curl "http://127.0.0.1:9180/apisix/admin/upstreams/1?force=true" -X DELETE \
-H "X-API-KEY: ${ADMIN_API_KEY}"Weitere Informationen zu dieser Funktion und ein Beispiel finden Sie unter „Löschen erzwingen“ .
Siehe #9810 für die entsprechende PR.
- Unterstützung für Umgebungsvariablen in apisix.yaml Unterstützung für die Verwendung von Umgebungsvariablen in apisix.yaml.
Sie können beispielsweise die Host-IP und den Port des Upstream-Dienstes als Umgebungsvariablen festlegen und die Variablen in apisix.yaml wie folgt verwenden:
routes:
-
uri: "/test"
upstream:
nodes:
"${{HOST_IP}}:${{PORT}}": 1
type: roundrobin
#ENDWeitere Informationen zu dieser Funktion und Beispiele finden Sie unter Verwenden von Umgebungsvariablen in der Management-API .
Siehe #9855 für die entsprechende PR.
- Fügen Sie einen Schemavalidierungsendpunkt in der Admin-API hinzu
Fügen Sie den Endpunkt /apisix/admin/schema/validate/{resource} zur Admin-API hinzu, um das konfigurierte Schema zu validieren. Sie können jetzt die Richtigkeit der Konfiguration überprüfen, ohne eine Anfrage zur Ressourcenerstellung an den Endpunkt zu senden.
Sie können beispielsweise das Schema einer Route mit dem folgenden Befehl überprüfen:
curl http://127.0.0.1:9180/apisix/admin/schema/validate/routes -i -X POST \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"uri": 1980,
"upstream": {
"scheme": "https",
"type": "roundrobin",
"nodes": {
"nghttp2.org": 1
}
}
}'
Da dieses Schema falsch ist, sollten Sie eine Antwort ähnlich der folgenden sehen:
HTTP/1.1 400 Bad Request
...
{"error_msg":"property \"uri\" validation failed: wrong type: expected string, got number"}
Weitere Informationen zu dieser Funktion und Beispiele finden Sie unter Schemavalidierung in der Admin-API .
Siehe #10065 für die entsprechende PR.
- Integration mit Chaitin WAF über Chaitin-Waf-Plugin-Unterstützung
Durch chaitin-waf Plug-in-Unterstützung und Integration mit Chaitin WAF wird der Gateway-Verkehr zur Prüfung und Erkennung von bösartigem Datenverkehr an Chaitin WAF weitergeleitet.
Sie können beispielsweise die Adresse von Chaitin WAF in den Plug-in-Metadaten konfigurieren und alle chaitin-waf Plug-in-Instanzen verweisen auf diese Adresse. Konfigurieren Sie es host als Chaiting SafeLine WAF-Erkennungsdienst-Host, Unix-Domänen-Socket, IP oder Domäne und gehen Sie portwie folgt vor:
curl http://127.0.0.1:9180/apisix/admin/plugin_metadata/chaitin-waf -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"nodes":[
{
"host": "unix:/path/to/safeline/resources/detector/snserver.sock",
"port": 8000
}
]
}'Anschließend können Sie das Plugin auf einer Route aktivieren und nur Datenverkehr, der den angegebenen Kriterien entspricht, an die WAF weiterleiten:
curl http://127.0.0.1:9180/apisix/admin/routes/1 -X PUT \
-H "X-API-KEY: ${ADMIN_API_KEY}" \
-d '{
"uri": "/*",
"plugins": {
"chaitin-waf": {
"match": [
{
"vars": [
["http_waf","==","true"]
]
}
]
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"httpbun.org:80": 1
}
}
}'Es versucht einen Injektionsangriff, wenn es eine potenziell böswillige Anfrage erkennt, wie zum Beispiel die folgende:
curl -i "http://127.0.0.1:9080/getid=1%20AND%201=1" \
-H "Host: httpbun.org" \
-H "waf: true"Sie sollten eine Antwort ähnlich der folgenden sehen:
HTTP/1.1 403 Forbidden
...
X-APISIX-CHAITIN-WAF: yes
X-APISIX-CHAITIN-WAF-TIME: 2
X-APISIX-CHAITIN-WAF-ACTION: reject
X-APISIX-CHAITIN-WAF-STATUS: 403
...
{"code": 403, "success":false, "message": "blocked by Chaitin SafeLine Web Application Firewall", "event_id": "51a268653f2c4189bfa3ec66afbcb26d"}Weitere Informationen zu dieser Funktion und Beispiele finden Sie in der Dokumentation zum Chaitin-Waf -Plugin.
Siehe #9838 für eine entsprechende PR.
andere Updates
- Unterstützung beim Konfigurieren des Proxyservers im OpenID-Connect-Plugin (PR #9948)
- Unterstützung des Sendens von Antwortheadern vom OPA-Server an den Upstream-Dienst im OPA-Plugin (PR #9710)
- Unterstützen Sie die Verwendung von Variablen im Dateilogger-Plugin, um bedingte Protokollierung zu ermöglichen (PR #9712)
- Unterstützung der Konfiguration von Antwortheadern im Mocking-Plugin (PR #9720)
Weitere Informationen finden Sie im CHANGELOG .