Puncte:1

Stocați în siguranță cheile de utilizator AWS IAM (acces și secret) create de IaC

drapel de

Am urmatoarea configuratie:

  1. Infrastructura este configurată folosind AWS CDK;
  2. Am o singură stivă/mediu (producție, montare...);
  3. Fiecare stivă are un S3 Bucket diferit (utilizat pentru găzduirea site-ului);
  4. Am o stivă care creează un utilizator IAM (utilizat de CI/CD);
  5. CI/CD în acest caz este GitHub Actions (se implementează de fiecare dată când o îmbinare la principal se întâmplă);
  6. Utilizatorul IAM a pus doar drepturi la toate Bucket-urile (deploy înseamnă a pune activele în Bucket);

Care este cel mai bun mod de a stoca/manipula cheile pentru acel utilizator?

Am început să-l printez în Outputs, dar nu este sigur. Toată lumea îl poate vedea (dacă au acces la jurnalele CI/CD, de exemplu).

Mi s-a sugerat să le stochez în SSM: funcționează, dar nu îl puteți crea ca SecureString, așa că ar fi doar un șir.

Am aruncat o privire și în Secrets Manager: funcționează și pare a fi mai sigur (nu sunt sigur dacă sentimentul meu de aici este totuși valid).

Ceva idei/pareri aici?

Mulțumiri!


În cod arată ceva de genul:

// Stiva de producție
const bucket = Bucket nou (aceasta, „Găleată”, {
  bucketName: „producție”,
});

// Staging Stack
const bucket = Bucket nou (aceasta, „Găleată”, {
  bucketName: „proiectare”,
});

// Stiva IAM
utilizator const = utilizator nou (acest, „Utilizator”, {
  userName: „ci-cd-user”,
});
const userAccessKey = noua cheie de acces(aceasta, "UserAccessKey", { user });

// Acesta este doar un exemplu, trec prin toate Bucket-urile disponibile
bucketProduction.grantPut(utilizator);
bucketStaging.grantPut(utilizator);
Tim avatar
drapel gp
Tim
Ce instrument CI/CD folosiți? Este în AWS? Vă rugăm să vă actualizați întrebarea cu mai multe detalii, apoi să răspundeți aici, astfel încât să văd că a fost actualizată. Răspunsul este diferit în funcție de aceste informații.
viniciuskneves avatar
drapel de
Bună @Tim, tocmai am actualizat cu mai multe informații: CI/CD este GitHub Actions și implementare înseamnă introducerea activelor în Buckets. Te ajută sau ai nevoie de mai multe detalii?
Tim avatar
drapel gp
Tim
Personal, aș crea manual utilizatorul IAM sau cel puțin cheia de acces a acestuia, apoi aș transfera acreditările acolo unde sunt necesare în Github, în ​​loc să le stochez în AWS. Dacă trebuie să le stocați în AWS, atunci magazinul de parametri sau managerul de secrete ar fi alegerea mea, fie este bine atâta timp cât sunt criptate. Probabil că aș restricționa cine poate vedea acreditările oriunde decideți să le stocați.
viniciuskneves avatar
drapel de
Hummm.. Am înțeles. Încercam să automatizez cât mai mult posibil procesul, dar, într-adevăr, abordarea manuală a tastelor are sens. Roles, prin federație, ar fi cea mai bună soluție? Ce vreau să spun: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services
Tim avatar
drapel gp
Tim
Rolurile sunt aproape întotdeauna o opțiune mai bună decât acreditările IAM.Nu știu nimic despre acțiunile github, dar dacă își poate asuma un rol, atunci alege acea opțiune. Doar asigurați-vă că rolul este securizat corespunzător, astfel încât numai acțiunile github să își poată asuma rolul.
viniciuskneves avatar
drapel de
Mulțumiri! Îl voi adăuga aici ca răspuns de îndată ce îl voi putea încerca corect cu Roles.
drapel cn
Se pare că îl face să-și asume rolul, doar specificați rolul fără acreditări și folosește OIDC, așa că ar trebui să fie mult mai sigur. https://github.com/aws-actions/configure-aws-credentials
viniciuskneves avatar
drapel de
Da @shearn89, l-am încercat ieri și funcționează ca un farmec. Nu eram pe deplin conștient de asta sau cum funcționează... Voi rezuma constatările mele în răspuns. Mulțumesc că ai semnalat ââï¸
Puncte:0
drapel de

Mi-a luat ceva timp, dar în cele din urmă mi-am cuprins gândurile aici: https://dev.to/viniciuskneves/use-aws-through-github-actions-without-secret-keys-32eo

Ideea este de a folosi OpenID Connect la conectați-vă cu GitHub și apoi să aibă un Rol care poate fi asumat de GitHub Actions și să efectueze implementarea (aceleași politici pe care le-aș da utilizatorului GitHub Actions).

Folosind AWS CDK, soluția arată astfel:

furnizor const = nou OpenIdConnectProvider(this, "GitHubProvider", {
  url: „https://token.actions.githubusercontent.com”,
  clientIds: ["sts.amazonaws.com"], // Denumit "Audience" în documentație
});
rol constant = rol nou(acest, „Rol”, {
  assumedBy: nou OpenIdConnectPrincipal(furnizor, {
    StringEquals: {
      „token.actions.githubusercontent.com:aud”: „sts.amazonaws.com”, // „Public” de sus
    },
    StringLike: {
      „token.actions.githubusercontent.com:sub”:
      „repo:<ORGANIZATION>/<DEPOSITORY>:*”, // Organizație și depozit cărora li se permite să își asume acest rol
    },
  }),
});

bucket.grantPut(rol); // Creează o politică

După aceea, trebuie să actualizăm GitHub Actions pentru a folosi acest lucru în loc de cheile noastre de utilizator:

...
permisiuni:
  id-token: scrie
  conținut: citiți # Acest lucru este necesar pentru acțiuni/checkout (documentația GitHub menționează că)
...
- nume: Configurați acreditările AWS 
  folosește: aws-actions/[email protected] # Versiunea la momentul scrierii acestui articol
  cu: # Încărcăm cheile stocate în secret
    rol-to-assume: arn:aws:iam::<ACCOUNT>:role/<ROLE-NAME> # Puteți specifica numele rolului când îl creați sau AWS va genera automat unul pentru dvs.
    aws-region: eu-central-1
- run: npm run deploy # Doar un exemplu

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.