Perubahan di Edge untuk Private Cloud 4.53.01

Ringkasan perubahan

Edge for Private Cloud 4.53.01 memperkenalkan beberapa perubahan yang meningkatkan postur keamanan platform dan menggabungkan versi terbaru software dan library yang diperlukan. Perubahan ini memengaruhi jenis kebijakan berikut:

Anda juga dapat menggunakan alat deteksi perubahan untuk mengidentifikasi perubahan pada proxy, alur bersama, atau artefak lain di cluster yang dapat menyebabkan gangguan akibat upgrade ini.

Deskripsi mendetail tentang perubahan

Bagian ini menjelaskan perubahan yang diperkenalkan di versi 4.53.01 yang dapat mengganggu alur kerja Anda selama atau setelah upgrade. Metode untuk mengidentifikasi potensi area masalah dan metodologi mitigasi atau solusi juga dibahas.

Kebijakan validasi OAS (spesifikasi OpenAPI)

Konteks

Kebijakan validasi OAS memvalidasi permintaan atau respons masuk terhadap aturan yang ditentukan dalam spesifikasi OpenAPI 3.0 (JSON atau YAML). Edge untuk Private Cloud 4.53.01 memberikan peningkatan pada kebijakan OAS (spesifikasi OpenAPI), yang berfokus pada validasi isi respons API yang lebih ketat dan akurat.

Perubahan

Edge untuk Private Cloud 4.53.01 memperkenalkan dua perubahan penting dalam cara kebijakan OAS memvalidasi respons API, sehingga memastikan keselarasan yang lebih erat dengan spesifikasi OpenAPI Anda:

  • Skenario 1:
    • Perilaku sebelumnya: Jika spesifikasi OpenAPI Anda memerlukan isi respons, tetapi respons sebenarnya dari target atau kebijakan upstream tidak menyertakannya, kebijakan tidak akan menandai hal ini sebagai error validasi.
    • Perilaku saat ini: Kebijakan kini akan menampilkan error validasi dengan benar (contoh: defines a response schema but no response body found) dalam skenario ini, yang menunjukkan ketidakcocokan antara respons yang diharapkan dan respons sebenarnya.
  • Skenario 2:
    • Perilaku sebelumnya: Jika spesifikasi OpenAPI Anda secara eksplisit menyatakan bahwa tidak ada isi respons yang diharapkan, tetapi respons sebenarnya dari target atau kebijakan upstream menyertakan isi, kebijakan tidak akan menyebabkan kegagalan.
    • Perilaku saat ini: Kebijakan kini akan menghasilkan kegagalan (contoh: No response body is expected but one was found) dalam skenario ini, sehingga memastikan bahwa respons mematuhi skema yang ditentukan secara ketat.

Mitigasi

Identifikasi proxy atau alur bersama yang mungkin terpengaruh oleh upgrade menggunakan alat deteksi perubahan atau melalui peninjauan manual. Cari proxy yang memenuhi salah satu kondisi berikut:

  • Kebijakan Validasi OAS dikonfigurasi dengan tag Source yang ditetapkan ke response.
  • Kebijakan Validasi OAS memvalidasi respons dari kebijakan lainnya yang menghasilkan respons.

Jika menggunakan alat ini, output akan dihasilkan dalam format di bawah:

Organisasi Lingkungan Nama Artefak Jenis Artefak Revisi Nama Kebijakan Jenis Kebijakan Jenis Dampak Kolom Khusus Dampak Kepastian Dampak Dokumentasi
org2 dev proxy2 proxy 4 oas-validateresponse OASValidation oas_content_type_handling Source=calloutresponse Sedang Kebijakan Validasi OAS
org1 prod proxy3 sharedflow 1 oas-spec-validation OASValidation oas_content_type_handling Source=response Sedang Kebijakan Validasi OAS

Untuk penjelasan mendetail tentang kolom dalam tabel output, lihat bagian Memahami output alat.

Setelah proxy atau alur bersama diidentifikasi, pastikan respons dan spesifikasi OAS Anda selaras terkait ada atau tidaknya isi respons. Anda dapat menggunakan rekaman aktivitas Apigee standar untuk meninjau pola traffic. Jika target menampilkan respons secara terputus-putus, gunakan kebijakan lain untuk memvalidasi respons sebelum respons diteruskan ke kebijakan Validasi OAS.

  • Jika file spesifikasi OAS Anda menentukan isi respons, respons dari target atau kebijakan upstream harus selalu menyediakannya.
  • Jika file spesifikasi OAS Anda tidak menentukan isi respons, kebijakan target atau upstream tidak boleh mengirimkannya.

Perbarui kebijakan validasi OAS atau perilaku target Anda sesuai kebutuhan sebelum Anda mencoba upgrade ke Private Cloud 4.53.01. Anda harus memvalidasi alur kerja yang diidentifikasi tersebut di lingkungan non-produksi terlebih dahulu untuk meminimalkan risiko gangguan selama upgrade cluster produksi.

Jalur JSON

Konteks

Edge untuk Private Cloud 4.53.01 telah memperkenalkan perubahan pada cara penggunaan ekspresi jalur JSON dalam berbagai kebijakan. Ekspresi JSONPath dapat digunakan dalam kebijakan seperti kebijakan ExtractVariable, kebijakan RegularExpressionProtection, Penyamaran data untuk mengurai konten JSON atau menyimpan nilai dalam variabel. Ekspresi JSONPath juga dapat digunakan dalam pembuatan template pesan umum untuk mengganti variabel dengan nilai secara dinamis selama eksekusi proxy. Ekspresi dan format JSONPath baru mengikuti standar ekspresi JSON terbaru.

Perubahan

Penting untuk meninjau proxy API/alur bersama yang ada untuk kebijakan yang menggunakan ekspresi JSONPath. Hal ini mencakup, tetapi tidak terbatas pada, kebijakan Extract Variables, kebijakan Regular Expression Protection, atau kebijakan apa pun dengan Message Template yang menggunakan JSONPath.

Input JSON di bawah digunakan untuk menjelaskan perubahan:

{
  "store": {
    "book": [
      {"category": "reference", "author": "Nigel Rees", "price": 8.95},
      {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
      {"category": "fiction", "author": "Herman Melville", "price": 8.99}
    ],
    "bicycle": {
      "color": "red",
      "book": [
        {"author": "Abc"}
      ]
    }
  }
}
  1. Perubahan perilaku karakter pengganti JSONPath [*] untuk nilai objek

    Perilaku karakter pengganti [*] telah diubah saat digunakan untuk mengakses semua nilai langsung dari objek JSON. Sebelumnya, $.object[*] akan menampilkan nilai langsung yang digabungkan dalam satu objek JSON. Dengan library yang diperbarui, outputnya sekarang berupa array yang berisi nilai-nilai ini.

    Misalnya, $.store[*]:

    Perilaku sebelumnya:
    {
      "bicycle": {
        "color": "red",
        "book": [{"author": "Abc"}]
      },
      "book": [
        {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
        {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
        {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
      ]
    }
    
    Perilaku saat ini:
    [
      [
        {"category": "reference", "author": "Nigel Rees", "price": 8.95},
        {"category": "fiction", "author": "Evelyn Waugh", "price": 12.99},
        {"category": "fiction", "author": "Herman Melville", "price": 8.99}
      ],
      {
        "color": "red",
        "book": [{"author": "Abc"}]
      }
    ]
    
    Tindakan:

    Ubah ekspresi JSONPath untuk menargetkan objek induk (contoh: $.store) guna menargetkan item yang diambil sebelumnya secara langsung.

  2. Titik di akhir JSONPath (.) dalam jalur menyebabkan error

    Ada validasi yang lebih ketat untuk ekspresi JSONPath. Sebelumnya, jalur yang diakhiri dengan titik di belakang yang tidak valid (contoh: $.path.to.element.) akan diabaikan tanpa pemberitahuan, dan kueri tetap menampilkan hasil jika segmen jalur valid sebelumnya cocok. Dengan versi baru, jalur yang salah format tersebut kini diidentifikasi dengan benar sebagai tidak valid dan akan menghasilkan error.

    Contoh, $.store.book.

    Perilaku sebelumnya:
    [
      {"price":8.95,"category":"reference","author":"Nigel Rees"},
      {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
      {"price":8.99,"category":"fiction","author":"Herman Melville"}
    ]
    
    Perilaku saat ini:
    ERROR: com.jayway.jsonpath.InvalidPathException - Path must not end with a '.' or '..'
    

    Semua kebijakan yang ada yang menggunakan ekspresi JSONPath dengan titik di akhir yang tidak disengaja kini akan gagal dengan InvalidPathException.

    Tindakan:

    Hapus titik di bagian akhir dari ekspresi JSONPath yang diakhiri dengan titik. Misalnya, ubah $.store.book. menjadi $.store.book.

  3. Perubahan struktur output (..) penurunan rekursif JSONPath

    Ada perubahan pada cara hasil ditampilkan saat menggunakan operator (..) (penurunan rekursif) untuk menemukan semua kemunculan elemen bernama. Sebelumnya, semua elemen yang ditemukan diratakan ke dalam satu daftar. Library yang diperbarui kini menampilkan daftar daftar, yang mempertahankan struktur pengelompokan asli tempat elemen ditemukan, bukan daftar datar tunggal.

    Contoh, $..book

    Perilaku sebelumnya:
    [
      {"price":8.95,"category":"reference","author":"Nigel Rees"},
      {"price":12.99,"category":"fiction","author":"Evelyn Waugh"},
      {"price":8.99,"category":"fiction","author":"Herman Melville"},
      {"author":"Abc"}
    ]
    
    Perilaku saat ini:
    [
      [
        {"category":"reference","author":"Nigel Rees","price":8.95},
        {"category":"fiction","author":"Evelyn Waugh","price":12.99},
        {"category":"fiction","author":"Herman Melville","price":8.99}
      ],
      [
        {"author":"Abc"}
      ]
    ]
    
    Tindakan:

    Perbarui logika pemrosesan hilir Anda untuk memperhitungkan struktur array bertingkat yang baru. Anda mungkin perlu melakukan iterasi melalui JSONArray luar, lalu melakukan iterasi melalui setiap JSONArray dalam untuk mengakses setiap elemen.

  4. Pengindeksan JSONPath setelah pemilihan atau pemfilteran multi-item menampilkan array kosong

    Ada perubahan perilaku saat indeks (contoh: [0]) diterapkan segera setelah pemilih multi-item (seperti [*]) atau filter ([?(condition)]). Sebelumnya, ekspresi tersebut akan mencoba memilih item pada indeks yang ditentukan dari hasil gabungan. Dengan versi baru, ekspresi ini kini akan menampilkan array kosong ([]).

    Contoh, $.store.book[*][0]

    Perilaku sebelumnya:
    {"category": "reference", "price": 8.95, "author": "Nigel Rees"}
    
    Perilaku saat ini:
    []
    
    Tindakan:

    Jika ada kebutuhan untuk memfilter, lalu mendapatkan item tertentu dari kumpulan yang difilter, proses array yang difilter yang ditampilkan oleh JSONPath, misalnya, $..book[?(@.category == 'fiction')], lalu ambil [0] dari hasil sebelumnya.

  5. Perubahan output pengirisan array negatif JSONPath

    Versi baru telah mengubah perilaku pemotongan array negatif (contoh: [-2:], [-1:]). Sebelumnya, saat menerapkan pemotongan negatif ke array (menunjukkan elemen dari akhir array), versi lama akan salah menampilkan hanya satu item dari pemotongan tersebut. Versi baru kini menampilkan daftar (array) dengan benar yang berisi semua elemen yang berada dalam rentang negatif yang ditentukan.

    Misalnya $.store.book[-2:]

    Perilaku sebelumnya:
    {"price":12.99,"category":"fiction","author":"Evelyn Waugh"}
    
    Perilaku saat ini:
    [
      {"category":"fiction","author":"Evelyn Waugh","price":12.99},
      {"category":"fiction","author":"Herman Melville","price":8.99}
    ]
    
    Tindakan:

    Logika pemrosesan hilir kini harus diperbarui untuk melakukan iterasi melalui array JSON yang ditampilkan guna mendapatkan output yang diinginkan.

  6. Titik sebelumnya yang lebih ketat JSONPath

    Ada penerapan sintaksis yang lebih ketat untuk elemen yang diakses langsung dari root. Jika elemen diakses langsung dari root tanpa titik sebelumnya (contoh: $propertyelement), sintaksis tersebut kini dianggap sebagai error dan akan mencegah deployment proxy.

    Misalnya $store,

    {
      "bicycle": {
        "color": "red",
        "book": [{"author": "Abc"}]
      },
      "book": [
        {"price": 8.95, "category": "reference", "author": "Nigel Rees"},
        {"price": 12.99, "category": "fiction", "author": "Evelyn Waugh"},
        {"price": 8.99, "category": "fiction", "author": "Herman Melville"}
      ]
    }
    

    Perilaku saat ini:

    Proxy will fail to deploy.

    Tindakan:

    Ubah JSONPath Anda untuk menyertakan titik: $.propertyName (contoh: $.store). Tindakan ini akan menargetkan dan mengambil nilai dengan benar.

  7. Ekspresi JSONPath dinamis

    Perhatikan baik-baik kebijakan yang ekspresi JSONPath-nya sendiri disediakan oleh variabel (contoh: {myJsonPathVariable} atau {dynamicPath}). Nilai variabel ini juga harus diperiksa terhadap potensi perubahan perilaku yang diuraikan di atas.

Mitigasi

Identifikasi proxy atau alur bersama yang mungkin terpengaruh oleh upgrade menggunakan alat deteksi perubahan atau tinjau proxy API Anda secara manual untuk mencari pola yang dijelaskan. Jika Anda menggunakan alat ini, output akan mengidentifikasi proxy atau alur bersama yang terpengaruh, kebijakan yang relevan, dan jalur JSON yang bermasalah, seperti yang ditunjukkan dalam contoh output di bawah:

Organisasi Lingkungan Nama Artefak Jenis Artefak Revisi Nama Kebijakan Jenis Kebijakan Jenis Dampak Kolom Khusus Dampak Kepastian Dampak Dokumentasi
org1 dev proxy1 proxy 4 EV-ExtractRequestParams ExtractVariables Perubahan Perilaku Kartu Wildcard JSONPath [*] untuk Nilai Objek $.store[*] Tinggi Perubahan Perilaku Kartu Wildcard JSONPath [*] untuk Nilai Objek
org2 prod proxy2 sharedflow 1 EV-ExtractResponseParams ExtractVariables Titik (.) di Akhir JSONPath dalam Jalur Sekarang Menyebabkan Error $.store.book. Tinggi Titik di akhir (trailing dot) JSONPath (.) dalam jalur menyebabkan error
org3 dev proxy3 proxy 3 SC-FetchUserProfile ServiceCallout Perubahan Struktur Output Turunan Rekursif JSONPath (..) $..book Tinggi Perubahan struktur output penurunan rekursif (..) JSONPath
org4 prod proxy4 sharedflow 2 RF-InvalidAuthToken RaiseFault Pengindeksan JSONPath Setelah Pemilihan Multi-Item atau Filter Sekarang Menampilkan Array Kosong $.store.book[*][0] Tinggi Pengindeksan JSONPath setelah pemilihan atau filter multi-item menampilkan array kosong
org5 uji proxy5 proxy 6 SC-FetchProfileDetails ServiceCallout Perubahan Output Pengirisan Array Negatif JSONPath $.store.book[-2:] Tinggi Perubahan output pengirisan array negatif JSONPath
org6 prod proxy6 proxy 2 ML-LogRequestDetails MessageLogging Titik Sebelumnya yang Lebih Ketat JSONPath $store Tinggi Titik sebelumnya yang lebih ketat JSONPath
org7 uji proxy7 proxy 5 RF-InvalidTokenDetails RaiseFault Ekspresi JSONPath Dinamis myJsonPathVariable Sedang Ekspresi JSONPath dinamis

Untuk penjelasan mendetail tentang kolom dalam tabel output di atas, lihat bagian Memahami output alat.

Untuk memitigasi, diperlukan strategi yang komprehensif. Proses ini melibatkan penentuan jalur update yang sesuai dan penerapan perbaikan yang diperlukan untuk ekspresi JSONPath yang terdeteksi.

Pilih Metode Jalur Upgrade yang paling sesuai untuk Anda:

  • Migrasi Tanpa Periode Nonaktif

    Strategi ini melibatkan pengadaan satu atau beberapa lingkungan baru sehingga Anda dapat menghubungkan node pemroses pesan yang terpisah ke lingkungan tersebut. Node pemroses pesan tersebut dapat disetel untuk menginstal 4.53.01 dan memiliki proxy dengan ekspresi JSONPath modern. Ini dapat digunakan selama upgrade dan dapat dihentikan setelah upgrade selesai. Strategi ini lancar, tetapi melibatkan pengadaan sementara node pemroses pesan tambahan untuk mendukung upgrade yang lancar. Berikut detailnya:

    • Buat lingkungan baru dan tambahkan node pemroses pesan baru versi 4.53.01 ke lingkungan baru ini.
    • Upload paket proxy untuk proxy yang terpengaruh ke lingkungan baru dan terapkan perbaikan yang diperlukan yang dijelaskan di bagian perbaikan & deploy paket proxy yang diperbarui ke lingkungan baru.
    • Alihkan traffic ke lingkungan baru dan batalkan deployment proxy yang terpengaruh dari lingkungan lama.
    • Upgrade node pemroses pesan asli ke 4.53.01. Deploy proxy yang memiliki perbaikan untuk JSONPath di lingkungan asli.
    • Alihkan traffic kembali ke lingkungan lama, yang kini memiliki pemroses pesan di 4.53.01 dan proxy yang dimodernisasi untuk ekspresi jsonpath baru.
    • Hapus dan nonaktifkan lingkungan baru dan node terkait.
  • Periode nonaktif dan upgrade

    Strategi ini melibatkan pengadaan periode nonaktif untuk Proxy API menggunakan ekspresi JSON Path yang salah. Hal ini tidak memerlukan pengadaan node pemroses pesan tambahan, tetapi menyebabkan gangguan pada traffic API untuk proxy yang terpengaruh.

    • Identifikasi proxy yang terpengaruh dengan kebijakan yang terpengaruh dan buat revisi baru untuk semua proxy yang terpengaruh.
    • Terapkan perbaikan yang diperlukan dengan Menerapkan perbaikan yang dijelaskan di bagian perbaikan dalam revisi baru proxy. Jangan terapkan ini dulu.
    • Dapatkan waktu nonaktif untuk proxy yang terpengaruh.
    • Upgrade semua pemroses pesan ke Edge untuk Private Cloud versi 4.53.01. Perhatikan bahwa proxy yang ada mungkin gagal di pemroses pesan yang baru diupgrade.
    • Setelah semua pemroses pesan diupgrade ke Edge untuk versi cloud pribadi 4.53.01 , deploy revisi proxy yang baru dibuat dengan ekspresi JSONPath yang diperbaiki.
    • Melanjutkan lalu lintas di proxy tersebut.
  • Mendesain ulang Proxy sebelum upgrade

    Anda dapat mendesain ulang proxy itu sendiri sebelum mengupgrade ke Edge untuk Private Cloud 4.53.01. Daripada mengandalkan ekspresi jalur JSON tertentu, Anda bisa mendapatkan hasil yang sama dengan menggunakan metode lain.

    Misalnya, jika Anda menggunakan Kebijakan Ekstrak Variabel dengan jalur JSON, Anda dapat mengganti kebijakan tersebut dengan kebijakan Javascript yang mengekstrak data serupa sebelum mengupgrade ke versi yang lebih baru. Setelah upgrade selesai, Anda dapat mengubah proxy kembali menggunakan Jalur JSON dengan format yang lebih baru.

Perubahan JavaCallout

Konteks

Edge untuk cloud pribadi 4.53.00 dan yang lebih lama dulu berisi direktori bernama deprecated ($APIGEE_ROOT/edge-message-processor/lib/deprecated) yang berisi banyak library JAR. Library ini tersedia untuk digunakan dalam kode Java di kebijakan JavaCallout dan dapat digunakan oleh kode Java kustom Anda secara langsung atau tidak langsung.

Perubahan

Direktori tidak digunakan lagi kini dihapus di Edge untuk Private Cloud versi 4.53.01. Jika kode Java Anda mengandalkan library tersebut, proxy yang menggunakan panggilan Java tersebut akan gagal saat pemroses pesan diupgrade ke versi 4.53.01. Untuk menghindari kegagalan tersebut, ikuti langkah-langkah mitigasi di bawah sebelum mengupgrade pemroses pesan ke versi 4.53.01.

Mitigasi

  1. Tinjau kebijakan Java Callout dan JAR terkait menggunakan alat deteksi perubahan atau secara manual. Periksa apakah ada kebijakan yang mereferensikan library yang ada di direktori “deprecated” pemroses pesan Anda saat ini.

    Jika Anda menggunakan alat yang disediakan oleh Apigee untuk deteksi di atas, alat tersebut akan membuat laporan seperti yang ditunjukkan dalam tabel berikut . Secara khusus, kebijakan ini menargetkan kebijakan yang mereferensikan JAR yang ditemukan di direktori $APIGEE_ROOT/edge-message-processor/lib/deprecated pada versi Edge untuk Private Cloud yang lebih lama.

    Alat ini akan membuat laporan dalam format di bawah:

    Organisasi Lingkungan Nama Artefak Jenis Artefak Revisi Nama Kebijakan Jenis Kebijakan Jenis Dampak Kolom Khusus Dampak Kepastian Dampak Dokumentasi
    org1 Tidak ada Tidak ada org-level-jar Tidak ada Tidak ada java-callout library yang tidak digunakan lagi terdeteksi untuk simple-javacallout-o1-jar-1.jar ['Terdeteksi penggunaan class org.apache.commons.io.FileUtils dari commons-io-2.5.jar, 'Terdeteksi penggunaan class org.apache.commons.io.input.XmlStreamReaderException dari commons-io-2.5.jar'] Tinggi Perubahan JavaCallout
    org3 env3 Tidak ada env-level-jar Tidak ada Tidak ada java-callout library yang tidak digunakan lagi terdeteksi untuk fat-javacallout-e3-jar-1.jar ['Terdeteksi penggunaan class org.apache.http.impl.auth.NTLMSchemeFactory dari httpclient-4.5.2.jar'] Tinggi Perubahan JavaCallout
    org1 env1 p1 proxy-level-jar 1 Tidak ada java-callout library yang tidak digunakan lagi terdeteksi untuk simple-javacallout-p1-jar-1.jar ['Penggunaan class org.apache.commons.lang3.builder.ToStringBuilder dari commons-lang3-3.4.jar terdeteksi', 'Penggunaan class org.apache.commons.lang3.Validate dari commons-lang3-3.4.jar terdeteksi'] Tinggi Perubahan JavaCallout

    Untuk penjelasan mendetail tentang kolom dalam tabel output di atas, lihat bagian Memahami output alat.

  2. Setelah mengidentifikasi library yang tidak digunakan lagi tersebut , Anda dapat mengikuti salah satu metode di bawah untuk mengurangi masalah ini.
    • Penempatan resource (Direkomendasikan jika Anda memiliki sejumlah kecil JAR / library dari direktori yang tidak digunakan lagi yang dirujuk oleh JAR Java-Callout)
      • Upload JAR yang diidentifikasi sebagai tidak digunakan lagi sebagai resource di tingkat yang diinginkan: revisi proxy API, lingkungan, atau organisasi.
      • Lanjutkan upgrade software Apigee seperti biasa.
    • Penempatan Manual (Direkomendasikan jika Anda memiliki banyak JAR / library yang dirujuk oleh JAR Java-Callout)
      • Di setiap node pemroses pesan, buat direktori baru bernama external-lib di jalur $APIGEE_ROOT/data/edge-message-processor/.
      • Salin JAR yang diidentifikasi ke direktori external-lib ini dari direktori yang tidak digunakan lagi: cp $APIGEE_ROOT/edge-message-processor/lib/deprecated/some.jar $APIGEE_ROOT/data/edge-message-processor/external-lib/some.jar
      • Pastikan direktori dan JAR yang mendasarinya dapat dibaca oleh pengguna Apigee: chown -R apigee:apigee $APIGEE_ROOT/data/edge-message-processor/external-lib
      • Lanjutkan upgrade software Apigee seperti biasa.

Perubahan OpenLDAP

Konteks

OpenLDAP dapat digunakan di Edge Private Cloud untuk autentikasi dan otorisasi. Di Edge untuk Private Cloud 4.53.01, software OpenLDAP yang dikirimkan oleh Apigee diupgrade dari versi 2.4 ke 2.6.

Perubahan

Di OpenLDAP 2.6, nama yang dibedakan relatif (RDN) dibatasi hingga sekitar 241 byte/karakter. Batasan ini adalah batas maksimum yang diterapkan dan tidak dapat diubah.

Dampak
  • Kegagalan replikasi atau impor terjadi untuk entri dengan RDN yang terlalu besar.
  • Upaya untuk membuat entitas seperti organisasi, lingkungan, peran khusus, izin, dll. dapat menghasilkan pesan error: "message": "[LDAP: error code 80 - Other]".
  • DN yang lebih panjang dari 241 byte di LDAP Apigee akan terpengaruh. DN tersebut akan mencegah upgrade software Apigee OpenLDAP yang berhasil dan Anda harus mengikuti strategi mitigasi untuk item tersebut sebelum dapat melanjutkan upgrade.

Umumnya, di LDAP Apigee, DN yang panjang terkait dengan izin karena dibuat dengan menggabungkan beberapa entity. Entri izin tersebut sangat rentan terhadap masalah upgrade.

Misalnya,

dn: cn=@@@environments@@@*@@@applications@@@*@@@revisions@@@*@@@debugsessions,ou=resources,cn=businessuser,ou=userroles,o=orgname,ou=organizations,dc=apigee,dc=com

Biasanya, Anda akan memiliki nama organisasi, lingkungan, dan peran dengan panjang sedemikian rupa sehingga RDN di LDAP menjadi lebih kecil dari 241 byte.

Mitigasi

Sebelum upgrade ke 4.53.01:

Langkah-langkah berikut akan membantu memverifikasi keberadaan RDN panjang di cluster LDAP 2.4 yang ada.

#1 - Ekstrak data LDAP

Gunakan perintah ldapsearch untuk menemukan nama khusus (dn) dan mengalihkan output ke file:

ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w LDAP_PASSWORD dn > /tmp/DN.ldif

Pastikan file DN.ldif di atas memiliki entri LDAP.

#2 - Mengidentifikasi RDN panjang

Alat deteksi perubahan menggunakan file LDIF yang dihasilkan untuk mengidentifikasi RDN LDAP yang melebihi 241 byte/karakter.

Alat ini akan membuat laporan dalam format berikut:

Organisasi Lingkungan Nama Artefak Jenis Artefak Revisi Nama Kebijakan Jenis Kebijakan Jenis Dampak Kolom Khusus Dampak Kepastian Dampak Dokumentasi
Tidak ada Tidak ada cn=really-long-name,ou=userroles,o=edge-platform,ou=organizations,dc=apigee,dc=com file ldif Tidak ada Tidak ada Tidak ada RDN LDAP melebihi 241 karakter cn=really-long-name Tinggi Perubahan OpenLDAP

Untuk penjelasan mendetail tentang kolom dalam tabel output di atas, lihat bagian Memahami output alat.

Jika perintah di atas tidak menghasilkan output, berarti tidak ada RDN dalam penyiapan LDAP yang ada yang melebihi 241 byte/karakter. Anda dapat melanjutkan upgrade seperti biasa.

Jika perintah di atas menghasilkan output, hal ini menunjukkan adanya RDN yang melebihi 241 byte/karakter. Untuk item tersebut, ikuti langkah-langkah mitigasi seperti yang dijelaskan di langkah#3 sebelum melanjutkan upgrade Edge untuk Private Cloud 4.53.01.

#3 - Menangani RDN panjang

Jika output diterima dari langkah#2, hal ini menunjukkan adanya RDN yang melebihi 241 byte/karakter dan ikuti langkah-langkah mitigasi di bawah:

Tinjau entri LDAP yang melebihi 241 byte.

  • Jika nama peran kustom, Aplikasi, produk API, atau entitas lain adalah faktor utama yang menyebabkan RDN menjadi panjang, migrasikan ke penggunaan entitas alternatif dengan nama yang lebih pendek.
  • Jika nama organisasi atau nama lingkungan yang menjadi kontributor utama RDN panjang, Anda harus bermigrasi ke organisasi atau lingkungan lain dengan nama yang lebih pendek.

Terus ulangi langkah-langkah di atas hingga LDAP Anda tidak memiliki RDN yang lebih panjang dari 241 byte. Setelah Anda mencapai status ini, lanjutkan upgrade versi cloud pribadi seperti biasa.

Perubahan Penyedia Kriptografi

Konteks

Perubahan ini merupakan kelanjutan dari Edge for Private Cloud 4.53.00. Di Edge untuk Private Cloud 4.53.00, penyedia kriptografi internal diupdate dari Bouncy Castle (BC) ke Bouncy Castle FIPS (BCFIPS) untuk mengaktifkan dukungan FIPS.

Perubahan

Jika kebijakan JavaCallout mengandalkan penggunaan penyedia BC asli, terutama saat menggunakan fungsi keamanan yang telah diperkuat di penyedia BCFIPS (misalnya, menggunakan pasangan kunci umum untuk enkripsi dan penandatanganan), kebijakan JavaCallout tersebut harus dimodernisasi. Kebijakan JavaCallout yang mencoba memuat penyedia kriptografi Bouncy Castle menggunakan nama BC dapat gagal karena penyedia default telah berubah. Kebijakan tersebut yang menggunakan penyedia BC dapat rusak. Semua penerapan kustom yang mengandalkan penyedia BC lama tidak akan dapat diakses lagi dan perlu ditinjau serta diterapkan ulang.

Mitigasi

Solusi yang direkomendasikan adalah menggunakan penyedia BCFIPS. Implementasi JavaCallout kustom yang mengandalkan penyedia lama harus ditinjau dan diimplementasikan ulang menggunakan penyedia Bouncy Castle FIPS, yang dapat diakses menggunakan string "BCFIPS".

Alat deteksi perubahan

Alat deteksi perubahan telah dibuat untuk mengidentifikasi proxy, kebijakan, dan shared flow Apigee yang mungkin terpengaruh selama dan setelah transisi ke Edge untuk Private Cloud 4.53.01. Alat ini menghasilkan laporan yang menjelaskan proxy yang di-deploy, alur bersama, dan OpenLDAP yang terpengaruh oleh perubahan serta memberikan arahan ke panduan dan strategi khusus yang relevan dengan proxy atau alur bersama yang diidentifikasi tersebut.

Prasyarat

  1. Mesin berbasis RHEL diperlukan untuk menjalankan alat ini.
  2. JRE 8 harus diinstal dan dikonfigurasi dengan benar di virtual machine host agar skrip alat dapat berjalan.
  3. Alat ini memerlukan endpoint (URL) yang benar dari Server Pengelolaan dan kredensial administratif yang valid untuk autentikasi dan pengambilan data.
  4. Alat ini memerlukan akses ke direktori kerja yang ditentukan (misalnya,/tmp) untuk mengekstrak paket, membuat log, dan menyimpan output. Pastikan direktori ini memiliki ruang disk yang cukup dan izin baca/tulis yang sesuai.
  5. Alat ini memerlukan file LDIF menggunakan perintah ldapsearch di bagian Perubahan OpenLDAP - Ekstrak data LDAP untuk mendeteksi RDN panjang yang lebih dari 241 karakter / byte.

Menjalankan alat

Setelah semua prasyarat yang tercantum di atas terpenuhi, download alat ini sambil memberikan nama pengguna dan sandi dari Apigee yang Anda gunakan untuk mengakses repositori Apigee. Setelah didownload, ekstrak arsip yang didownload.

curl -u uName:pWord https://software.apigee.com/apigee/change-detector/change-detector-for-4.53.01_1.0.0.zip -o /tmp/change-detector-for-4.53.01_1.0.0.zip
unzip /tmp/change-detector-for-4.53.01_1.0.0.zip

Setelah download selesai, Anda dapat menjalankan perintah berikut untuk melihat semua opsi yang tersedia untuk alat:

./change-detector --help

Untuk menjalankan alat, gunakan perintah berikut dan ganti placeholder dengan informasi Anda:

export APIGEE_PASSWORD=[your_password]
./change-detector --username [your_username] --mgmt-url [MGMT url]

Untuk mendeteksi entri LDAP RDN besar, jalankan perintah berikut:

./change-detector --username [your_username] --mgmt-url [MGMT url] --ldif-file [LDIF_file]

Alat ini menghasilkan output dalam format json atau csv yang dapat langsung digunakan atau diimpor ke alat yang dapat dibaca manusia, seperti Google Spreadsheet.

Memahami output alat

Organisasi

Menunjuk ke nama organisasi tempat artefak berada. Untuk perubahan OpenLDAP, nilainya adalah None.

Lingkungan

Lingkungan tertentu (misalnya, dev, test, prod) dalam organisasi. Untuk perubahan OpenLDAP, nilainya adalah None.

Untuk perubahan Panggilan Java, jika Jenis Artefak=env-level-jar, kolom ini akan menjadi None.

Nama artefak

Kolom ini menjelaskan nama proxy/alur bersama. Untuk perubahan OpenLDAP, kolom ini menampilkan entitas LDAP RDN.

Untuk perubahan Java Callout, jika Jenis Artefak=env-level-jar atau org-level-jar, kolom ini akan menjadi None.

Jenis artefak

  • Untuk perubahan OAS dan JSON, kolom ini menentukan jenis artefak, proxy, atau alur bersama.
  • Untuk perubahan Panggilan Java, kolom ini memberikan detail tentang tempat atau tingkat saat jar yang terpengaruh diupload. Resource (JAR) dapat disimpan di salah satu dari tiga tingkat: org-level, env-level, proxy-level.
  • Untuk perubahan OpenLDAP, kolom ini menunjukkan file LDIF yang digunakan dalam alat.

Revisi

Bagian ini mengarah ke revisi yang di-deploy dari proxy/alur bersama yang terpengaruh. Untuk perubahan OpenLDAP, akan menjadi None.

Nama kebijakan

Nama kebijakan tertentu yang telah diidentifikasi sebagai potensi masalah. Untuk perubahan OpenLDAP, akan menjadi None.

Jenis kebijakan

Menunjukkan jenis kebijakan. Untuk perubahan OpenLDAP, akan menjadi None.

Jenis dampak

  • Kolom ini menjelaskan jenis perubahan spesifik yang terdeteksi dalam proxy/alur bersama.
  • Untuk perubahan Java Callout, deteksi perubahan terkait java-callout, alat ini mengarah ke java-callout yang terpengaruh yang memiliki referensi ke JAR yang ada di direktori $APIGEE_ROOT/edge-message-processor/lib/deprecated versi Edge for Private Cloud yang lebih lama dengan cara berikut di kolom tertentu ini.
  • deprecated library detected for NAME_OF_THE_AFFECTED_JAVA_CALLOUT_JAR
  • Untuk perubahan OpenLDAP, kolom ini menunjukkan apakah RDN entitas LDAP melebihi 241 byte atau karakter.

Memengaruhi kolom tertentu

  • Untuk perubahan OAS, kolom ini adalah nama variabel yang digunakan dalam tag Sumber kebijakan.
  • Untuk perubahan JSON, kolom ini menampilkan ekspresi atau elemen JSONPath yang tepat yang telah ditandai sebagai potensi masalah.
  • Untuk perubahan Java Callout, kolom ini berisi detail kelas yang tepat dan nama JAR yang sesuai (ada di direktori $APIGEE_ROOT/edge-message-processor/lib/deprecated versi Private Cloud yang lebih lama) yang digunakan/dirujuk oleh JAR JavaCallout yang terpengaruh yang akan menyebabkan kegagalan saat mengupgrade ke versi 4.53.01 jika tidak ditangani.
  •  ['Detected use of class CLASS_NAME_1 from JAR_NAME_1',
        Detected use of class CLASS_NAME_2 from JAR_NAME_2', 
      .. , .. , ]
  • Untuk perubahan OpenLDAP, kolom ini menampilkan RDN entitas LDAP yang semuanya melebihi 241 byte atau karakter.

Kepastian dampak

  • Kolom ini menunjukkan tingkat kepastian alat dalam mendeteksi item tertentu. Nilai untuk kolom ini dapat berupa Tinggi atau Sedang (nilai lainnya dapat ditambahkan nanti).

    Nilai Tinggi berarti alat telah menentukan bahwa ada kemungkinan yang sangat tinggi bahwa item tersebut akan menyebabkan aplikasi rusak setelah diupgrade ke versi 4.53.01. Nilai Sedang menunjukkan bahwa alat tidak jelas tentang deteksi dan diperlukan lebih banyak strategi untuk membuat penentuan (Misalnya, merekam aktivitas untuk mengamati variabel yang diselesaikan selama eksekusi proxy).

  • Deteksi terkait perubahan JavaCallout dan OpenLDAP akan selalu memiliki nilai Tinggi untuk kolom kepastian dampak.

Dokumentasi

Kolom ini menyediakan hyperlink ke dokumentasi Apigee (bagian yang relevan dari artikel ini) yang menjelaskan masalah dan langkah-langkah mitigasinya.