บรรจวบ เข้าสู่ระบบ
Score:1
viniciuskneves avatar Server

จัดเก็บคีย์ผู้ใช้ AWS IAM (การเข้าถึงและข้อมูลลับ) ที่สร้างโดย IaC อย่างปลอดภัย

ธง de
viniciuskneves

ฉันมีการตั้งค่าต่อไปนี้:

  1. โครงสร้างพื้นฐานได้รับการตั้งค่าโดยใช้ AWS CDK;
  2. ฉันมี Stack/Environment (Production, Staging...);
  3. แต่ละสแต็กมี S3 Bucket ที่แตกต่างกัน (ใช้สำหรับการโฮสต์เว็บไซต์)
  4. ฉันเป็นสแต็กที่สร้างผู้ใช้ IAM (ใช้โดย CI/CD);
  5. CI/CD ในกรณีนี้คือ GitHub Actions (ปรับใช้ทุกครั้งที่ผสานเข้ากับ หลัก เกิดขึ้น);
  6. ผู้ใช้ IAM มีสิทธิ์ในบัคเก็ตทั้งหมดเท่านั้น (ปรับใช้หมายถึงใส่เนื้อหาในบัคเก็ต)

วิธีใดดีที่สุดในการจัดเก็บ/จัดการคีย์สำหรับผู้ใช้รายนั้น

ฉันเริ่มพิมพ์ในผลลัพธ์ แต่ไม่ปลอดภัย ทุกคนสามารถดูได้ (เช่น หากเข้าถึงบันทึกของ CI/CD)

ฉันได้รับคำแนะนำให้เก็บไว้ใน SSM: ใช้งานได้ แต่คุณไม่สามารถสร้างเป็น SecureString ได้ ดังนั้นมันจึงเป็นเพียงสตริง

ฉันได้ตรวจสอบ Secrets Manager ด้วย: มันใช้งานได้และดูเหมือนจะปลอดภัยกว่า (ไม่แน่ใจว่าความรู้สึกของฉันที่นี่ถูกต้องหรือไม่)

ความคิด / ความคิดเห็นใด ๆ ที่นี่?

ขอบคุณ!

ในรหัสดูเหมือนว่า:

// กองการผลิต
ถัง const = ถังใหม่ (นี่คือ "ถัง", {
  ชื่อถัง: "การผลิต",
});

// สแต็คการจัดเตรียม
ถัง const = ถังใหม่ (นี่คือ "ถัง", {
  ชื่อถัง: "การแสดงละคร",
});

// IAM สแต็ค
ผู้ใช้ const = ผู้ใช้ใหม่ (นี่คือ "ผู้ใช้" {
  ชื่อผู้ใช้: "ผู้ใช้ ci-cd",
});
const userAccessKey = ใหม่ AccessKey (นี้ "UserAccessKey", { ผู้ใช้ });

// นี่แค่ตัวอย่างนะครับ ผมไล่ดู Buckets ที่มีอยู่ทั้งหมด
bucketProduction.grantPut (ผู้ใช้);
bucketStaging.grantPut (ผู้ใช้);
61
0 + 0
Tim avatar
gp flag
Tim
คุณใช้เครื่องมือ CI/CD ใด อยู่ใน AWS หรือไม่ โปรดอัปเดตคำถามของคุณพร้อมรายละเอียดเพิ่มเติม แล้วตอบกลับที่นี่ เพื่อดูว่ามีการอัปเดตแล้ว คำตอบนั้นแตกต่างกันไปขึ้นอยู่กับข้อมูลนี้
0
ตอบกลับ
viniciuskneves avatar
de flag
viniciuskneves
สวัสดี @Tim ฉันเพิ่งอัปเดตข้อมูลเพิ่มเติม: CI/CD คือ GitHub Actions และการปรับใช้หมายถึงการใส่เนื้อหาลงใน Buckets มันช่วยหรือคุณต้องการรายละเอียดเพิ่มเติม?
0
ตอบกลับ
Tim avatar
gp flag
Tim
โดยส่วนตัวแล้ว ฉันจะสร้างผู้ใช้ IAM หรืออย่างน้อยคีย์การเข้าถึงด้วยตนเอง จากนั้นถ่ายโอนข้อมูลรับรองไปยังตำแหน่งที่จำเป็นใน Github แทนที่จะเก็บไว้ใน AWS หากคุณต้องจัดเก็บไว้ใน AWS ที่เก็บพารามิเตอร์หรือตัวจัดการความลับจะเป็นตัวเลือกของฉัน ทั้งสองอย่างก็ใช้ได้ตราบใดที่เข้ารหัสไว้ ฉันอาจจะจำกัดว่าใครสามารถดูข้อมูลรับรองได้ทุกที่ที่คุณตัดสินใจจะจัดเก็บ
0
ตอบกลับ
viniciuskneves avatar
de flag
viniciuskneves
อืม..เข้าใจแล้ว ฉันพยายามทำให้กระบวนการเป็นไปโดยอัตโนมัติมากที่สุดเท่าที่จะเป็นไปได้ แต่การจัดการกับคีย์ด้วยตนเองนั้นสมเหตุสมผล บทบาทผ่านสหพันธ์จะเป็นทางออกที่ดีที่สุดหรือไม่? ฉันหมายถึงอะไร: https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services
0
ตอบกลับ
Tim avatar
gp flag
Tim
บทบาทมักเป็นตัวเลือกที่ดีกว่าข้อมูลรับรอง IAMฉันไม่รู้อะไรเกี่ยวกับการกระทำของ GitHub แต่ถ้ามันสามารถรับบทบาทได้ ให้เลือกตัวเลือกนั้น เพียงตรวจสอบให้แน่ใจว่าบทบาทได้รับการรักษาความปลอดภัยอย่างเหมาะสม ดังนั้นการกระทำ GitHub เท่านั้นที่สามารถรับบทบาทได้
0
ตอบกลับ
viniciuskneves avatar
de flag
viniciuskneves
ขอบคุณ! ฉันจะเพิ่มเป็นคำตอบที่นี่ทันทีที่ฉันสามารถลองกับ Roles ได้อย่างถูกต้อง
0
ตอบกลับ
cn flag
shearn89
ดูเหมือนว่าจะได้รับบทบาทที่คุณเพียงแค่ระบุบทบาทโดยไม่มีข้อมูลรับรองและใช้ OIDC ดังนั้นจึงควรปลอดภัยกว่านี้มาก https://github.com/aws-actions/configure-aws-credentials
0
ตอบกลับ
viniciuskneves avatar
de flag
viniciuskneves
ใช่ @ shearn89 ฉันลองใช้เมื่อวานนี้และใช้งานได้อย่างมีเสน่ห์ ฉันไม่ทราบแน่ชัดว่ามันทำงานอย่างไร... ฉันจะสรุปผลการวิจัยของฉันในคำตอบ ขอบคุณที่ชี้ให้เห็น ââï¸
1
ตอบกลับ
Score:0
viniciuskneves avatar Server
ธง de
viniciuskneves

ฉันใช้เวลาสักครู่ แต่ในที่สุดฉันก็สรุปความคิดของฉันไว้ที่นี่: https://dev.to/viniciuskneves/use-aws-through-github-actions-without-secret-keys-32eo

มีแนวคิดที่จะใช้ OpenID เชื่อมต่อ ถึง เชื่อมต่อกับ GitHub จากนั้นมีบทบาทที่สามารถสันนิษฐานได้โดย GitHub Actions และดำเนินการปรับใช้ (นโยบายเดียวกันกับที่ฉันให้กับผู้ใช้ GitHub Actions)

การใช้ AWS CDK โซลูชันจะมีลักษณะดังนี้:

ผู้ให้บริการ const = OpenIdConnectProvider ใหม่ (นี่คือ "GitHubProvider", {
  URL: "https://token.actions.githubusercontent.com",
  clientIds: ["sts.amazonaws.com"], // อ้างอิงเป็น "Audience" ในเอกสารประกอบ
});
บทบาท const = บทบาทใหม่ (นี่คือ "บทบาท", {
  สันนิษฐานโดย: OpenIdConnectPrincipal ใหม่ (ผู้ให้บริการ {
    สตริงเท่ากับ: {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com", // "Audience" จากด้านบน
    },
    สตริงไลค์: {
      "token.actions.githubusercontent.com:sub":
      "repo:<ORGANIZATION>/<REPOSITORY>:*", // องค์กรและพื้นที่เก็บข้อมูลที่ได้รับอนุญาตให้รับบทบาทนี้
    },
  }),
});

bucket.grantPut (บทบาท); // สร้างนโยบาย

หลังจากนั้น เราจำเป็นต้องอัปเดต GitHub Actions เพื่อใช้แทนคีย์ผู้ใช้ของเรา:

...
สิทธิ์:
  รหัสโทเค็น: เขียน
  เนื้อหา: อ่าน # สิ่งนี้จำเป็นสำหรับการดำเนินการ / ชำระเงิน (เอกสาร GitHub กล่าวถึงสิ่งนั้น)
...
- ชื่อ: กำหนดค่า AWS Credentials 
  ใช้: aws-actions/[email protected] # เวอร์ชัน ณ เวลาที่เขียนนี้
  ด้วย: # เรากำลังโหลดกุญแจที่เก็บไว้ในความลับ
    role-to-assume: arn:aws:iam::<ACCOUNT>:role/<ROLE-NAME> # คุณสามารถระบุชื่อบทบาทได้เมื่อสร้าง มิฉะนั้น AWS จะสร้างชื่อให้คุณโดยอัตโนมัติ
    ภูมิภาค aws: eu-central-1
- run: npm run deploy # แค่ตัวอย่าง
0 + 0
ธงชาติไทย
Kulap
คำถามนี้เป็นภาษาอื่นๆ:

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา