Znane problemy z Apigee

Gdy zmienna przepływu cachehit jest używana po polityce LookupCache, ze względu na sposób wysyłania punktów debugowania w przypadku zachowania asynchronicznego, polityka LookupPolicy wypełnia obiekt DebugInfo przed wykonaniem wywołania zwrotnego, co powoduje błąd.

Obejście: powtórz proces (nawiązywanie drugiego połączenia) bezpośrednio po pierwszym połączeniu.

Ustawienie wartości PurgeChildEntries w zasadzie InvalidateCache powinno spowodować usunięcie tylko wartości elementu KeyFragment, ale powoduje wyczyszczenie całej pamięci podręcznej.

Rozwiązanie: użyj polityki KeyValueMapOperations, aby iterować wersjonowanie pamięci podręcznej i ominąć konieczność unieważniania pamięci podręcznej.

Może się tak zdarzyć, gdy równolegle działają różne wersje potoku wdrożeniowego CI/CD. Aby uniknąć tego problemu, nie wdrażaj zasobów proxy API ani SharedFlow przed zakończeniem bieżącego wdrożenia.

Rozwiązanie: unikaj jednoczesnego wdrażania proxy interfejsu API i SharedFlow.

Interfejs Edge API Analytics może czasami zawierać zduplikowane dane wywołań interfejsu API. W takim przypadku liczby wywołań interfejsu API wyświetlane w Edge API Analytics są wyższe niż porównywalne wartości wyświetlane w zewnętrznych narzędziach analitycznych.

Rozwiązanie: wyeksportuj dane analityczne i użyj pola gateway_flow_id, aby usunąć duplikaty.

Opcje TLS_DISABLED_ALGO i TLS_ENABLED_CIPHERS nie działają prawidłowo. Aby włączyć określone szyfry w interfejsie Edge, wykonaj te czynności:

1. Otwórz plik konfiguracji /opt/apigee/etc/edge-ui.d/SSL.sh.
2. Dodaj właściwość -Djdk.tls.server.cipherSuites z listą rozdzielonych przecinkami zestawów szyfrów w notacji IANA w tagu UI_OPTIONS. Na przykład:

   UI_OPTIONS=" -Dhttp.port=disabled -Dhttps.port=9433 -Dhttps.keyStoreType=JKS -Dhttps.keyStore=/opt/apigee/customer/conf/keystore.jks -Dplay.http.sslengineprovider=services.CustomSSLEngineProvider -Dhttps.keyStorePasswordEncrypted=mypass -Djdk.tls.server.cipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384"

3. Zapisz zmiany w pliku konfiguracji.
4. Uruchom ponownie interfejs Edge:

   /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

• Apigee Edge obsługuje specyfikację OpenAPI 3.0, gdy tworzysz specyfikacje za pomocą edytora specyfikacji i publikujesz interfejsy API za pomocą SmartDocs w portalu, choć część funkcji nie jest jeszcze obsługiwana.

  Na przykład te funkcje specyfikacji OpenAPI 3.0 nie są jeszcze obsługiwane:

  • allOfwłaściwości do łączenia i rozszerzania schematów
  • odwołania zdalne.

  Jeśli w specyfikacji OpenAPI jest nawiązanie do funkcji, której nie obsługujemy, narzędzia mogą ją zignorować, ale nadal renderować dokumentację referencyjną interfejsu API. W innych przypadkach nieobsługiwana funkcja spowoduje błędy, które uniemożliwią renderowanie dokumentacji referencyjnej interfejsu API. W obu przypadkach musisz zmodyfikować specyfikację OpenAPI, aby uniknąć używania funkcji, która nie jest obsługiwana, dopóki nie zostanie obsługiwana w przyszłej wersji.

  Uwaga: podczas renderowania dokumentacji referencyjnej interfejsu API edytor specyfikacji jest mniej restrykcyjny niż SmartDocs, więc wyniki uzyskane za pomocą tych narzędzi mogą się różnić.

• Gdy używasz opcji Wypróbuj ten interfejs API na portalu, nagłówek Accept jest ustawiony na application/json niezależnie od wartości consumes w specyfikacji OpenAPI.
• 138438484: Wiele serwerów nie jest obsługiwanych.

• Jednoczesne aktualizowanie portalu (np. strony, motywu, szablonu CSS lub skryptu) przez wielu użytkowników nie jest obecnie obsługiwane.
• Jeśli usuniesz stronę dokumentacji referencyjnej API z portalu, nie będzie można jej ponownie utworzyć. Musisz usunąć i ponownie dodać produkt API, a następnie wygenerować dokumentację referencyjną API.
• Podczas konfigurowania zasad bezpieczeństwa treści pełne zastosowanie zmian może potrwać do 15 minut.
• Gdy dostosujesz motyw portalu, wprowadzenie zmian może potrwać do 5 minut.

• Wyszukiwarka zostanie zintegrowana z integrowanym portalem w jednej z kolejnych wersji.

Ujawniono lukę w zabezpieczeniach (CVE-2026-42945) dotyczącą ngx_http_rewrite_module w NGINX. Narzędzia do skanowania zabezpieczeń mogą oznaczyć pliki binarne NGINX dołączone do Apigee Edge for Private Cloud, ponieważ ten moduł jest statycznie kompilowany w NGINX.

Wpływ na Apigee Edge for Private Cloud:

Apigee Edge for Private Cloud nie jest narażony na tę podatność na zagrożenia w domyślnej, dostarczonej konfiguracji. Wykorzystanie podatności na zagrożenia CVE-2026-42945 zależy od konkretnych wzorców konfiguracji NGINX, w szczególności od użycia dyrektywy rewrite w określonej sekwencji. Te wzorce nie występują w żadnych standardowych konfiguracjach NGINX w Apigee Edge for Private Cloud.

Wymagane działanie:

• W przypadku domyślnych konfiguracji Apigee Edge for Private Cloud: nie są wymagane żadne poprawki, uaktualnienia ani zmiany operacyjne. Wyniki skanowania dotyczące CVE-2026-42945 można traktować jako fałszywe alarmy w przypadku instalacji domyślnych. Aby udokumentować ten wyjątek w systemie zarządzania lukami w zabezpieczeniach, możesz użyć tego tekstu:

  CVE-2026-42945 — Accepted exception (false positive for Apigee Edge for Private Cloud). Apigee Edge for Private Cloud does not use the rewrite directive in any shipped NGINX configuration. The vulnerable code path in ngx_http_rewrite_module is configuration-gated and is not reachable in the default Apigee Edge for Private Cloud deployment.

• W przypadku dostosowanych konfiguracji NGINX: jeśli ręcznie zmodyfikowano pliki konfiguracyjne NGINX w instalacji Apigee Edge for Private Cloud (np. w katalogu /opt/nginx), wykonaj te czynności, aby sprawdzić, czy dostosowania nie wprowadziły przypadkowo podatnego na zagrożenia wzorca:
  1. Sprawdź, czy jest używana dyrektywa rewrite: na każdym węźle NGINX uruchom to polecenie:

     sudo grep -rnI '^\s*rewrite\b' /opt/nginx

  2. Analizuj wyniki:
     • Jeśli polecenie nie zwróci żadnych danych wyjściowych, Twój system nie jest narażony.
     • Jeśli zostaną znalezione dopasowania, sprawdź każdą instancję. Luka w zabezpieczeniach występuje tylko wtedy, gdy w danym bloku spełnione są wszystkie te warunki:
       • Używana jest dyrektywa rewrite.
       • Bezpośrednio po niej w tym samym bloku konfiguracji występuje inna dyrektywa rewrite, if lub set.
       • W dyrektywach używana jest nienazwana grupa przechwytywania PCRE (np. $1, $2 itp.).
       • Ciąg zastępujący w dyrektywie zawiera znak zapytania (?).
  3. Ograniczanie ryzyka (jeśli występuje podatność na zagrożenia): jeśli w którejkolwiek części konfiguracji niestandardowej spełnione są wszystkie powyższe warunki, ogranicz ryzyko, wykonując te czynności:
     • Usuń znak zapytania (?) z ciągu zastępującego.
     • Zamiast nienazwanych grup przechwytywania PCRE używaj nazwanych grup przechwytywania PCRE.
     • Ponownie oceń, czy potrzebne są połączone dyrektywy.

W Edge for Private Cloud 4.53.00 i nowszych wersjach w interfejsie wyświetla się "End of Life" (EOL) warning pop-up. To ostrzeżenie pojawia się
wielokrotnie i nie można zapobiec jego wyświetlaniu ani zmniejszyć jego częstotliwości.

Obecnie nie ma metody, która pozwoliłaby użytkownikom wyłączyć to ostrzeżenie lub zmniejszyć jego częstotliwość.

Wywołania Java klienta, które próbują załadować dostawcę kryptografii Bouncy Castle za pomocą nazwy „BC”, mogą się nie powieść, ponieważ domyślny dostawca został zmieniony na Bouncy Castle FIPS, aby obsługiwać FIPS. Nowa nazwa dostawcy to "BCFIPS".

Wywołania Java klienta, które próbują załadować dostawcę kryptografii Bouncy Castle za pomocą nazwy „BC”, mogą się nie powieść, ponieważ domyślny dostawca został zmieniony na Bouncy Castle FIPS, aby obsługiwać FIPS. Nowa nazwa dostawcy to "BCFIPS".

Ten problem dotyczy tylko osób, które używają MINT lub mają włączoną usługę MINT w instalacjach Edge for Private Cloud.

Komponent, którego dotyczy problem: edge-message-processor

Problem: jeśli masz włączoną monetyzację i instalujesz wersję 4.52.01 jako nową instalację lub uaktualniasz ją z poprzednich wersji Private Cloud, wystąpi problem z procesorami wiadomości. Będzie stopniowo wzrastać liczba otwartych wątków, co doprowadzi do wyczerpania zasobów. W system.log procesora wiadomości Edge widać ten wyjątek:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

Niedawno wykryto lukę w zabezpieczeniach typu „odmowa usługi” (DoS) w wielu implementacjach protokołu HTTP/2 (CVE-2023-44487), w tym w Apigee Edge for Private Cloud. Ta luka w zabezpieczeniach może prowadzić do DoS w przypadku funkcji zarządzania interfejsami API Apigee. Więcej informacji znajdziesz w biuletynie bezpieczeństwa Apigee GCP-2023-032.

Komponenty router i serwer zarządzania w Edge for Private Cloud są dostępne w internecie i mogą być podatne na zagrożenia. Chociaż protokół HTTP/2 jest włączony na porcie zarządzania innych komponentów Edge w Edge for Private Cloud, żaden z tych komponentów nie jest dostępny w internecie. W komponentach innych niż Edge, takich jak Cassandra, Zookeeper i inne, protokół HTTP/2 nie jest włączony. Aby rozwiązać problem z luką w zabezpieczeniach w Edge for Private Cloud, zalecamy wykonanie tych czynności:

• Czynności w przypadku Edge for Private Cloud w wersji 4.51.00.11 lub nowszej
• Czynności w przypadku Edge for Private Cloud w wersji starszej niż 4.51.00.11

Jeśli używasz Edge Private Cloud w wersji 4.51.00.11 lub nowszej, wykonaj te czynności:

1. Zaktualizuj serwer zarządzania:

   1. Na każdym węźle serwera zarządzania otwórz plik /opt/apigee/customer/application/management-server.properties.
   2. Dodaj do pliku właściwości ten wiersz:

      conf_webserver_http2.enabled=false

   3. Uruchom ponownie komponent serwera zarządzania:

      apigee-service edge-management-server restart

2. Zaktualizuj procesor wiadomości:

   1. Na każdym węźle procesora wiadomości otwórz plik /opt/apigee/customer/application/message-processor.properties.
   2. Dodaj do pliku właściwości ten wiersz:

      conf_webserver_http2.enabled=false

   3. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-message-processor restart

3. Zaktualizuj router:

   1. Na każdym węźle routera otwórz plik /opt/apigee/customer/application/router.properties.
   2. Dodaj do pliku właściwości ten wiersz:

      conf_webserver_http2.enabled=false

   3. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-router restart

4. Zaktualizuj QPID:

   1. Na każdym węźle QPID otwórz plik /opt/apigee/customer/application/qpid-server.properties.
   2. Dodaj do pliku właściwości ten wiersz:

      conf_webserver_http2.enabled=false

   3. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-qpid-server restart

5. Zaktualizuj Postgres:

   1. Na każdym węźle Postgres otwórz plik /opt/apigee/customer/application/postgres-server.properties.
   2. Dodaj do pliku właściwości ten wiersz:

      conf_webserver_http2.enabled=false

   3. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-postgres-server restart

Jeśli używasz Edge for Private Cloud w wersji starszej niż 4.51.00.11, wykonaj te czynności:

1. Zaktualizuj serwer zarządzania:

   1. Na każdym węźle serwera zarządzania otwórz plik /opt/apigee/customer/application/management-server.properties.
   2. Dodaj do pliku właściwości te 2 wiersze:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Uruchom ponownie komponent serwera zarządzania:

      apigee-service edge-management-server restart

2. Zaktualizuj procesor wiadomości:

   1. Na każdym węźle procesora wiadomości otwórz plik /opt/apigee/customer/application/message-processor.properties.
   2. Dodaj do pliku właściwości te 2 wiersze:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-message-processor restart

3. Zaktualizuj router:

   1. Na każdym węźle routera otwórz plik /opt/apigee/customer/application/router.properties.
   2. Dodaj do pliku właściwości te 2 wiersze:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-router restart

4. Zaktualizuj QPID:

   1. Na każdym węźle QPID otwórz plik /opt/apigee/customer/application/qpid-server.properties.
   2. Dodaj do pliku właściwości te 2 wiersze:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-qpid-server restart

5. Zaktualizuj Postgres:

   1. Na każdym węźle Postgres otwórz plik /opt/apigee/customer/application/postgres-server.properties.
   2. Dodaj do pliku właściwości te 2 wiersze:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. Uruchom ponownie komponent procesora wiadomości:

      apigee-service edge-postgres-server restart

Apigee-postgresql ma problemy z uaktualnieniem z Edge for Private Cloud w wersji 4.50 lub 4.51 do wersji 4.52. Problemy występują głównie wtedy, gdy liczba tabel jest większa niż 500.

Łączną liczbę tabel w Postgres możesz sprawdzić, uruchamiając to zapytanie SQL:

select count(*) from information_schema.tables

Obejście: podczas uaktualniania Apigee Edge 4.50.00 lub 4.51.00 do 4.52.00, przed uaktualnieniem Apigee-postgresql wykonaj krok wstępny.

149245401: ustawienia puli połączeń LDAP dla JNDI skonfigurowane za pomocą zasobu LDAP nie są odzwierciedlane, a domyślne ustawienia JNDI powodują, że za każdym razem używane są połączenia jednorazowe. W rezultacie połączenia są otwierane i zamykane za każdym razem do jednorazowego użytku, co powoduje dużą liczbę połączeń na godzinę z serwerem LDAP.

Obejście:

Aby zmienić właściwości puli połączeń LDAP, wykonaj te czynności, aby wprowadzić globalną zmianę we wszystkich zasadach LDAP.

1. Jeśli plik właściwości konfiguracji jeszcze nie istnieje, utwórz go:

   /opt/apigee/customer/application/message-processor.properties

2. Dodaj do pliku te informacje (zastąp wartości właściwości Java Naming and Directory Interface (JNDI) properties na podstawie wymagań konfiguracji zasobu LDAP).

   bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
   -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
   -Dcom.sun.jndi.ldap.connect.pool.initsize=2
   -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
   -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"

3. Upewnij się, że plik /opt/apigee/customer/application/message-processor.properties jest własnością apigee:apigee.
4. Uruchom ponownie każdy procesor wiadomości.

Aby sprawdzić, czy właściwości JNDI puli połączeń działają, możesz wykonać tcpdump, aby obserwować zachowanie puli połączeń LDAP w czasie.

139051927: Wysokie opóźnienia przetwarzania serwera proxy znalezione w procesorze komunikatów wpływają na wszystkie proxy interfejsu API. Objawy to opóźnienia w czasie przetwarzania o 200–300 ms w porównaniu z normalnym czasem odpowiedzi interfejsu API . Mogą one występować losowo nawet przy niskim TPS. Może to się zdarzyć, gdy procesor wiadomości łączy się z ponad 50 serwerami docelowymi.

Przyczyna: procesory wiadomości przechowują pamięć podręczną, która mapuje adres URL serwera docelowego na obiekt HTTPClient w przypadku połączeń wychodzących z serwerami docelowymi. Domyślnie to ustawienie jest ustawione na 50, co może być zbyt niską wartością w przypadku większości wdrożeń. Gdy wdrożenie ma wiele kombinacji org/env w konfiguracji, i dużą liczbę serwerów docelowych, które łącznie przekraczają 50, adresy URL serwerów docelowych są usuwane z pamięci podręcznej, co powoduje opóźnienia.

Weryfikacja: Aby sprawdzić, czy problem z opóźnieniem jest spowodowany usunięciem adresu URL serwera docelowego, wyszukaj w system.log procesora komunikatów słowo kluczowe „onEvict” lub „Eviction”. Ich obecność w logach wskazuje, że adresy URL serwerów docelowych są usuwane z pamięci podręcznej HTTPClient, ponieważ jej rozmiar jest zbyt mały.

Obejście: w przypadku Edge for Private Cloud w wersji 19.01 i 19.06 możesz edytować i skonfigurować pamięć podręczną HTTPClient /opt/apigee/customer/application/message-processor.properties:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

Następnie uruchom ponownie procesor wiadomości. Wprowadź te same zmiany we wszystkich procesorach wiadomości.

Wartość 500 jest przykładem. Optymalna wartość dla Twojej konfiguracji powinna być większa niż liczba serwerów docelowych, z którymi będzie się łączyć procesor wiadomości. Ustawienie tej właściwości na wyższą wartość nie ma żadnych skutków ubocznych, a jedynym efektem będzie skrócenie czasu przetwarzania żądań serwera proxy procesora wiadomości.

Uwaga: w Edge for Private Cloud w wersji 50.00 domyślne ustawienie to 500.

157933959: jednoczesne wstawianie i aktualizowanie tej samej mapy klucz-wartość (KVM) w zakresie organizacji lub środowiska powoduje niespójne dane i utratę aktualizacji.

Uwaga: to ograniczenie dotyczy tylko Edge for Private Cloud. Edge for Public Cloud i Hybrid nie mają tego ograniczenia.

Aby obejść ten problem w Edge for Private Cloud, utwórz KVM w zakresie apiproxy scope.