Keamanan gambar - Amazon EKS
RekomendasiAlat dan sumber daya

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Keamanan gambar

Anda harus mempertimbangkan gambar kontainer sebagai garis pertahanan pertama Anda terhadap serangan. Gambar yang tidak aman dan dibangun dengan buruk dapat memungkinkan penyerang melarikan diri dari batas-batas wadah dan mendapatkan akses ke host. Setelah berada di host, penyerang dapat memperoleh akses ke informasi sensitif atau bergerak secara lateral di dalam cluster atau dengan akun AWS Anda. Praktik terbaik berikut akan membantu mengurangi risiko terjadinya hal ini.

Rekomendasi

Buat gambar minimal

Mulailah dengan menghapus semua binari asing dari gambar kontainer. Jika Anda menggunakan gambar yang tidak dikenal dari Dockerhub, periksa gambar menggunakan aplikasi seperti Dive yang dapat menampilkan konten dari setiap lapisan wadah. Hapus semua binari dengan bit SETUID dan SETGID karena dapat digunakan untuk meningkatkan hak istimewa dan pertimbangkan untuk menghapus semua shell dan utilitas seperti nc dan curl yang dapat digunakan untuk tujuan jahat. Anda dapat menemukan file dengan bit SETUID dan SETGID dengan perintah berikut:

find / -perm /6000 -type f -exec ls -ld {} \;

Untuk menghapus izin khusus dari file-file ini, tambahkan direktif berikut ke gambar kontainer Anda:

RUN find / -xdev -perm /6000 -type f -exec chmod a-s {} \; || true

Dalam bahasa sehari-hari, ini dikenal sebagai de-fanging your image.

Gunakan build multi-tahap

Menggunakan build multi-tahap adalah cara untuk membuat gambar minimal. Seringkali, build multi-tahap digunakan untuk mengotomatiskan bagian-bagian dari siklus Integrasi Berkelanjutan. Misalnya, build multi-tahap dapat digunakan untuk lint kode sumber Anda atau melakukan analisis kode statis. Ini memberi pengembang kesempatan untuk mendapatkan umpan balik langsung daripada menunggu pipeline untuk dijalankan. Build multi-tahap menarik dari sudut pandang keamanan karena memungkinkan Anda meminimalkan ukuran gambar akhir yang didorong ke registri kontainer Anda. Gambar kontainer tanpa alat build dan binari asing lainnya meningkatkan postur keamanan Anda dengan mengurangi permukaan serangan gambar. Untuk informasi tambahan tentang build multi-tahap, lihat dokumentasi build multi-tahap Docker.

Buat Software Bill of Materials (SBOMs) untuk gambar kontainer Anda

Sebuah “software bill of materials” (SBOM) adalah inventaris bersarang dari artefak perangkat lunak yang membentuk gambar kontainer Anda. SBOM adalah blok bangunan utama dalam keamanan perangkat lunak dan manajemen risiko rantai pasokan perangkat lunak. Menghasilkan, menyimpan SBOMS di repositori pusat dan memindai SBOMs kerentanan membantu mengatasi masalah berikut:

  • Visibilitas: pahami komponen apa yang membentuk gambar kontainer Anda. Menyimpan di repositori pusat memungkinkan SBOMs untuk diaudit dan dipindai kapan saja, bahkan pasca penyebaran untuk mendeteksi dan menanggapi kerentanan baru seperti kerentanan nol hari.

  • Verifikasi Asal: jaminan bahwa asumsi yang ada tentang di mana dan bagaimana artefak berasal adalah benar dan bahwa artefak atau metadata yang menyertainya belum dirusak selama proses pembuatan atau pengiriman.

  • Kepercayaan: jaminan bahwa artefak tertentu dan isinya dapat dipercaya untuk melakukan apa yang seharusnya dilakukan, yaitu cocok untuk suatu tujuan. Ini melibatkan penilaian apakah kode tersebut aman untuk dieksekusi dan membuat keputusan berdasarkan informasi tentang risiko yang terkait dengan pelaksanaan kode. Kepercayaan terjamin dengan membuat laporan eksekusi pipa yang dibuktikan bersama dengan SBOM yang telah dibuktikan dan laporan pemindaian CVE yang dibuktikan untuk meyakinkan konsumen gambar bahwa gambar ini sebenarnya dibuat melalui sarana aman (pipeline) dengan komponen yang aman.

  • Verifikasi Kepercayaan Ketergantungan: pemeriksaan rekursif pohon ketergantungan artefak untuk kepercayaan dan asal artefak yang digunakannya. Drift in SBOMs dapat membantu mendeteksi aktivitas berbahaya termasuk dependensi yang tidak sah, tidak tepercaya, upaya infiltrasi.

Alat-alat berikut dapat digunakan untuk menghasilkan SBOM:

  • Amazon Inspector dapat digunakan untuk membuat dan mengekspor. SBOMs

  • Syft dari Anchore juga dapat digunakan untuk generasi SBOM. Untuk pemindaian kerentanan yang lebih cepat, SBOM yang dihasilkan untuk gambar kontainer dapat digunakan sebagai input untuk memindai. Laporan SBOM dan pemindaian kemudian dibuktikan dan dilampirkan pada gambar sebelum mendorong gambar ke repositori OCI pusat seperti Amazon ECR untuk tujuan peninjauan dan audit.

Pelajari lebih lanjut tentang mengamankan rantai pasokan perangkat lunak Anda dengan meninjau panduan Praktik Terbaik Rantai Pasokan Perangkat Lunak CNCF.

Pindai gambar untuk kerentanan secara teratur

Seperti rekan-rekan mesin virtual mereka, gambar kontainer dapat berisi binari dan pustaka aplikasi dengan kerentanan atau mengembangkan kerentanan dari waktu ke waktu. Cara terbaik untuk melindungi terhadap eksploitasi adalah dengan memindai gambar Anda secara teratur dengan pemindai gambar. Gambar yang disimpan di Amazon ECR dapat dipindai saat push atau on-demand (sekali selama periode 24 jam). ECR saat ini mendukung dua jenis pemindaian - Basic dan Enhanced. Pemindaian dasar memanfaatkan Clair solusi pemindaian gambar open source tanpa biaya. Pemindaian yang disempurnakan menggunakan Amazon Inspector untuk menyediakan pemindaian berkelanjutan otomatis dengan biaya tambahan. Setelah gambar dipindai, hasilnya dicatat ke aliran acara untuk ECR di. EventBridge Anda juga dapat melihat hasil pemindaian dari dalam konsol ECR. Gambar dengan kerentanan TINGGI atau KRITIS harus dihapus atau dibangun kembali. Jika gambar yang telah digunakan mengembangkan kerentanan, itu harus diganti sesegera mungkin.

Mengetahui di mana gambar dengan kerentanan telah digunakan sangat penting untuk menjaga lingkungan Anda tetap aman. Meskipun Anda dapat membuat sendiri solusi pelacakan gambar, sudah ada beberapa penawaran komersial yang menyediakan ini dan kemampuan canggih lainnya di luar kotak, termasuk:

Webhook validasi Kubernetes juga dapat digunakan untuk memvalidasi bahwa gambar bebas dari kerentanan kritis. Webhook validasi dipanggil sebelum API Kubernetes. Mereka biasanya digunakan untuk menolak permintaan yang tidak sesuai dengan kriteria validasi yang ditentukan dalam webhook. Ini adalah contoh webhook tanpa server yang memanggil API describeImageScan Temuan ECR untuk menentukan apakah sebuah pod menarik gambar dengan kerentanan kritis. Jika kerentanan ditemukan, pod ditolak dan pesan dengan daftar CVEs dikembalikan sebagai Event.

Gunakan pengesahan untuk memvalidasi integritas artefak

Pengesahan adalah “pernyataan” yang ditandatangani secara kriptografis yang mengklaim sesuatu - “predikat” misalnya pipeline run atau SBOM atau laporan pemindaian kerentanan benar tentang hal lain - “subjek” yaitu gambar wadah.

Pengesahan membantu pengguna untuk memvalidasi bahwa artefak berasal dari sumber tepercaya dalam rantai pasokan perangkat lunak. Sebagai contoh, kita dapat menggunakan gambar kontainer tanpa mengetahui semua komponen perangkat lunak atau dependensi yang disertakan dalam gambar itu. Namun, jika kita mempercayai apa pun yang dikatakan produsen gambar kontainer tentang perangkat lunak apa yang ada, kita dapat menggunakan pengesahan produsen untuk mengandalkan artefak itu. Ini berarti bahwa kita dapat melanjutkan untuk menggunakan artefak dengan aman di alur kerja kita daripada melakukan analisis sendiri.

Buat kebijakan IAM untuk repositori ECR

Saat ini, tidak jarang sebuah organisasi memiliki beberapa tim pengembangan yang beroperasi secara independen dalam akun AWS bersama. Jika tim ini tidak perlu berbagi aset, Anda mungkin ingin membuat serangkaian kebijakan IAM yang membatasi akses ke repositori yang dapat berinteraksi dengan setiap tim. Cara yang baik untuk mengimplementasikan ini adalah dengan menggunakan ruang nama ECR. Ruang nama adalah cara untuk mengelompokkan repositori serupa bersama-sama. Misalnya, semua registrasi untuk tim A dapat diawali dengan tim-a/ sedangkan untuk tim B dapat menggunakan awalan tim-b/. Kebijakan untuk membatasi akses mungkin terlihat seperti berikut:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPushPull",
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability",
        "ecr:PutImage",
        "ecr:InitiateLayerUpload",
        "ecr:UploadLayerPart",
        "ecr:CompleteLayerUpload"
      ],
      "Resource": [
        "arn:aws:ecr:<region>:<account_id>:repository/team-a/*"
      ]
    }
  ]
}

Pertimbangkan untuk menggunakan titik akhir pribadi ECR

ECR API memiliki titik akhir publik. Akibatnya, pendaftar ECR dapat diakses dari Internet selama permintaan tersebut telah diautentikasi dan disahkan oleh IAM. Bagi mereka yang perlu beroperasi di lingkungan kotak pasir di mana VPC cluster tidak memiliki Internet Gateway (IGW), Anda dapat mengonfigurasi titik akhir pribadi untuk ECR. Membuat endpoint pribadi memungkinkan Anda mengakses ECR API secara pribadi melalui alamat IP pribadi alih-alih merutekan lalu lintas di Internet. Untuk informasi tambahan tentang topik ini, lihat Titik akhir VPC antarmuka Amazon ECR.

Menerapkan kebijakan endpoint untuk ECR

Kebijakan endpoint default untuk memungkinkan akses ke semua repositori ECR dalam suatu wilayah. Ini mungkin memungkinkan attacker/insider untuk mengekstrasi data dengan mengemasnya sebagai gambar kontainer dan mendorongnya ke registri di akun AWS lain. Mengurangi risiko ini melibatkan pembuatan kebijakan endpoint yang membatasi akses API ke repositori ECR. Misalnya, kebijakan berikut memungkinkan semua prinsip AWS di akun Anda untuk melakukan semua tindakan terhadap repositori ECR Anda dan hanya Anda:

{
  "Statement": [
    {
      "Sid": "LimitECRAccess",
      "Principal": "*",
      "Action": "*",
      "Effect": "Allow",
      "Resource": "arn:aws:ecr:<region>:<account_id>:repository/*"
    }
  ]
}

Anda dapat menyempurnakannya lebih lanjut dengan menetapkan kondisi yang menggunakan PrincipalOrgID atribut baru yang akan mencegah pushing/pulling gambar dengan prinsip IAM yang bukan bagian dari Organisasi AWS Anda. Lihat, aws: PrincipalOrg ID untuk detail tambahan. Kami merekomendasikan menerapkan kebijakan yang sama untuk kedua titik akhir com.amazonaws.<region>.ecr.dkr dan com.amazonaws.<region>.ecr.api titik akhir. Karena EKS menarik gambar untuk kube-proxy, coredns, dan aws-node dari ECR, Anda perlu menambahkan ID akun registri, misalnya 602401143452.dkr.ecr.us-west-2.amazonaws.com/ ke daftar sumber daya dalam kebijakan titik akhir atau mengubah kebijakan untuk mengizinkan penarikan dari dan membatasi dorongan ke ID akun Anda. Tabel di bawah ini mengungkapkan pemetaan antara akun AWS tempat gambar EKS dijual dan wilayah cluster.

Nomor Rekening Wilayah

602401143452

Semua wilayah komersial kecuali yang tercantum di bawah ini

—

—

800184023465

ap-east-1 - Asia Pasifik (Hong Kong)

558608220178

me-south-1 - Timur Tengah (Bahrain)

918309763551

cn-utara-1 - Tiongkok (Beijing)

961992271922

cn-barat laut-1 - Tiongkok (Ningxia)

Untuk informasi lebih lanjut tentang penggunaan kebijakan titik akhir, lihat Menggunakan kebijakan titik akhir VPC untuk mengontrol akses ECR Amazon.

Menerapkan kebijakan siklus hidup untuk ECR

Panduan Keamanan Kontainer Aplikasi NIST memperingatkan tentang risiko “gambar basi dalam pendaftar”, mencatat bahwa seiring waktu gambar lama dengan paket out-of-date perangkat lunak yang rentan harus dihapus untuk mencegah penyebaran dan paparan yang tidak disengaja. Setiap repositori ECR dapat memiliki kebijakan siklus hidup yang menetapkan aturan kapan gambar kedaluwarsa. Dokumentasi resmi AWS menjelaskan cara mengatur aturan pengujian, mengevaluasinya, dan kemudian menerapkannya. Ada beberapa contoh kebijakan siklus hidup di dokumen resmi yang menunjukkan berbagai cara memfilter gambar dalam repositori:

  • Memfilter berdasarkan usia gambar atau hitungan

  • Memfilter berdasarkan gambar yang ditandai atau tidak ditandai

  • Memfilter berdasarkan tag gambar, baik dalam beberapa aturan atau satu aturan

??? + peringatan Jika gambar untuk aplikasi yang berjalan lama dibersihkan dari ECR, itu dapat menyebabkan kesalahan penarikan gambar saat aplikasi dipindahkan atau diskalakan secara horizontal. Saat menggunakan kebijakan siklus hidup gambar, pastikan Anda memiliki CI/CD praktik yang baik untuk menjaga penerapan dan gambar yang mereka referensikan tetap mutakhir dan selalu membuat aturan kedaluwarsa [image] yang memperhitungkan seberapa sering Anda melakukan rilis/penerapan.

Buat satu set gambar yang dikuratori

Daripada mengizinkan pengembang untuk membuat gambar mereka sendiri, pertimbangkan untuk membuat satu set gambar yang diperiksa untuk tumpukan aplikasi yang berbeda di organisasi Anda. Dengan demikian, pengembang dapat mengabaikan belajar bagaimana menulis Dockerfiles dan berkonsentrasi pada penulisan kode. Saat perubahan digabungkan menjadi Master, CI/CD pipeline dapat secara otomatis mengkompilasi aset, menyimpannya dalam repositori artefak dan menyalin artefak ke gambar yang sesuai sebelum mendorongnya ke registri Docker seperti ECR. Setidaknya Anda harus membuat satu set gambar dasar dari mana pengembang untuk membuat Dockerfiles mereka sendiri. Idealnya, Anda ingin menghindari pengambilan gambar dari Dockerhub karena 1/Anda tidak selalu tahu apa yang ada di gambar dan 2/sekitar seperlima dari 1000 gambar teratas memiliki kerentanan. Daftar gambar-gambar itu dan kerentanannya dapat ditemukan di sini.

Tambahkan direktif USER ke Dockerfiles Anda untuk dijalankan sebagai pengguna non-root

Seperti yang disebutkan di bagian keamanan pod, Anda harus menghindari menjalankan container sebagai root. Meskipun Anda dapat mengonfigurasi ini sebagai bagian dari PodSpec, itu adalah kebiasaan yang baik untuk menggunakan USER arahan ke Dockerfiles Anda. USERDirektif menetapkan UID untuk digunakan saat menjalankanRUN,ENTRYPOINT, atau CMD instruksi yang muncul setelah direktif USER.

Lint Dockerfiles Anda

Linting dapat digunakan untuk memverifikasi bahwa Dockerfiles Anda mengikuti serangkaian pedoman yang telah ditentukan sebelumnya, misalnya penyertaan USER arahan atau persyaratan bahwa semua gambar diberi tag. dockerfile_lint adalah proyek open source dari yang memverifikasi praktik terbaik umum dan menyertakan mesin aturan RedHat yang dapat Anda gunakan untuk membuat aturan Anda sendiri untuk linting Dockerfiles. Itu dapat dimasukkan ke dalam pipa CI, di mana build dengan Dockerfiles yang melanggar aturan akan secara otomatis gagal.

Membangun gambar dari Scratch

Mengurangi permukaan serangan gambar kontainer Anda harus menjadi tujuan utama saat membuat gambar. Cara ideal untuk melakukan ini adalah dengan membuat gambar minimal yang tanpa binari yang dapat digunakan untuk mengeksploitasi kerentanan. Untungnya, Docker memiliki mekanisme untuk membuat gambar dari scratch. Dengan bahasa seperti Go, Anda dapat membuat biner tertaut statis dan mereferensikannya di Dockerfile Anda seperti dalam contoh ini:

############################
# STEP 1 build executable binary
############################
FROM golang:alpine AS builder# Install git.
# Git is required for fetching the dependencies.
RUN apk update && apk add --no-cache gitWORKDIR $GOPATH/src/mypackage/myapp/COPY . . # Fetch dependencies.
# Using go get.
RUN go get -d -v# Build the binary.
RUN go build -o /go/bin/hello

############################
# STEP 2 build a small image
############################
FROM scratch# Copy our static executable.
COPY --from=builder /go/bin/hello /go/bin/hello# Run the hello binary.
ENTRYPOINT ["/go/bin/hello"]

Ini menciptakan gambar kontainer yang terdiri dari aplikasi Anda dan tidak ada yang lain, membuatnya sangat aman.

Gunakan tag yang tidak dapat diubah dengan ECR

Tag yang tidak dapat diubah memaksa Anda untuk memperbarui tag gambar pada setiap dorongan ke repositori gambar. Ini dapat menggagalkan penyerang dari menimpa gambar dengan versi berbahaya tanpa mengubah tag gambar. Selain itu, ini memberi Anda cara untuk mengidentifikasi gambar dengan mudah dan unik.

Tanda tangani gambar Anda SBOMs, proses pipeline, dan laporan kerentanan

Ketika Docker pertama kali diperkenalkan, tidak ada model kriptografi untuk memverifikasi gambar kontainer. Dengan v2, Docker menambahkan intisari ke manifes gambar. Ini memungkinkan konfigurasi gambar untuk di-hash dan untuk hash yang akan digunakan untuk menghasilkan ID untuk gambar. Saat penandatanganan gambar diaktifkan, mesin Docker memverifikasi tanda tangan manifes, memastikan bahwa konten dihasilkan dari sumber tepercaya dan tidak ada gangguan yang terjadi. Setelah setiap lapisan diunduh, mesin memverifikasi intisari lapisan, memastikan bahwa konten cocok dengan konten yang ditentukan dalam manifes. Penandatanganan gambar secara efektif memungkinkan Anda membuat rantai pasokan yang aman, melalui verifikasi tanda tangan digital yang terkait dengan gambar.

Kami dapat menggunakan AWS Signer atau Sigstore Cosign, untuk menandatangani gambar kontainer, membuat pengesahan, laporan pemindaian kerentanan SBOMs, dan laporan proses pipeline. Pengesahan ini menjamin kepercayaan dan integritas gambar, bahwa itu sebenarnya dibuat oleh pipa tepercaya tanpa gangguan atau gangguan, dan bahwa itu hanya berisi komponen perangkat lunak yang didokumentasikan (dalam SBOM) yang diverifikasi dan dipercaya oleh penerbit gambar. Pengesahan ini dapat dilampirkan ke gambar kontainer dan didorong ke repositori.

Pada bagian selanjutnya kita akan melihat bagaimana menggunakan artefak yang dibuktikan untuk audit dan verifikasi pengontrol penerimaan.

Verifikasi integritas gambar menggunakan pengontrol penerimaan Kubernetes

Kami dapat memverifikasi tanda tangan gambar, artefak yang dibuktikan secara otomatis sebelum menerapkan gambar untuk menargetkan klaster Kubernetes menggunakan pengontrol penerimaan dinamis dan mengakui penerapan hanya jika metadata keamanan artefak mematuhi kebijakan pengontrol penerimaan.

Misalnya kita dapat menulis kebijakan yang secara kriptografis memverifikasi tanda tangan gambar, SBOM yang dibuktikan, laporan pipeline run yang dibuktikan, atau laporan pemindaian CVE yang dibuktikan. Kami dapat menulis kondisi dalam kebijakan untuk memeriksa data dalam laporan, misalnya pemindaian CVE seharusnya tidak kritisCVEs. Penerapan hanya diperbolehkan untuk gambar yang memenuhi kondisi ini dan semua penerapan lainnya akan ditolak oleh pengontrol penerimaan.

Contoh pengontrol penerimaan meliputi:

Perbarui paket dalam gambar kontainer Anda

Anda harus menyertakan RUN apt-get update && apt-get upgrade di Dockerfiles Anda untuk memutakhirkan paket dalam gambar Anda. Meskipun pemutakhiran mengharuskan Anda untuk menjalankan sebagai root, ini terjadi selama fase pembuatan gambar. Aplikasi tidak perlu dijalankan sebagai root. Anda dapat menginstal pembaruan dan kemudian beralih ke pengguna lain dengan arahan USER. Jika gambar dasar Anda berjalan sebagai pengguna non-root, beralihlah ke root dan back; jangan hanya mengandalkan pengelola gambar dasar untuk menginstal pembaruan keamanan terbaru.

Jalankan apt-get clean untuk menghapus file installer dari/var/cache/apt/archives/. Anda juga dapat menjalankan rm -rf /var/lib/apt/lists/* setelah menginstal paket. Ini menghapus file indeks atau daftar paket yang tersedia untuk diinstal. Ketahuilah bahwa perintah ini mungkin berbeda untuk setiap manajer paket. Misalnya:

RUN apt-get update && apt-get install -y \
    curl \
    git \
    libsqlite3-dev \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

Alat dan sumber daya