Memperbarui Kebijakan OPA secara Dinamis di ASM -

Service Mesh (ASM) terintegrasi dengan Open Policy Agent (OPA), memungkinkan Anda mendefinisikan kebijakan kontrol akses untuk menerapkan kontrol yang lebih rinci pada aplikasi. Instance ASM versi 1.8.6.41 dan yang lebih baru mendukung pembuatan ConfigMaps untuk mendorong kebijakan OPA ke kontainer secara otomatis, sehingga memungkinkan pembaruan dinamis. Topik ini menjelaskan cara memperbarui kebijakan OPA secara dinamis di ASM.

Prasyarat

Sebuah instance ASM dengan versi v1.8.6.41-gb1d8f288-aliyun atau yang lebih baru telah dibuat. Untuk informasi lebih lanjut, lihat Buat instance ASM.
Sebuah kluster ACK dikelola telah dibuat. Untuk informasi lebih lanjut, lihat Buat kluster ACK dikelola.
Kluster ditambahkan ke instance ASM.

Informasi latar belakang

OPA adalah proyek tingkat inkubasi yang dikelola oleh Cloud Native Computing Foundation (CNCF). Sebagai mesin kebijakan, OPA dapat digunakan untuk menerapkan kontrol akses yang lebih rinci pada aplikasi Anda. Anda dapat menyebarkan OPA sebagai layanan mandiri bersama dengan mikro layanan. Untuk melindungi aplikasi, pastikan setiap permintaan masuk ke mikro layanan diotorisasi sebelum diproses. Mikro layanan melakukan panggilan API ke OPA untuk memutuskan apakah permintaan tersebut diizinkan. OPA

Langkah 1: Aktifkan OPA

Masuk ke Konsol ASM.
Di panel navigasi sisi kiri, pilih Service Mesh > Mesh Management.
Di halaman Mesh Management, temukan instance ASM yang ingin dikonfigurasi. Klik nama instance ASM atau pilih Manage di kolom Actions.
Di bagian Basic Information, klik Settings di pojok kanan atas.
Di panel Settings Update, pilih Enable OPA Plug-in.
Klik OK.
Di bagian Basic Information, status di bidang OPA Plug-in berubah menjadi Enabled.

Langkah 2: Buat ConfigMaps

ASM mendukung pembaruan dinamis kebijakan OPA. Anda dapat membuat ConfigMap dengan label openpolicyagent.org/policy=rego untuk mendefinisikan kebijakan OPA. Kebijakan tersebut akan didorong secara otomatis ke pod yang disuntik dengan kontainer sidecar OPA di semua namespace. Jika Anda menghapus ConfigMap, kebijakan OPA juga akan dihapus dari pod.

Penting

Saat mendefinisikan kebijakan OPA untuk sebuah pod, pastikan hanya satu kebijakan OPA yang berisi bidang default allow. Jika beberapa ConfigMaps berlaku untuk sebuah pod dan bidang default allow didefinisikan di setiap kebijakan, pembaruan dinamis kebijakan OPA gagal karena adanya beberapa bidang default allow.
Pemulaan kontainer sidecar OPA bergantung pada ConfigMap bernama opa-policy. Jika Anda menghapus ConfigMap, kebijakan OPA yang didefinisikan oleh ConfigMap juga dihapus dari kontainer sidecar OPA. Jika Anda membuat ulang ConfigMap, kebijakan OPA yang dihapus tidak dipulihkan. Untuk menggunakan kembali kebijakan OPA, Anda harus membuat ulang pod tempat kebijakan awalnya didorong.

Tentukan tipe kredensial KubeConfig. Untuk informasi lebih lanjut, lihat Langkah 2: Pilih jenis kredensial kluster.
Buat sebuah ConfigMap bernama opa-policy.
Pemulaan kontainer sidecar OPA bergantung pada ConfigMap bernama opa-policy. ConfigMap ini mendukung pembaruan dinamis kebijakan OPA. Kami menyarankan Anda untuk hanya mengonfigurasi pengaturan kebijakan dasar di dalam ConfigMap. Anda dapat membuat ConfigMap lain untuk mengonfigurasi pengaturan kebijakan yang lebih kompleks.
1. Gunakan konten berikut untuk membuat file YAML bernama opa-policy:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy
data:
  policy.rego: | ### Pendorongan dinamis kebijakan OPA bergantung pada jalur yang diizinkan dalam ConfigMap. Jika Anda tidak menentukan jalur dalam ConfigMap, kebijakan OPA gagal diperbarui secara dinamis. 
    package istio.authz

    import input.parsed_path
    
    allow {
            parsed_path[0] = "v1"
            parsed_path[1] = "policies"
    }
