ASM'de OPA ilkelerini dinamik olarak güncelleme - - Alibaba Cloud Dokümantasyon Merkezi

Alibaba Cloud Service Mesh (ASM), Open Policy Agent (OPA) eklentisiyle entegre çalışır ve uygulamalarınız için ayrıntılı erişim kontrol ilkeleri tanımlamanıza olanak tanır. v1.8.6.41 veya sonraki sürümlerdeki ASM örnekleri, OPA ilkelerini pod'lara otomatik olarak göndermek için bir ConfigMap yapılandırmanızı destekler; bu sayede ilkeler dinamik olarak güncellenebilir. Bu konuda, ASM'de OPA ilkelerini nasıl dinamik olarak güncelleyeceğiniz gösterilmektedir.

Önkoşullar

v1.8.6.41-gb1d8f288-aliyun veya daha yeni bir sürümde ASM örneği oluşturmuş olmalısınız. Daha fazla bilgi için bkz. ASM örneği oluşturma.
Yönetilen bir ACK kümesi oluşturmuş olmalısınız. Daha fazla bilgi için bkz. Yönetilen ACK kümesi oluşturma.
Kümeyi ASM örneğine ekleme işlemini tamamlamış olmalısınız.

Arka plan bilgileri

CNCF tarafından kuluçka projesi olarak barındırılan Open Policy Agent (OPA), uygulamalarınız için ayrıntılı erişim kontrolü uygulamanıza olanak tanıyan bir ilke altyapısıdır. Genel amaçlı bir ilke altyapısı olarak OPA, mikroservislerinizin yanında bağımsız bir hizmet olarak dağıtılabilir. Bir uygulamayı korumak için mikroservise gelen her isteğin yetkilendirilmesi gerekir. Mikroservis, isteğin izin verilip verilmediğini belirlemek üzere OPA API'sini sorgular. OPA

Adım 1: OPA'yı etkinleştirin

ASM konsolu oturumunu açın.
Sol gezinme bölmesinde Service Mesh > Mesh Management seçeneğini belirleyin.
Mesh Management sayfasında, yapılandırmak istediğiniz ASM örneğini bulun. ASM örneğinin adını tıklayın veya Actions sütunundaki Manage öğesini tıklayın.
Basic Information sayfasında, sağ üst köşedeki Settings seçeneğini tıklayın.
Settings Update panelinde Enable OPA plug-in seçeneğini işaretleyin.
OK seçeneğini tıklayın.

Basic Information sayfasında, OPA Plug-in durumu Enable olarak değişir.

Adım 2: ConfigMap'leri oluşturun

ASM, OPA ilkelerinin dinamik güncellenmesini destekler. Service Mesh yapılandırmasında openpolicyagent.org/policy=rego etiketini kullanabilirsiniz. Bu şekilde, ilke tüm ad alanlarında OPA sidecar enjekte edilmiş tüm pod'lara otomatik olarak gönderilir. ConfigMap kaldırıldığında, ilke de pod'lardan kaldırılır.

Önemli

Bir pod için OPA ilkesi tanımlarken yalnızca bir adet default allow alanı dahil edebilirsiniz. Birden fazla OPA ilkesiyle ilişkili ConfigMap aynı poda uygulanıyorsa ve her ilke bir default allow alanı tanımlıyorsa, çoklu default allow alanları dinamik güncellemelerin başarısız olmasına neden olur.
OPA sidecar, başlatma işlemi için opa-policy adlı bir ConfigMap'e bağımlıdır. Bu ConfigMap'i silerseniz, ilgili OPA ilkesi de OPA sidecar'dan kaldırılır. ConfigMap'i yeniden oluşturmak ilkeyi geri yüklemez; pod'u yeniden oluşturmanız gerekir.

Kümenin kubeconfig dosyasını alın ve kubectl kullanarak kümeye bağlanın.
opa-policy adlı bir ConfigMap oluşturun.

OPA sidecar, başlatma işlemi için opa-policy adlı bir ConfigMap gerektirir. Bu ConfigMap dinamik güncellemeleri destekler. Yalnızca temel ilke yapılandırması için bu ConfigMap'i kullanın. Karmaşık ilkeleri diğer ConfigMap'ler aracılığıyla dinamik olarak ekleyin.
1. Aşağıdaki içeriği kullanarak opa-policy adlı bir YAML dosyası oluşturun:
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy
data:
  policy.rego: | ### The paths allowed in this policy are required for dynamic OPA policy updates. If these paths are not configured, the updates will fail.
    package istio.authz
    import input.parsed_path
    allow {
            parsed_path[0] = "v1"
            parsed_path[1] = "policies"
    }
```
2. ConfigMap'i oluşturmak için aşağıdaki komutu çalıştırın:
```
kubectl apply -f opa-policy.yaml
```

opa-policy-add adlı bir ConfigMap oluşturun.

OPA ilkenizi tanımlamak için bu ConfigMap'i kullanın.

Aşağıdaki içeriği kullanarak opa-policy-add adlı bir YAML dosyası oluşturun:

apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy-add
  labels:
    ### You must configure the following label in the ConfigMap. Otherwise, the OPA policy that the ConfigMap defines cannot be dynamically updated. 
    openpolicyagent.org/policy: rego
data:
  policy.rego: |  ### The following code shows the definition of a sample policy. Define a policy based on your actual needs. 
    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: Kullanıcılara rol atar. Bu örnekte, guest rolü guest1 kullanıcısına ve admin rolü admin1 kullanıcısına atanır.
role_perms: Her rol için izinleri ayarlar. Bu örnekte, guest rolünün /productpage yolundaki uygulamaya erişmesine ve admin rolünün /productpage ile /api/v1/products yollarındaki uygulamalara erişmesine izin verilir.

ConfigMap'i oluşturmak için aşağıdaki komutu çalıştırın:
```
kubectl apply -f opa-policy-add.yaml
```

İlke gönderim sonucunu görüntülemek için aşağıdaki komutu çalıştırın:
Gönderim durumu, ConfigMap'in annotations alanında güncellenir.
```
kubectl get configmap  opa-policy-add -o yaml  
```
Komut çıktısında ConfigMap'i inceleyin:
- Gönderim başarılıysa, ConfigMap'te aşağıdaki bilgileri görürsünüz.
```
openpolicyagent.org/policy-status: '{"status":"ok"}'
```
- Gönderim başarısız olursa, ilgili bir hata iletisi görüntülenir.

Adım 3: OPA sidecar enjekte edin

Örnek Bookinfo uygulamasını ASM örneğine dağıtın ve Bookinfo uygulamasının her pod'una bir OPA sidecar enjekte edilip edilmediğini kontrol edin.

Bookinfo örnek uygulamasını ASM örneğine dağıtın. Daha fazla bilgi için bkz. Uygulamayı ASM örneğine dağıtma.
Gerekirse Istio sanal hizmetlerini ve bir giriş ağ geçidi hizmetini tanımlayın. Daha fazla bilgi için bkz. Istio ile sürüm tabanlı trafik yönlendirme.
Bookinfo uygulamasındaki her uygulamanın pod'larına OPA sidecar enjekte edilip edilmediğini kontrol edin.
1. Container Service Management Console oturumunu açın.
2. Sol gezinme bölmesinde Cluster seçeneğini tıklayın.
3. Cluster List sayfasında, hedef kümenin adını tıklayın veya Actions sütunundaki Details seçeneğini tıklayın.
4. Küme yönetimi sayfasının sol gezinme bölmesinde Workload > Pods seçeneğini belirleyin.
5. Pods sayfasında, Namespace açılır listesinden default değerini seçin ve hedef uygulamanın pod adını tıklayın.
  
  Containers sekmesinde, bir sidecar proxy'sinin (istio-proxy) ve bir OPA sidecar'ının (opa-istio) enjekte edildiğini doğrulayın. Bu kontrolü her uygulama pod'u için tekrarlayın.

Adım 4: OPA ilkesinin erişim kontrolünü beklendiği gibi uyguladığını doğrulayın

Aşağıdaki komutları çalıştırın. Sonuçlar, guest rolüne sahip guest1 kullanıcısının /productpage adresindeki uygulamaya erişebildiğini ancak /api/v1/products adresindeki erişiminin reddedildiğini gösterir.
```
curl -X GET http://{{The IP address of the ingress gateway service}}/productpage --user guest1:password -I
```
Beklenen çıktı aşağıdaki gibidir:
```
HTTP/1.1 200 OK
```
```
curl -X GET http://{{The IP address of the ingress gateway service}}/api/v1/products --user guest1:password -I
```
Beklenen çıktı aşağıdaki gibidir:
```
HTTP/1.1 403 Forbidden
```
Aşağıdaki komutları çalıştırın. Sonuçlar, admin rolüne sahip admin1 kullanıcısının hem /productpage hem de /api/v1/products yollarındaki uygulamalara erişebildiğini gösterir.
```
curl -X GET http://{{The IP address of the ingress gateway service}}/productpage --user admin1:password -I
```
Beklenen çıktı aşağıdaki gibidir:
```
HTTP/1.1 200 OK
```
```
curl -X GET http://{{The IP address of the ingress gateway service}}/api/v1/products --user admin1:password -I
```
Beklenen çıktı aşağıdaki gibidir:
```
HTTP/1.1 200 OK
```
Yukarıdaki sonuçlar, tanımlanan OPA ilkesinin erişim kontrolünü beklendiği gibi uyguladığını gösterir.

Adım 5: OPA ilkesini dinamik olarak güncelleyin

opa-policy-add adlı ConfigMap'i güncellemek için ACK kümesinde aşağıdaki komutu çalıştırın:

kubectl replace -n {The namespace where the ACK cluster resides} -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: opa-policy-add
  labels:
    ### You must configure the following label in the ConfigMap. Otherwise, the OPA policy that the ConfigMap defines cannot be dynamically updated. 
    openpolicyagent.org/policy: rego
data:
  policy.rego: |  ### The following code shows the definition of a sample policy. Define a policy based on your actual needs. 
    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: Kullanıcılara rol atar. Bu örnekte, guest1 kullanıcısına hem guest hem de admin rolleri verilirken admin1 kullanıcısına admin rolü verilir.
role_perms: Her rol için izinleri ayarlar. Bu örnekte, guest rolünün /productpage yolundaki uygulamaya erişmesine ve admin rolünün /productpage ile /api/v1/products yollarındaki uygulamalara erişmesine izin verilir.

İlke gönderim sonucunu görüntülemek için aşağıdaki komutu çalıştırın:
Gönderim durumu, ConfigMap'in annotations alanında güncellenir.
```
kubectl get configmap  opa-policy-add -o yaml  
```
Komut çıktısında ConfigMap'i inceleyin:
- Gönderim başarılıysa, ConfigMap'te aşağıdaki bilgileri görürsünüz.
```
openpolicyagent.org/policy-status: '{"status":"ok"}'
```
- Gönderim başarısız olursa, ilgili bir hata iletisi görüntülenir.

Adım 6: OPA ilkesinin dinamik olarak güncellendiğini doğrulayın

Aşağıdaki cURL komutlarını çalıştırın. Sonuçlar, admin rolünün guest1 kullanıcısına atandığını gösterir. Ayrıca, guest1 kullanıcısının /productpage veya /api/v1/products içeren bir URL kullanarak uygulamaya erişim iznine sahip olduğu görülür.

curl -X GET http://{{The IP address of the ingress gateway service}}/productpage --user guest1:password -I

Beklenen çıktı aşağıdaki gibidir:

HTTP/1.1 200 OK

curl -X GET http://{{The IP address of the ingress gateway service}}/api/v1/products --user guest1:password -I

Beklenen çıktı aşağıdaki gibidir:

HTTP/1.1 200 OK

OPA ilkesi güncellenmeden önce, guest1 kullanıcısı /productpage içeren bir URL kullanarak uygulamaya erişebilir ancak /api/v1/products içeren bir URL ile erişemez. OPA ilkesi güncellendikten sonra, guest1 kullanıcısı /productpage veya /api/v1/products içeren bir URL kullanarak uygulamaya erişebilir. Bu sonuç, OPA ilkesinin dinamik olarak güncellendiğini gösterir.