Alibaba Cloud Service Mesh:Sıfır güven güvenliğine genel bakış

Arka plan

Mikroservisler; ölçeklenebilirlik, esneklik, bağımsız ölçeklendirme, iş mantığı izolasyonu, bağımsız yaşam döngüsü yönetimi ve basitleştirilmiş dağıtık geliştirme gibi birçok avantaj sağlar. Ancak bu dağıtık mimari, her mikroservisin potansiyel bir saldırı hedefi haline gelmesi nedeniyle güvenlik zorluklarını da beraberinde getirir. Kubernetes, mikroservisleri barındırmak ve düzenlemek için mükemmel bir platform sunar. Bununla birlikte, varsayılan olarak mikroservisler arasındaki tüm iletişim güvensizdir. Mikroservisler düz metin HTTP üzerinden iletişim kurar; bu durum modern güvenlik gereksinimleri için yetersizdir. Güvenlik için yalnızca ağ çevresine güvenmek yeterli değildir. Dahili bir hizmet ele geçirilirse, saldırgan ağ içindeki diğer hizmetlere saldırmak için yatay hareket edebilir. Bu nedenle, dahili trafiğin de güvenli hale getirilmesi gerekir. İşte sıfır güven güvenliğinin değeri burada ortaya çıkar. Sıfır güven modeli, her istek için açık doğrulama gerektirir ve kaynaklara erişimi kısıtlamak için en az ayrıcalık ilkesini uygular.

Service Mesh teknolojisinin temel faydalarından biri, geliştirici verimliliğini azaltmadan üretim ortamlarını güvence altına alabilmesidir. Service Mesh , mikroservisler için sıfır güven güvenlik yaklaşımını benimsemek için temel oluşturur. Bu yaklaşım, güçlü kimlik doğrulama, bağlam farkındalıklı yetkilendirme ve tüm erişimler için kapsamlı günlük kaydı ve izleme gibi güvenlik hedeflerine ulaşmanıza yardımcı olur. Bu ağ özelliklerini kullanarak, ağ içindeki tüm uygulamalara güvenlik kontrolleri uygulayabilirsiniz. Örneğin, tüm trafiğin şifrelenmesini ve uygulamalara gelen tüm trafiğin bir ilke uygulama noktası (PEP) tarafından doğrulanmasını sağlayabilirsiniz.

Katman 3 güvenliği için Kubernetes ağ ilkelerine ek olarak, ASM eş kimlik doğrulama, istek kimlik doğrulama, Istio yetkilendirme ilkeleri ve ayrıntılı OPA ilkeleri sağlar. ASM'deki bu sıfır güven güvenlik yetenekleri, güvenlik hedeflerinize ulaşmanıza yardımcı olur.

Sıfır güveni uygulamak için neden ASM kullanmalısınız?

ASM ile tek bir kontrol düzlemi kullanarak güçlü kimlik ve erişim yönetimi, şeffaf TLS şifrelemesi, kimlik doğrulama, yetkilendirme ve denetim günlüğü uygulayabilirsiniz. Basit kurulumu ve yönetimi sayesinde geliştiriciler, sistem yöneticileri ve güvenlik ekipleri mikroservis uygulamalarını koruyabilir.

ASM'nin sıfır güven sisteminin kullanılması

ASM, cloud-native ortamlardaki saldırı yüzeyini azaltır ve sıfır güven uygulama ağı için temel çerçeveyi sağlar. Hizmetten hizmete güvenliği yöneterek ASM, uçtan uca şifreleme, hizmet düzeyinde kimlik doğrulama ve ayrıntılı yetkilendirme ilkeleri sağlar.

ASM, iş yükü kimliği, eş kimlik doğrulama, istek kimlik doğrulama, yetkilendirme ilkeleri ve OPA ilkeleri dahil olmak üzere temel sıfır güven güvenlik yetenekleri sağlar.

İş yükü kimliği

Bir uygulama ASM ortamında çalıştığında, ASM her hizmet için benzersiz bir kimlik sağlar. Bu hizmet kimliği, hizmetler arasındaki erişimi doğrulamak için karşılıklı kimlik doğrulamada ve yetkilendirme ilkelerinde kullanılabilir.

Kubernetes üzerinde çalışan iş yüklerini yönetmek için ASM'yi kullandığınızda, ASM her iş yükü için bir hizmet kimliği sağlar. Bu kimlik, iş yükünün hizmet hesabı belirtecine dayanır.