```
2. Jalankan perintah berikut untuk membuat ConfigMap:
```
kubectl apply -f opa-policy.yaml
```

Buat sebuah ConfigMap bernama opa-policy-add.

Gunakan ConfigMap untuk mendefinisikan kebijakan OPA.

Gunakan konten berikut untuk membuat file YAML bernama opa-policy-add:

apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy-add
  labels:
    ### Anda harus mengonfigurasi label berikut dalam ConfigMap. Jika tidak, kebijakan OPA yang didefinisikan oleh ConfigMap tidak dapat diperbarui secara dinamis.
    openpolicyagent.org/policy: rego
data:
  policy.rego: |  ### Kode berikut menunjukkan definisi dari contoh kebijakan. Definisikan kebijakan berdasarkan kebutuhan aktual Anda.
    package istio.authz
    import input.attributes.request.http as http_request
    default allow = false
    allow {
        roles_for_user[r]
        required_roles[r]
    }
    roles_for_user[r] {
        r := user_roles[user_name][_]
    }
    required_roles[r] {
        perm := role_perms[r][_]
        perm.method = http_request.method
        perm.path = http_request.path
    }
    user_name = parsed {
        [_, encoded] := split(http_request.headers.authorization, " ")
        [parsed, _] := split(base64url.decode(encoded), ":")
    }
    user_roles = {
        "guest1": ["guest"],
        "admin1": ["admin"]
    }
    role_perms = {
        "guest": [
            {"method": "GET",  "path": "/productpage"},
        ],
        "admin": [
            {"method": "GET",  "path": "/productpage"},
            {"method": "GET",  "path": "/api/v1/products"},
        ],
    }

user_roles: Menetapkan peran kepada pengguna. Dalam contoh ini, tetapkan peran guest kepada pengguna guest1 dan peran admin kepada pengguna admin1.
role_perms: Menentukan izin setiap peran. Dalam contoh ini, berikan peran guest izin untuk mengakses aplikasi menggunakan URL yang berisi /productpage, dan berikan peran admin izin untuk mengakses aplikasi menggunakan URL yang berisi /productpage atau /api/v1/products.

Jalankan perintah berikut untuk membuat ConfigMap:
```
kubectl apply -f opa-policy-add.yaml
```

Jalankan perintah berikut untuk melihat hasil dorongan kebijakan:
Hasil dorongan kebijakan dicatat dalam parameter annotations di ConfigMap.
```
kubectl get configmap  opa-policy-add -o yaml  
```
Lihat ConfigMap di hasil keluaran perintah:
- Jika dorongan berhasil, informasi berikut ditampilkan di ConfigMap.
```
openpolicyagent.org/policy-status: '{"status":"ok"}'
```
- Jika dorongan gagal, informasi kesalahan yang sesuai akan ditampilkan di ConfigMap.

Langkah 3: Suntikkan sidecar OPA

Sebarkan aplikasi sampel Bookinfo di instance ASM dan periksa apakah sidecar OPA disuntikkan ke setiap pod aplikasi Bookinfo.

Sebarkan aplikasi Bookinfo di instance ASM. Untuk informasi lebih lanjut, lihat Sebarkan aplikasi di instance ASM.
Definisikan layanan virtual Istio dan layanan gateway masuk sesuai kebutuhan. Untuk informasi lebih lanjut, lihat Gunakan sumber daya Istio untuk merutekan lalu lintas ke versi layanan yang berbeda.
Periksa apakah sidecar OPA disuntikkan ke dalam pod setiap aplikasi di aplikasi Bookinfo.
1. Masuk ke ACK console.
2. Di panel navigasi sisi kiri ACK console, klik Clusters.
3. Pada halaman Clusters, temukan kluster yang ingin dikelola dan klik nama kluster tersebut atau pilih Details di kolom Actions. Halaman detail kluster akan muncul.
4. Di panel navigasi sisi kiri halaman detail, pilih Workloads > Pods.
5. Di bagian atas halaman Pods, pilih default dari daftar drop-down Namespace. Klik nama pod dari sebuah aplikasi.
  Pada tab Container, Anda dapat menemukan bahwa proxy sidecar bernama istio-proxy dan sidecar OPA bernama opa-istio telah disuntikkan ke setiap container. Periksa container dari setiap aplikasi secara bergantian untuk memastikan bahwa proxy sidecar dan sidecar OPA telah disuntikkan ke setiap container.

Langkah 4: Verifikasi bahwa kebijakan OPA menerapkan kontrol akses seperti yang diharapkan

Jalankan perintah cURL berikut. Hasilnya menunjukkan bahwa peran guest diberikan kepada pengguna guest1. Selain itu, pengguna guest1 memiliki izin untuk mengakses aplikasi menggunakan URL yang berisi /productpage, tetapi tidak /api/v1/products.
```
curl -X GET http://{{Alamat IP layanan gateway masuk}}/productpage --user guest1:password -I
```
Keluaran berikut diharapkan:
```
HTTP/1.1 200 OK
```
```
curl -X GET http://{{Alamat IP layanan gateway masuk}}/api/v1/products --user guest1:password -I
```
Keluaran berikut diharapkan:
```
HTTP/1.1 403 Forbidden
```
Jalankan perintah cURL berikut. Hasilnya menunjukkan bahwa peran admin diberikan kepada pengguna admin1. Selain itu, pengguna admin1 memiliki izin untuk mengakses aplikasi menggunakan URL yang berisi /productpage atau /api/v1/products.
```
curl -X GET http://{{Alamat IP layanan gateway masuk}}/productpage --user admin1:password -I
```
Keluaran berikut diharapkan:
```
HTTP/1.1 200 OK
```
```
curl -X GET http://{{Alamat IP layanan gateway masuk}}/api/v1/products --user admin1:password -I
```
Keluaran berikut diharapkan:
```
HTTP/1.1 200 OK
```
Hasil sebelumnya menunjukkan bahwa kebijakan OPA yang didefinisikan menerapkan kontrol akses seperti yang diharapkan.

Langkah 5: Perbarui kebijakan OPA secara dinamis

Jalankan perintah berikut pada kluster ACK untuk memperbarui ConfigMap bernama opa-policy-add:

kubectl replace -n {Namespace tempat ACK cluster berada} -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy-add
  labels:
    ### Anda harus mengonfigurasi label berikut dalam ConfigMap. Jika tidak, kebijakan OPA yang didefinisikan oleh ConfigMap tidak dapat diperbarui secara dinamis.
    openpolicyagent.org/policy: rego
data:
  policy.rego: |  ### Kode berikut menunjukkan definisi dari contoh kebijakan. Definisikan kebijakan berdasarkan kebutuhan aktual Anda.
    package istio.authz
    import input.attributes.request.http as http_request
    default allow = false
    allow {
        roles_for_user[r]
        required_roles[r]
    }
    roles_for_user[r] {
        r := user_roles[user_name][_]
    }
    required_roles[r] {
        perm := role_perms[r][_]
        perm.method = http_request.method
        perm.path = http_request.path
    }
    user_name = parsed {
        [_, encoded] := split(http_request.headers.authorization, " ")
        [parsed, _] := split(base64url.decode(encoded), ":")
    }
    user_roles = {
        "guest1": ["guest", "admin"],
        "admin1": ["admin"]
    }
    role_perms = {
        "guest": [
            {"method": "GET",  "path": "/productpage"},
        ],
        "admin": [
            {"method": "GET",  "path": "/productpage"},
            {"method": "GET",  "path": "/api/v1/products"},
        ],
    }
EOF

user_roles: Menetapkan peran kepada pengguna. Dalam contoh ini, tetapkan peran guest dan admin kepada pengguna guest1 serta peran admin kepada pengguna admin1.
role_perms: Menentukan izin untuk setiap peran. Dalam contoh ini, berikan peran guest izin untuk mengakses aplikasi menggunakan URL yang berisi /productpage, dan berikan peran admin izin untuk mengakses aplikasi menggunakan URL yang berisi /productpage atau /api/v1/products.

Jalankan perintah berikut untuk melihat hasil dorongan kebijakan:
Hasil dorongan kebijakan dicatat dalam parameter annotations di ConfigMap.
```
kubectl get configmap  opa-policy-add -o yaml  
```
Lihat ConfigMap di hasil keluaran perintah:
- Jika dorongan berhasil, informasi berikut ditampilkan di ConfigMap.
```
openpolicyagent.org/policy-status: '{"status":"ok"}'
```
- Jika dorongan gagal, informasi kesalahan yang sesuai ditampilkan di ConfigMap.

Langkah 6: Verifikasi bahwa kebijakan OPA diperbarui secara dinamis

Jalankan perintah cURL berikut. Hasilnya menunjukkan bahwa peran admin diberikan kepada pengguna guest1. Selain itu, pengguna guest1 memiliki izin untuk mengakses aplikasi menggunakan URL yang berisi /productpage atau /api/v1/products.

curl -X GET http://{{Alamat IP layanan gateway masuk}}/productpage --user guest1:password -I

Keluaran berikut diharapkan:

HTTP/1.1 200 OK

curl -X GET http://{{Alamat IP layanan gateway masuk}}/api/v1/products --user guest1:password -I

Keluaran berikut diharapkan:

HTTP/1.1 200 OK

Sebelum kebijakan OPA diperbarui, pengguna guest1 dapat mengakses aplikasi menggunakan URL yang berisi /productpage, tetapi tidak /api/v1/products. Setelah kebijakan OPA diperbarui, pengguna guest1 dapat mengakses aplikasi menggunakan URL yang berisi /productpage atau /api/v1/products. Hasilnya menunjukkan bahwa kebijakan OPA diperbarui secara dinamis.