Ringkasan kebijakan otorisasi
Tidak seperti aplikasi monolitik yang mungkin berjalan di satu tempat, aplikasi microservice yang didistribusikan secara global melakukan panggilan melintasi batas jaringan. Artinya, lebih banyak titik masuk ke aplikasi Anda, dan lebih banyak peluang untuk serangan berbahaya. Dan karena pod Kubernetes memiliki IP sementara, aturan firewall berbasis IP tradisional tidak memadai untuk mengamankan akses antara beban kerja. Dalam arsitektur microservice, pendekatan keamanan baru diperlukan. Dengan memanfaatkan fitur keamanan seperti akun layanan Kubernetes dan kebijakan keamanan Istio, Anthos Service Mesh memberikan kemampuan lebih banyak untuk membantu Anda mengamankan aplikasi Anda.
Halaman ini memberi operator aplikasi ringkasan tentang resource kustom (CR)
AuthorizationPolicy
. Kebijakan otorisasi memungkinkan Anda mengaktifkan kontrol akses pada
beban kerja pada lapisan aplikasi (L7) dan transpor (L3/4). Anda mengonfigurasi kebijakan otorisasi untuk menentukan izin—apa yang boleh dilakukan oleh layanan atau pengguna ini?
Kebijakan otorisasi
Permintaan antarlayanan di mesh Anda (serta antara pengguna akhir dan layanan) diizinkan secara default. Anda menggunakan CR AuthorizationPolicy
untuk menentukan kebijakan terperinci terkait workload Anda. Setelah Anda menerapkan kebijakan otorisasi, Anthos Service Mesh mendistribusikannya ke proxy file bantuan. Saat permintaan masuk ke
beban kerja, proxy file bantuan memeriksa kebijakan otorisasi untuk menentukan apakah
permintaan harus diizinkan atau ditolak.
Cakupan kebijakan
Anda dapat menerapkan kebijakan ke seluruh mesh layanan, ke namespace, atau beban kerja individual.
Untuk menerapkan kebijakan seluruh mesh, tentukan namespace root,
istio-system
, di kolommetadata:namespace
:apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "mesh-wide" namespace: istio-system spec: ...
Untuk menerapkan kebijakan ke namespace, tentukan namespace di kolom
metadata:namespace
:apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "currencyservice" namespace: currencyservice spec: ...
Untuk membatasi kebijakan pada beban kerja tertentu, sertakan kolom
selector
.apiVersion: "security.istio.io/v1beta1" kind: "AuthorizationPolicy" metadata: name: "frontend" namespace: demo spec: selector: matchLabels: app: frontend ...
Struktur dasar
Kebijakan otorisasi mencakup cakupan kebijakan, action
, dan daftar
rules
:
Seperti yang dijelaskan di bagian sebelumnya, cakupan kebijakan dapat berupa seluruh mesh, namespace, atau beban kerja tertentu. Jika Anda menyertakannya, kolom
selector
akan menentukan target kebijakan.Kolom
action
menentukan apakah permintaan akanALLOW
atauDENY
. Jika Anda tidak menentukan tindakan, tindakan akan ditetapkan keALLOW
secara default. Agar lebih jelas, sebaiknya selalu tentukan tindakan. (Kebijakan otorisasi juga mendukung tindakanAUDIT
danCUSTOM
.)rules
menetapkan waktu untuk memicu tindakan.Kolom
from
dirules
menentukan sumber permintaan.Kolom
to
dirules
menentukan operations permintaan.Kolom
when
menentukan conditions tambahan yang diperlukan untuk menerapkan aturan.
Dalam contoh berikut:
Kebijakan ini diterapkan untuk permintaan ke layanan
frontend
dalam namespacedemo
.Permintaan diizinkan jika "hello:world" ada di header permintaan; jika tidak, permintaan akan ditolak.
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: "hello-world"
namespace: demo
spec:
selector:
matchLabels:
app: frontend
action: ALLOW
rules:
- when:
- key: request.headers[hello]
values: ["world"]
Kontrol akses pada operasi permintaan
Anda dapat mengontrol akses ke operations permintaan tertentu seperti metode HTTP atau port TCP dengan menambahkan bagian to
pada rules
.
Pada contoh berikut, hanya metode HTTP GET
dan POST
yang diizinkan
ke currencyservice
dalam namespace demo
.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: currencyservice
namespace: demo
spec:
selector:
matchLabels:
app: currencyservice
action: ALLOW
rules:
- to:
- operation:
methods: ["GET", "POST"]
Kontrol akses pada identitas terautentikasi
Pada contoh sebelumnya, kebijakan tersebut mengizinkan permintaan dari beban kerja yang tidak diautentikasi. Jika mengaktifkan
STRICT
TLS bersama (mTLS),
Anda dapat membatasi akses berdasarkan identitas beban kerja atau namespace tempat
permintaan berasal di bagian
source
.
Gunakan kolom
principals
ataunotPrincipal
untuk mengontrol akses di tingkat beban kerja.Gunakan kolom
namespaces
ataunotNamespaces
untuk mengontrol akses di tingkat namespace.
Semua kolom di atas mewajibkan Anda mengaktifkan STRICT
mTLS. Jika Anda
tidak dapat menetapkan mTLS STRICT
, lihat
Menolak permintaan teks biasa untuk solusi
alternatif.
Beban kerja yang teridentifikasi
Pada contoh berikut, permintaan ke currencyservice
hanya diizinkan
dari layanan frontend
. Permintaan ke currencyservice
dari beban kerja
lain ditolak.
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
name: "currencyservice"
namespace: demo
spec:
selector:
matchLabels:
app: currencyservice
action: ALLOW
rules:
- from:
- source:
principals: ["example-project-1234.svc.id.goog/ns/demo/sa/frontend-sa"]
Untuk menentukan akun layanan, principals
untuk
certificate authority Anthos Service Mesh (Mesh CA)
dan Certificate Authority Service
(CA Service) harus dalam format berikut:
principals: ["PROJECT_ID.svc.id.goog/ns/NAMESPACE/sa/SERVICE_ACCOUNT_NAME"]
PROJECT_ID.svc.id.goog
adalah
domain kepercayaan untuk Mesh CA. Jika Anda menggunakan Istio CA (sebelumnya dikenal sebagai Citadel), domain kepercayaan default adalah cluster.local
.
Namespace teridentifikasi
Contoh berikut menunjukkan kebijakan yang menolak permintaan jika sumbernya bukan
namespace foo
:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin-deny
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
version: v1
action: DENY
rules:
- from:
- source:
notNamespaces: ["foo"]
Pencocokan nilai
Sebagian besar kolom dalam kebijakan otorisasi mendukung semua skema pencocokan berikut:
- Pencocokan persis: pencocokan string persis.
- Pencocokan karakter pengganti menggunakan karakter pengganti
"*"
:- Pencocokan awalan: string dengan akhiran
"*"
. Misalnya,"test.example.*"
cocok dengan"test.example.com"
atau"test.example.com.cn"
. - Pencocokan akhiran: string dengan
"*"
awal. Misalnya,"*.example.com"
cocok dengan"eng.example.com"
atau"test.eng.example.com"
.
- Pencocokan awalan: string dengan akhiran
- Pencocokan kehadiran: Untuk menentukan bahwa kolom harus ada dan tidak kosong, gunakan
format
fieldname: ["*"]
. Hal ini berbeda dengan membiarkan kolom tidak ditentukan, yang berarti mencocokkan apa pun, termasuk kosong.
Ada beberapa pengecualian. Misalnya, kolom berikut hanya mendukung pencocokan persis:
- Kolom
key
di bagianwhen
ipBlocks
di bagiansource
- Kolom
ports
di bagianto
Contoh kebijakan berikut mengizinkan akses di jalur dengan awalan /test/*
atau akhiran */info
:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: tester
namespace: default
spec:
selector:
matchLabels:
app: products
action: ALLOW
rules:
- to:
- operation:
paths: ["/test/*", "*/info"]
Pencocokan pengecualian
Untuk mencocokkan kondisi negatif seperti notValues
di kolom when
, notIpBlocks
di kolom source
, notPorts
di kolom to
, Anthos Service Mesh mendukung pencocokan pengecualian. Contoh berikut memerlukan permintaan principals
yang valid, yang berasal dari autentikasi JWT, jika jalur permintaan
bukan /healthz
. Dengan demikian, kebijakan ini akan mengecualikan permintaan ke jalur /healthz
dari autentikasi JWT:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: disable-jwt-for-healthz
namespace: default
spec:
selector:
matchLabels:
app: products
action: ALLOW
rules:
- to:
- operation:
notPaths: ["/healthz"]
from:
- source:
requestPrincipals: ["*"]
Menolak permintaan teks biasa
Di Anthos Service Mesh 1.5 dan yang lebih baru, mTLS otomatis diaktifkan secara default. Dengan auto mTLS, proxy file bantuan klien otomatis mendeteksi apakah server memiliki file bantuan. Sidecar klien mengirimkan mTLS ke workload dengan sidecar dan mengirim teks biasa ke workload tanpa sidecar. Untuk keamanan terbaik, sebaiknya Anda mengaktifkan STRICT mTLS.
Jika tidak dapat mengaktifkan mTLS dengan mode STRICT
untuk beban kerja atau
namespace, Anda dapat:
- membuat kebijakan otorisasi untuk secara eksplisit mengizinkan traffic dengan
namespaces
yang tidak kosong atauprincipals
yang tidak kosong, atau - menolak traffic dengan
namespaces
atauprincipals
kosong.
Karena namespaces
dan principals
hanya dapat diekstrak dengan permintaan mTLS, kebijakan ini secara efektif menolak traffic teks biasa apa pun.
Kebijakan berikut menolak permintaan jika akun utama dalam permintaan
kosong (yang berlaku untuk permintaan teks biasa). Kebijakan ini mengizinkan
permintaan jika akun utama tidak kosong. ["*"]
berarti pencocokan tidak kosong, dan
menggunakan notPrincipals
berarti mencocokkan pada akun utama yang kosong.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: require-mtls
namespace: NAMESPACE
spec:
action: DENY
rules:
- from:
- source:
notPrincipals: ["*"]
Prioritas kebijakan otorisasi
Anda dapat mengonfigurasi kebijakan otorisasi ALLOW
dan DENY
yang terpisah, tetapi Anda
perlu memahami prioritas kebijakan dan perilaku default untuk memastikan
kebijakan tersebut melakukan hal yang Anda inginkan. Diagram berikut menjelaskan prioritas
kebijakan.
Contoh kebijakan di bagian berikut ini menggambarkan beberapa perilaku default dan situasi yang mungkin bermanfaat bagi Anda.
Jangan izinkan
Contoh berikut menunjukkan kebijakan ALLOW
yang tidak cocok dengan apa pun. Secara
default, jika tidak ada kebijakan ALLOW
lain, permintaan akan selalu ditolak.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
spec:
action: ALLOW
Praktik keamanan yang baik adalah memulai dengan kebijakan izinkan tidak ada dan
menambahkan lebih banyak kebijakan ALLOW
secara bertahap untuk membuka lebih banyak akses ke beban kerja.
Tolak semua akses
Contoh berikut menunjukkan kebijakan DENY
yang cocok dengan semuanya. Karena
kebijakan DENY
dievaluasi sebelum kebijakan ALLOW
, semua permintaan akan ditolak
meskipun ada kebijakan ALLOW
yang cocok dengan permintaan tersebut.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-all
spec:
action: DENY
rules:
- {}
Kebijakan tolak semua berguna jika Anda ingin menonaktifkan sementara semua akses ke beban kerja.
Izinkan semua akses
Contoh berikut menunjukkan kebijakan ALLOW
yang cocok dengan semuanya, dan
memungkinkan akses penuh ke beban kerja. Kebijakan izinkan semua membuat kebijakan ALLOW
lainnya tidak berguna karena selalu mengizinkan permintaan.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-all
spec:
action: ALLOW
rules:
- {}
Kebijakan izinkan semua berguna jika Anda ingin mengekspos akses penuh untuk sementara ke beban kerja. Jika ada kebijakan DENY
, permintaan tetap dapat ditolak karena kebijakan DENY
dievaluasi sebelum kebijakan ALLOW
.
Praktik terbaik
Buat akun layanan Kubernetes untuk setiap layanan, dan tentukan akun layanan di Deployment. Contoh:
apiVersion: v1 kind: ServiceAccount metadata: name: frontend-sa namespace: demo --- apiVersion: apps/v1 kind: Deployment metadata: name: frontend namespace:demo spec: selector: matchLabels: app: frontend template: metadata: labels: app: frontend spec: serviceAccountName: frontend-sa ...
Mulai dengan kebijakan izinkan tidak ada dan tambahkan lebih banyak kebijakan
ALLOW
secara bertahap untuk membuka lebih banyak akses ke workload.Jika Anda menggunakan JWT untuk layanan Anda:
Buat kebijakan
DENY
untuk memblokir permintaan yang tidak diautentikasi, misalnya:apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: requireJWT namespace: admin spec: action: DENY rules: - from: - source: notRequestPrincipals: ["*"]
Terapkan kebijakan izinkan tidak ada.
Tentukan kebijakan
ALLOW
untuk setiap beban kerja. Untuk mengetahui contohnya, lihat Token JWT.
Langkah selanjutnya
Pelajari fitur keamanan Anthos Service Mesh lebih lanjut:
- Mengonfigurasi autentikasi pengguna Anthos Service Mesh
- Mengonfigurasi kebijakan audit untuk layanan Anda
- Mengonfigurasi keamanan transpor
- Mengintegrasikan Identity-Aware Proxy dengan Anthos Service Mesh
- Praktik Terbaik untuk menggunakan gateway traffic keluar Anthos Service Mesh di cluster GKE
Pelajari lebih lanjut kebijakan otorisasi dari dokumentasi Istio: