Dimensional Data

GitLab folosește o cheie GPG pentru a semna toate pachetele Omnibus create în conductele CI pentru a se asigura că pachetele nu au fost modificate. Această cheie este separată de cheia de semnare a metadatelor din depozit utilizată de managerii de pachete și de cheia de semnare GPG pentru GitLab Runner. Cheia de semnare a pachetului Omnibus este setat să expire la 1 iulie 2022 și va fi prelungită pentru a expira în schimb la 1 iulie 2023. De ce prelungim termenul? Expirarea cheii de semnare a pachetului Omnibus este prelungită în fiecare an pentru a respecta politicile de securitate GitLab și pentru a limita expunerea în cazul în care cheia devine compromisă. Expirarea cheii este extinsă în loc să se rotească la o nouă cheie, pentru a fi mai puțin perturbatoare pentru utilizatorii care verifică verificarea integrității pachetului înainte de a instala pachetul. Ce trebuie sa fac? Singura acțiune care trebuie luată este să vă actualizați copia cheii de semnare a pachetului dacă validați semnăturile de pe pachetele Omnibus pe care le distribuie GitLab. Cheia de semnare a pachetului nu este cheia care semnează metadatele din depozit utilizate de managerii de pachete ale sistemului de operare, cum ar fi apt sau yum. Dacă nu verificați în mod specific semnăturile pachetelor sau ați configurat managerul de pachete pentru a verifica semnăturile pachetelor, nu este necesară nicio acțiune din partea dvs. pentru a continua instalarea pachetelor Omnibus. Mai multe informații privind verificarea semnăturilor pachetului sunt disponibile în documentația Omnibus. Dacă trebuie doar să reîmprospătați o copie a cheii publice, atunci o puteți găsi pe oricare dintre serverele de chei GPG căutând support@gitlab.com sau folosind ID-ul DBEF 8977 4DDB 9EB3 7D9F C3A0 3CFC F9BA F27E AB47. Alternativ, îl puteți descărca direct de pe packages.gitlab.com folosind adresa URL: https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey/gitlab-gitlab-ce-3D645A26AB9FBD22.pub.gpg Ce fac dacă mai am probleme? Deschideți o problemă îninstrumentul de urmărire a problemelor omnibus-gitlab . Înscrieți-vă pentru buletinul informativ de două ori lunar al GitLab

Când vorbim despre securitatea Terraform, există multe resurse care acoperă aspectele de securitate ale infrastructurii din jurul anumitor configurații Terraform. Privind securitatea Terraform în sine și lucrurile care ar putea merge prost atunci când îl rulează, totuși, au o acoperire foarte mică până acum. Unele lucrări publicate anterior de care sunt la curent includ: „Furnizorii și modulele Terraform utilizate în configurația dvs. Terraform vor avea acces deplin la variabilele și starea Terraform dintr-un spațiu de lucru. Terraform Cloud nu poate împiedica furnizorii și modulele rău intenționați să exfiltreze aceste date sensibile. Vă recomandăm să utilizați numai module și furnizori de încredere în configurația dvs. Terraform. .” Postarea pe blog pe care o citiți este prima parte a unei serii de trei părți care examinează aspectele lanțului de aprovizionare ale Terraform și își propune să analizeze modulele și furnizorii Terraform rău intenționați. Voi oferi, de asemenea, recomandări cu privire la securizarea procesului de rulare a Terraform împotriva modulelor și furnizorilor deveniți necinstiți. Următoarele două bloguri din serie se vor baza pe aceste descoperiri și vor acoperi subiecte și vulnerabilități mai aprofundate. Securitatea furnizorului Furnizorii din Terraform sunt binare executabile, deci dacă un furnizor devine rău intenționat, cu siguranță este „game over”, în sensul că poate face orice permite sistemul de operare gazdă pe care rulează. Furnizorii trebuie să aibă o semnătură care este validată de Terraform la instalarea Furnizorului. Versiunea 0.14 Terraform creează un fișier de blocare a dependenței care înregistrează sumele de verificare ale furnizorilor utilizați în două formate diferite. sume de control zh și h1 Primul format , zh , este pur și simplu un hash SHA256 al fișierului zip care conține un furnizor pentru o anumită combinație de platformă OS/hardware. Hash-ul h1 este așa-numitul „ dirhash ” al directorului furnizorului. Deci, dacă ne uităm la următorul fișier de blocare .terraform.lock.hcl , putem observa cele două tipuri diferite de hashe-uri: # This file is maintained automatically by “terraform init”. # Manual edits may be lost in future updates. provider “registry.terraform.io/hashicorp/aws” { version = “4.11.0” hashes = [ “h1:JTgGUEVVuuv82X0ePjDM73f+ZM+NfLwb/GGNAOM0CdE=”, “zh:3e4634f4babcef402160ffb97f9f37e3e781313ceb7b7858fe4b7fc0e2e33e99”, “zh:3ff647aa88e71419480e3f51a4b40e3b0e2d66482bea97c0b4e75f37aa5ad1f1”, “zh:4680d16fbb85663034dc3677b402e9e78ab1d4040dd80603052817a96ec08911”, “zh:5190d03f43f7ad56dae0a7f0441a0f5b2590f42f6e07a724fe11dd50c42a12e4”, “zh:622426fcdbb927e7c198fe4b890a01a5aa312e462cd82ae1e302186eeac1d071”, “zh:9b12af85486a96aedd8d7984b0ff811a4b42e3d88dad1a3fb4c0b580d04fa425”, “zh:b0b766a835c79f8dd58b93d25df8f37749f33cca2297ac088d402d718baddd9c”, “zh:b293cf26a02992b2167ed3f63711dc01221c4a5e2984b6c7c0c04a6155ab0526”, “zh:ca8e1f5c58fc838edb5fe7528aec3f2fcbaeabf808add0f401aee5073b61f17f”, “zh:e0d2ad2767c0134841d52394d180f8f3315c238949c8d11be39a214630e8d50e”, “zh:ece0d11c35a8537b662287e00af4d27a27eb9558353b133674af90ec11c818d3”, “zh:f7e1cd07ae883d3be01942dc2b0d516b9736a74e6037287ab19f616725c8f7e8”, ] } Intrările zh pot fi găsite și în versiunea v.4.11.0 a furnizorului în fișierul SHA256SUMS . Pentru a înțelege intrarea unică h1 dirhash, trebuie să aruncăm o privire la directorul furnizorului. În proiectul nostru Terraform este construit astfel: $ ls .terraform/providers/registry.terraform.io/hashicorp/aws/4.11.0/linux_amd64/ terraform-provider-aws_v4.11.0_x5 $ cd .terraform/providers/registry.terraform.io/hashicorp/aws/4.11.0/linux_amd64/ $ sha256sum terraform-provider-aws_v4.11.0_x5 34c03613d15861d492c2d826c251580c58de232be6e50066cb0a0bb8c87b48de terraform-provider-aws_v4.11.0_x5 $ sha256sum terraform-provider-aws_v4.11.0_x5 > /tmp/dirhash $ sha256sum /tmp/dirhash 253806504555baebfcd97d1e3e30ccef77fe64cf8d7cbc1bfc618d00e33409d1 /tmp/dirhash $ echo 253806504555baebfcd97d1e3e30ccef77fe64cf8d7cbc1bfc618d00e33409d1 | ruby -rbase64 -e ‘puts Base64.encode64 [STDIN.read.chomp].pack(“H*”)’ JTgGUEVVuuv82X0ePjDM73f+ZM+NfLwb/GGNAOM0CdE= dirhash -ul, numit h1 în fișierul de blocare, este creat dintr-o listă alfabetică de nume de sha256sum filename . Odată ce această listă este sumată din nou, sha256sum rezultat este luat în reprezentare binară și apoi convertit în Base64. Din perspectiva unui atacator, partea interesantă a fișierului de blocare este că poate conține mai multe hash-uri zh și h1 pentru fiecare furnizor. De asemenea, este de remarcat faptul că aceste două tipuri nu trebuie să aibă nicio relație. Dacă modificăm conținutul unui furnizor descărcat pe disc, putem pur și simplu să plasăm hash-ul h1 corespunzător lângă orice alt h1 din fișierul de blocare. Deoarece pot exista mai multe intrări, nu am întrerupe nicio instalare legitimă și am permite doar să listăm un director de furnizor modificat pe […]