ASM'deki hizmet kimlikleri SPIFFE standardına uygundur ve şu biçimi kullanır: spiffe://<trust-domain>/ns/<namespace>/sa/<service-account>.

Bir Kubernetes kümesinden bağlı olan hizmetleri görüntülemek için ASM konsolunda oturum açabilirsiniz.

1. ASM konsolunda oturum açın. Sol gezinme bölmesinde Service Mesh > Mesh Management seçeneklerini seçin.

2. Mesh Management sayfasında, ASM örneğinin adını tıklayın. Sol gezinme bölmesinde Mesh Security Center > Workload Identity seçeneklerini seçin.

3. Workload Identity sayfasında, Data Plane ayarını küme kimliğine yapın ve hizmet ağına eklenen Kubernetes kümesindeki hizmetler için iş yükü kimliklerini görüntülemek üzere bir Namespaces seçin.

Eş kimlik doğrulama

ASM iki tür kimlik doğrulama sağlar: eş kimlik doğrulama ve istek kimlik doğrulama. Eş kimlik doğrulama, iki mikroservis etkileşime girdiğinde eşleri doğrulamak için karşılıklı TLS kullanır.

• Hem istemci hem de sunucuda sidecar proxy enjekte edilmişse, ASM'de mTLS iletişimi varsayılan olarak etkindir.

• Yalnızca istemcide sidecar proxy enjekte edilmişse, istemci sunucunun yapılandırmasına göre mTLS iletişimini kullanıp kullanmamaya karar verir.

• Yalnızca sunucuda sidecar proxy enjekte edilmişse, varsayılan mTLS modu PERMISSIVE'dir; bu mod hem düz metin hem de şifrelenmiş trafiği kabul eder. Sunucu için bir PeerAuthentication ilkesi yapılandırır ve mTLS modunu STRICT olarak ayarlarsanız, istekler başarısız olur.

İstek kimlik doğrulama

İstek kimlik doğrulama, son kullanıcıların ve sistemlerin mikroservislerle etkileşime girmesine olanak tanır. Bu işlem genellikle JSON Web Token (JWT) kullanılarak yapılır.

Bir mikroservis istendiğinde, gelen isteklerde JWT doğrulaması yapmak için bir istek kimlik doğrulama ilkesi oluşturabilirsiniz. İlke, JWT içeren istekleri doğrular. Yalnızca geçerli bir JWT'ye sahip istekler hizmete başarıyla erişebilir. JWT içermeyen istekler doğrulanmaz ve hizmeti kısıtlama olmaksızın erişebilir.

1. İstek alacak bookinfo uygulamasını dağıtın. Daha fazla bilgi için bkz. ASM örneğiyle ilişkili bir kümede uygulama dağıtma.

2. İstek gönderecek sleep uygulamasını dağıtın.

   1. ACK kümeniz için KubeConfig ortamında bir sleep.yaml dosyası oluşturun.

      Sleep.yaml dosyası

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: sleep
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: sleep
        labels:
          app: sleep
          service: sleep
      spec:
        ports:
        - port: 80
          name: http
        selector:
          app: sleep
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: sleep
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: sleep
        template:
          metadata:
            labels:
              app: sleep
          spec:
            terminationGracePeriodSeconds: 0
            serviceAccountName: sleep
            containers:
            - name: sleep
              image: curlimages/curl
              command: ["/bin/sleep", "3650d"]
              imagePullPolicy: IfNotPresent
              volumeMounts:
              - mountPath: /etc/sleep/tls
                name: secret-volume
            volumes:
            - name: secret-volume
              secret:
                secretName: sleep-secret
                optional: true
      ---

   2. Sleep uygulamasını dağıtmak için aşağıdaki komutu çalıştırın.

      kubectl apply -f sleep.yaml -n default 

3. details hizmetine gelen istekler için JWT kimlik doğrulamasını zorunlu kılmak amacıyla bir istek kimlik doğrulama ilkesi oluşturun.

   1. ASM konsolunda oturum açın. Sol gezinme bölmesinde Service Mesh > Mesh Management seçeneklerini seçin.

   2. Mesh Management sayfasında, ASM örneğinin adını tıklayın. Sol gezinme bölmesinde Mesh Security Center > RequestAuthentication seçeneklerini seçin. Açılan sayfada Create seçeneğini tıklayın.

   3. Oluşturma sayfasında aşağıdaki parametreleri ayarlayın ve ardından details iş yükü için bir JWT kuralı tanımlamak üzere Create seçeneğini tıklayın.

      default ad alanını seçin, adı test olarak ayarlayın ve adı app, değeri details olan bir etiket seçici ekleyin.

      Aşağıda bazı parametreler açıklanmaktadır:

      • issuer: JWT'nin yayıncısı. Bu örnek için bunu testing@secure.istio.io olarak ayarlayın.

      • audiences: JWT için hedef kitle listesi. Bu, hangi hizmetlerin JWT'yi kullanarak hedef hizmete erişebileceğini belirtir. Bu örnek için boş bırakın; bu, erişimin belirli bir hizmetle kısıtlanmadığı anlamına gelir.

      • jwks: JWT için JSON Web Anahtar Kümesi (JWKS). Bu örnek için aşağıdaki JWKS'yi kullanın. Daha fazla bilgi için bkz. jwks.json.

        { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

4. Sonraki adımda kullanılacak belirteci oluşturmak için bir JWT aracı kullanabilirsiniz. Belirteç, JWKS'deki genel anahtara karşılık gelen bir özel anahtar kullanılarak oluşturulmalı ve testing@secure.istio.io yayıncısını içermelidir.

   { "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}

   Beklenen belirteç şöyledir:

   eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3UcMI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg

5. İstek kimlik doğrulama ilkesinin etkili olduğunu doğrulayın.

   1. Kodlanmış JWT'yi kullanarak details hizmetine erişmek için aşağıdaki komutu çalıştırın.

      export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3UcMI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg
      kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n'        

      Başarılı erişimi gösteren 200 durum kodu döndürülür.

   2. Geçersiz bir JWT kullanarak details hizmetine erişmek için aşağıdaki komutu çalıştırın.

      kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n'                              

      Erişimin başarısız olduğunu gösteren 403 durum kodu döndürülür.

   3. JWT olmadan details hizmetine erişmek için aşağıdaki komutu çalıştırın.

      kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'

      Başarılı erişimi gösteren 200 durum kodu döndürülür.

      Bu sonuçlar, geçerli JWT'ye sahip isteklerin başarılı olduğunu, geçersiz JWT'ye sahip isteklerin başarısız olduğunu ve JWT içermeyen isteklerin başarılı olduğunu gösterir. Bu durum, istek kimlik doğrulama ilkesinin beklendiği gibi çalıştığını doğrular.

Yetkilendirme ilkesi

Bir mikroservis istendiğinde, isteğin bağlantı noktasına, IP adresine, kaynağına ve daha fazlasına göre erişimi kısıtlamak için bir yetkilendirme ilkesi kullanabilirsiniz. Yalnızca gereksinimleri karşılayan istekler hizmete erişebilir. Aşağıdaki yetkilendirme ilkesi, isteğin belirli bir yayıncıdan gelen bir JWT içermesini zorunlu kılarak erişimi istek kaynağına göre kısıtlar.

1. İstek alacak bookinfo uygulamasını dağıtın. Daha fazla bilgi için bkz. ASM örneğiyle ilişkili bir kümede uygulama dağıtma.

2. İstek gönderecek sleep uygulamasını dağıtın.

   1. Aşağıdaki içeriğe sahip bir sleep.yaml dosyası oluşturun.

      Sleep.yaml dosyası

      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: sleep
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: sleep
        labels:
          app: sleep
          service: sleep
      spec:
        ports:
        - port: 80
          name: http
        selector:
          app: sleep
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: sleep
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: sleep
        template:
          metadata:
            labels:
              app: sleep
          spec:
            terminationGracePeriodSeconds: 0
            serviceAccountName: sleep
            containers:
            - name: sleep
              image: curlimages/curl
              command: ["/bin/sleep", "3650d"]
              imagePullPolicy: IfNotPresent
              volumeMounts:
              - mountPath: /etc/sleep/tls
                name: secret-volume
            volumes:
            - name: secret-volume
              secret:
                secretName: sleep-secret
                optional: true
      ---

   2. ACK kümeniz için KubeConfig ortamında, sleep uygulamasını dağıtmak için aşağıdaki komutu çalıştırın.

      kubectl apply -f sleep.yaml -n default 

3. Bir yetkilendirme ilkesi oluşturun.

   1. ASM konsolunda oturum açın. Sol gezinme bölmesinde Service Mesh > Mesh Management seçeneklerini seçin.

   2. Mesh Management sayfasında, ASM örneğinin adını tıklayın. Sol gezinme bölmesinde Mesh Security Center > AuthorizationPolicy seçeneklerini seçin. Açılan sayfada Create from YAML seçeneğini tıklayın.

4. Create sayfasında default ad alanını seçin, aşağıdaki YAML'yi girin ve ardından Create seçeneğini tıklayın.

   Alanlar hakkında daha fazla bilgi için bkz. Yetkilendirme İlkesi.

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: require-jwt
     namespace: default
   spec:
     action: ALLOW
     rules:
       - from:
           - source:
               requestPrincipals:
                 - testing@secure.istio.io/testing@secure.istio.io
     selector:
       matchLabels:
         app: details

5. Hizmete erişmek için JWT içermeyen bir istek göndermek amacıyla aşağıdaki komutu çalıştırın.

    kubectl exec $(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- curl http://details:9080/details/1 -o /dev/null  -s -w '%{http_code}\n'

   Beklenen çıktı:

   403

   JWT içermeyen details hizmetine yapılan istek başarısız olur; bu durum, yetkilendirme ilkesinin etkili olduğunu doğrular. İlke, hizmete başarıyla erişmek için tüm isteklerin testing@secure.istio.io tarafından yayınlanan bir JWT içermesini gerektirir.

OPA ilkesi

OPA, uygulamalarınız için ayrıntılı erişim denetimi sağlayan bir ilke motorudur. Genel amaçlı bir ilke motoru olarak OPA, mikroservislerinizin yanında bağımsız bir hizmet olarak dağıtılabilir. Bir uygulamayı korumak için, mikroservise yapılan her isteğin işlenmeden önce yetkilendirilmesi gerekir. Mikroservis, isteğin izin verilip verilmeyeceğini belirlemek için OPA API'sini sorgular. Daha fazla bilgi için bkz. OPA.

ASM, bir OPA eklentisini entegre eder; bu sayede uygulamalarınız için ayrıntılı erişim denetimi elde etmek amacıyla OPA kullanarak erişim denetimi ilkeleri tanımlayabilirsiniz. Bu OPA ilkeleri dinamik olarak da güncellenebilir. Daha fazla bilgi için bkz. ASM'de OPA ilkelerini dinamik olarak güncelleme.

Özet ve kullanım senaryoları

Özetle, ASM aşağıdaki güvenliği artıran bileşenleri sağlar:

• Sertifika yayınlamayı ve CA rotasyonunu basitleştiren, tam sertifika yaşam döngüsü yönetimine sahip yönetilen bir sertifika altyapısı.

• Kimlik doğrulama ilkelerini, yetkilendirme ilkelerini ve güvenli adlandırma bilgilerini Envoy proxy'lere dağıtmak için yönetilen kontrol düzlemi API'leri.

• Ağı güvence altına almaya yardımcı olmak için ilke uygulama noktası (PEP) olarak görev yapan sidecar proxy'ler.

• Telemetri toplama ve denetim olanağı sağlayan Envoy proxy uzantıları.

Her iş yükü, kimliğini belirlemek için bir X.509 TLS sertifikası kullanır. Bu sertifika daha sonra iş yükünün sidecar proxy'si tarafından kullanılır. ASM bu sertifikaları ve özel anahtarları sağlar ve periyodik olarak rotasyona tabi tutar. Özel bir anahtar ele geçirilirse, ASM onu hızla yeni bir anahtarla değiştirebilir; bu da saldırı yüzeyini önemli ölçüde azaltır.

Kullanım senaryoları

• IP tabanlı erişim denetimi veya özel bir dış yetkilendiriciye dayalı erişim denetimi uygulamak için bir giriş ağ geçidinde yetkilendirme ilkesi kullanın.

• Bir internet finansmanı müşterisi, kümeler arası çok dilli uygulamalar için erişim izinlerini yönetmek zorundaydı. Hariciye açık bölgeleri dahili uygulama bölgelerinden izole etmek için ASM yetkilendirme ilkelerini kullandılar. Ağ trafiğini denetlemek için bir çıkış ağ geçidiyle birlikte, uygulamaların üçüncü taraf hizmetlere erişimini kontrol etmek için de yetkilendirme ilkelerini kullandılar.