Credentials สำหรับ AWS

เอกสารประกอบสำหรับ credentials AWS ใช้ข้อมูลประจำตัวเหล่านี้เพื่อตรวจสอบสิทธิ์ AWS ใน n8n ซึ่งเป็นแพลตฟอร์ม workflow อัตโนมัติ

n8n มี credentials สองประเภทสำหรับ AWS:

• AWS (IAM) : ตรวจสอบสิทธิ์ด้วยคีย์การเข้าถึง (รหัสคีย์การเข้าถึงและคีย์การเข้าถึงข้อมูลลับ)
• AWS (Assume Role) : ตรวจสอบสิทธิ์โดยรับบทบาท IAM ผ่าน AWS STS หนังสือรับรองที่ n8n ใช้สำหรับ AssumeRole สามารถป้อนการโทรด้วยตนเองหรืออ่านโดยอัตโนมัติจากสภาพแวดล้อมที่เรียกใช้ n8n

หากคุณโฮสต์ n8n ด้วยตนเองบนโครงสร้างพื้นฐาน AWS (EKS, ECS หรือ EC2) และต้องการหลีกเลี่ยงการจัดเก็บคีย์แบบคงที่ใน n8n โปรดดู การใช้ credentials ระบบ AWS .

credentials AWS (IAM)

คุณสามารถใช้ credentials เหล่านี้เพื่อตรวจสอบสิทธิ์ node ต่อไปนี้:

• AWS Bedrock Chat Model
• AWS Certificate Manager
• AWS Cognito
• AWS Comprehend
• AWS DynamoDB
• AWS Elastic Load Balancing
• AWS IAM
• AWS Lambda
• AWS Rekognition
• AWS S3
• AWS SES
• AWS SNS
• AWS SNS Trigger
• AWS SQS
• AWS Textract
• AWS Transcribe
• Embeddings AWS Bedrock

วิธีการรับรองความถูกต้องที่รองรับ (Supported authentication methods)

• รหัสการเข้าถึง API

ทรัพยากรที่เกี่ยวข้อง (Related resources)

อ้างถึง เอกสารการจัดการข้อมูลประจำตัวและการเข้าถึงของ AWS สำหรับข้อมูลเพิ่มเติมเกี่ยวกับบริการ

การใช้คีย์การเข้าถึง API (Using API access key)

หากต้องการกำหนดค่าข้อมูลประจำตัวนี้ คุณจะต้องมี AWS บัญชีและ:

• AWS ของคุณ Region
• ที่ Access Key ID : สร้างขึ้นเมื่อคุณสร้างรหัสการเข้าถึง
• ที่ Secret Access Key : สร้างขึ้นเมื่อคุณสร้างรหัสการเข้าถึง

หากต้องการสร้างคีย์การเข้าถึงและตั้งค่า credentials:

1. ในข้อมูลประจำตัว n8n ของคุณ ให้เลือก AWS ของคุณ Region.

2. เข้าสู่ระบบที่ คอนโซล IAM .

3. ในแถบนำทางที่ด้านบนขวา ให้เลือกชื่อผู้ใช้ของคุณ จากนั้นเลือก credentials ความปลอดภัย (Security credentials).

4. ใน คีย์การเข้าถึง (Access keys) ส่วน ให้เลือก สร้างรหัสการเข้าถึง (Create access key).

5. บน เข้าถึงหน้าแนวทางปฏิบัติที่ดีที่สุดและทางเลือกที่สำคัญ (Access key best practices & alternatives page) ให้เลือกกรณีการใช้งานของคุณ หากไม่แจ้งให้คุณสร้างรหัสการเข้าถึง ให้เลือก Other.

6. เลือก Next.

7. ตั้ง ก คำอธิบาย (description) ค่าแท็กสำหรับคีย์การเข้าถึงเพื่อให้ระบุได้ง่ายขึ้น เป็นต้น n8n integration.

8. เลือก สร้างรหัสการเข้าถึง (Create access key).

9. เผย Access Key ID และ Secret Access Key และป้อนใน n8n

10. หากต้องการใช้ก credentials ความปลอดภัยชั่วคราว (Temporary security credential) ให้เปิดตัวเลือกนั้นและเพิ่ม token เซสชัน (Session token) . อ้างถึง เอกสารรับรองความปลอดภัยชั่วคราวของ AWS สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการทำงานกับ credentials ความปลอดภัยชั่วคราว

11. ถ้าคุณใช้ Amazon Virtual Private Cloud (VPC) หากต้องการโฮสต์ n8n คุณสามารถสร้างการเชื่อมต่อระหว่าง VPC ของคุณกับบางแอปได้ ใช้ Custom Endpoints เพื่อป้อนจุดสิ้นสุดที่กำหนดเองที่เกี่ยวข้องสำหรับการเชื่อมต่อนี้ การตั้งค่านี้ใช้ได้กับแอปเหล่านี้:

    • การรับรู้
    • แลมบ์ดา
    • โซเชียลเน็ตเวิร์ก
    • สส
    • SQS
    • S3
    • เอสเอสเอ็ม
    • ข้อเท็จจริง

    Bedrock มีฟิลด์จุดสิ้นสุดสองช่อง: Bedrock Endpoint ใช้เพื่อแสดงรายการรุ่นที่มีจำหน่าย และ Bedrock Runtime Endpoint ใช้ในการอนุมานโดย AWS Bedrock Chat Model และ Embeddings AWS Bedrock node ตั้งค่าทั้งสองอย่างหากคุณกำหนดเส้นทาง Bedrock ผ่าน จุดสิ้นสุดอินเทอร์เฟซ VPC (PrivateLink) โดยไม่มี DNS ส่วนตัว

คุณยังสามารถสร้างคีย์การเข้าถึงผ่าน AWS CLI และ AWS API ได้อีกด้วย อ้างถึง เอกสารประกอบการจัดการคีย์การเข้าถึงของ AWS สำหรับคำแนะนำในการสร้างคีย์การเข้าถึงโดยใช้วิธีการเหล่านี้

credentials AWS (สมมติบทบาท)

คุณสามารถใช้ข้อมูลประจำตัวเหล่านี้เพื่อรับรองความถูกต้องของ node ต่อไปนี้ด้วยการรักษาความปลอดภัยที่ได้รับการปรับปรุงผ่านสมมติฐานบทบาท IAM:

• AWS Bedrock Chat Model
• AWS Certificate Manager
• AWS Cognito
• AWS Comprehend
• AWS DynamoDB
• AWS Elastic Load Balancing
• AWS IAM
• AWS Lambda
• AWS Rekognition
• AWS S3
• AWS SES
• AWS SNS
• AWS SNS Trigger
• AWS SQS
• AWS Textract
• AWS Transcribe
• Embeddings AWS Bedrock

วิธีการรับรองความถูกต้องที่รองรับ (Supported authentication methods)

• บทบาทสมมติ

ทรัพยากรที่เกี่ยวข้อง (Related resources)

อ้างถึง เอกสารประกอบบทบาท IAM ของ AWS และ เอกสาร STS AssumeRole สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการรับบทบาท

Understanding AWS Role Assumption

AWS Role Assumption ช่วยให้คุณเข้าถึงทรัพยากร AWS ได้อย่างปลอดภัยโดยรับบทบาท IAM ชั่วคราว แทนที่จะใช้คีย์การเข้าถึงที่มีอายุการใช้งานยาวนาน สิ่งนี้เป็นไปตามแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยของ AWS และช่วยให้:

• การเข้าถึงข้ามบัญชี: (Cross-account access:) เข้าถึงทรัพยากรในบัญชี AWS ต่างๆ
• การรักษาความปลอดภัยขั้นสูง: (Enhanced security:) ใช้ข้อมูลประจำตัวชั่วคราวที่จะหมดอายุโดยอัตโนมัติ
• หลักการของสิทธิพิเศษน้อยที่สุด: (Principle of least privilege:) ให้สิทธิ์ที่จำเป็นสำหรับงานเฉพาะเท่านั้น
• เส้นทางการตรวจสอบ: (Audit trail:) ติดตามได้ดีขึ้นว่าใครเข้าถึงทรัพยากรใดบ้าง

n8n ใช้ AWS SDK อย่างเป็นทางการเพื่อสร้าง STS AssumeRole โทร. โดยจะขอข้อมูลประจำตัวชั่วคราวใหม่เมื่อลงนามคำขอ node ดังนั้นคุณไม่จำเป็นต้องจัดการการหมดอายุ สิ่งนี้แตกต่างจาก credentials ความปลอดภัยชั่วคราว (Temporary security credential) ตัวเลือกบน credentials AWS (IAM) ซึ่งคุณป้อน token เซสชันแบบคงที่ที่ n8n ไม่สามารถต่ออายุได้: เมื่อ token นั้นหมดอายุ คุณต้องป้อน token ใหม่

การตั้งค่าข้อมูลประจำตัว AWS Assume Role (Setting up AWS Assume Role credentials)

ในการกำหนดค่า credentials นี้ คุณจะต้อง:

Required Parameters

• Region: ภูมิภาค AWS ที่จะเรียกใช้บริการ STS เพื่อรับบทบาท n8n เรียกตำแหน่งข้อมูล STS ระดับภูมิภาคสำหรับภูมิภาคนี้ ซึ่งรวมถึง AWS China ( cn-* ) และ AWS GovCloud ( us-gov-* ) พาร์ติชัน (มีตั้งแต่ n8n 2.29.0)
• Role ARN: Amazon Resource Name (ARN) ของบทบาท IAM ที่คุณต้องการรับ มันมีรูปแบบ arn:aws:iam::123456789012:role/MyRole . บทบาทนี้ต้องมีนโยบายความน่าเชื่อถือที่อนุญาตให้ข้อมูลประจำตัวของคุณรับได้
• External ID: ตัวระบุที่ไม่ซ้ำกันที่กำหนดโดยนโยบายความน่าเชื่อถือของบทบาท เพื่อป้องกันปัญหา "รองที่สับสน" นี่ควรเป็นค่าลับที่คุณสร้างและกำหนดค่าทั้งในนโยบายความน่าเชื่อถือของบทบาทและข้อมูลประจำตัวนี้ ถือว่าค่านี้มีความละเอียดอ่อน อย่าแชร์กับผู้ใช้ n8n คนอื่นที่คุณไม่ไว้วางใจ
• Role Session Name: ชื่อของเซสชันบทบาทที่สมมติ (ใช้สำหรับการตรวจสอบ) ค่าเริ่มต้นคือ n8n-session . ค่านี้ปรากฏในบันทึก AWS CloudTrail เพื่อให้คุณสามารถระบุเซสชันได้

credentials STS (เลือกวิธีใดวิธีหนึ่ง) (STS credentials (Choose one method))

คุณมีสองทางเลือกในการให้ข้อมูลประจำตัวเพื่อทำการเรียก STS AssumeRole:

ตัวเลือกที่ 1: ใช้ credentials ระบบ (แนะนำสำหรับการปรับใช้เซิร์ฟเวอร์)

เปิดเครื่อง Use System Credentials หากสภาพแวดล้อมที่เซิร์ฟเวอร์ n8n ของคุณทำงานนั้นมีข้อมูลระบุตัวตน AWS อยู่แล้ว จากนั้น n8n จะค้นพบ credentials สำหรับ AssumeRole โทรโดยอัตโนมัติโดยไม่ต้องเก็บสแตติกคีย์ใน n8n n8n ลองใช้แหล่งข้อมูลเหล่านี้ตามลำดับและใช้แหล่งข้อมูลแรกที่ส่งคืนข้อมูลประจำตัว:

1. ตัวแปรสภาพแวดล้อม ( AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY และเป็นทางเลือก AWS_SESSION_TOKEN)
2. บทบาท EKS IAM สำหรับบัญชีบริการ (IRSA)
3. EKS พ็อดประจำตัว
4. บทบาทงาน ECS หรือ Fargate
5. โปรไฟล์อินสแตนซ์ EC2

ตัวเลือกนี้ต้องการให้ผู้ดูแลระบบ n8n ของคุณเปิดใช้งานการเข้าถึง credentials ระบบโดยการตั้งค่าตัวแปรสภาพแวดล้อม N8N_AWS_SYSTEM_CREDENTIALS_ACCESS_ENABLED ถึง true . อ้างถึง การใช้ credentials ระบบ AWS สำหรับรายละเอียดการตั้งค่าและข้อควรพิจารณาด้านความปลอดภัย

Option 2: Manual STS Credentials

หากไม่มี credentials ระบบ ให้จัดเตรียมสิ่งเหล่านี้ด้วยตนเอง:

• STS Access Key ID: รหัสคีย์การเข้าถึงสำหรับผู้ใช้ IAM หรือบทบาทที่ได้รับอนุญาตให้รับบทบาทเป้าหมาย
• STS Secret Access Key: รหัสการเข้าถึงข้อมูลลับที่สอดคล้องกับรหัสรหัสการเข้าถึง STS
• STS Session Token (ไม่บังคับ): token เซสชันหากใช้ credentials ชั่วคราวสำหรับการโทร STS

Optional Parameters

• Custom Endpoints: หากใช้ Amazon VPC คุณสามารถระบุตำแหน่งข้อมูลแบบกำหนดเองสำหรับบริการ AWS ได้:
  • จุดสิ้นสุดการรับรู้
  • จุดสิ้นสุดแลมบ์ดา
  • จุดสิ้นสุด SNS
  • จุดสิ้นสุด SES
  • จุดสิ้นสุด SQS
  • จุดสิ้นสุด S3
  • จุดสิ้นสุด SSM
  • Bedrock Endpoint (ใช้เพื่อแสดงรายการรุ่นที่มี)
  • Bedrock Runtime Endpoint (ใช้สำหรับการอนุมาน Bedrock เช่น ผ่าน a จุดสิ้นสุดอินเทอร์เฟซ VPC (PrivateLink) )

Setup Steps

1. สร้างบทบาท IAM ในบัญชี AWS เป้าหมาย นโยบายความไว้วางใจนี้มีไว้สำหรับ Option 2: Manual STS Credentials . ถ้าคุณใช้ ตัวเลือกที่ 1: ใช้ credentials ระบบ (Option 1: Use system credentials) , ที่ Principal คือบทบาทที่ n8n ทำงานเป็น อ้างถึง นโยบายความน่าเชื่อถือสำหรับ credentials ระบบ .

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": "arn:aws:iam::SOURCE-ACCOUNT:root"
         },
         "Action": "sts:AssumeRole",
         "Condition": {
           "StringEquals": {
             "sts:ExternalId": "your-unique-external-id"
           }
         }
       }
     ]
   }
   

2. กำหนดค่าข้อมูลประจำตัวใน n8n

   • เลือก AWS ของคุณ Region
   • ป้อน Role ARN ของบทบาทที่คุณสร้างขึ้น
   • กำหนดเอกลักษณ์ External ID (เช่นเดียวกับในนโยบายความน่าเชื่อถือ)
   • เลือกของคุณ วิธีการรับรอง STS (STS credentials method)
   • ป้อน Role Session Name (หรือใช้ค่าเริ่มต้น)

3. ทดสอบข้อมูลประจำตัว (Test the credential) ใช้ฟังก์ชันทดสอบในตัวเพื่อตรวจสอบความถูกต้องของบทบาท

Security Best Practices

• ใช้ ID ภายนอกที่ไม่ซ้ำกันสำหรับข้อมูลประจำตัวแต่ละรายการเพื่อป้องกันการเข้าถึงโดยไม่ได้รับอนุญาต
• หมุนเวียน credentials STS ที่ใช้สำหรับการรับบทบาท
• ใช้หลักการของสิทธิพิเศษน้อยที่สุดกับทั้งข้อมูลประจำตัวที่สมมติและบทบาทเป้าหมาย
• ในอินสแตนซ์ที่ใช้ร่วมกัน ให้ปิดใช้งานการเข้าถึงข้อมูลประจำตัวของระบบ อ้างถึง การใช้ credentials ระบบ AWS .

การใช้ credentials ระบบ AWS (การรับรองความถูกต้องแบบรวมศูนย์)

ส่วนนี้มีไว้สำหรับผู้ดูแลระบบอินสแตนซ์ n8n ที่โฮสต์เอง

การเข้าถึง credentials ระบบมีไว้สำหรับ n8n ที่โฮสต์เองเท่านั้น ไม่สามารถใช้งานได้บน n8n Cloud

เมื่อ n8n ทำงานบนโครงสร้างพื้นฐานของ AWS ตัวโครงสร้างพื้นฐานเองก็สามารถจัดเตรียมข้อมูลระบุตัวตนของ AWS ได้ ไม่มีคีย์การเข้าถึงสำหรับสร้าง จัดเก็บ หรือหมุนเวียน นี่เป็นวิธีมาตรฐานในการตรวจสอบปริมาณงานบน EKS, ECS และ EC2 และทีมรักษาความปลอดภัยมักต้องการสิ่งนี้ ("คีย์คงที่เป็นศูนย์")

n8n อ่านสิ่งเหล่านี้ credentials ระบบ (system credentials) กับผู้ให้บริการ credentials AWS SDK อย่างเป็นทางการ และใช้เป็น credentials เริ่มต้นสำหรับ AWS (Assume Role) หนังสือรับรองเมื่อ Use System Credentials เปิดอยู่ ซึ่งใช้ได้กับ node ทั้งหมดที่ยอมรับ credentials AWS (Assume Role) รวมถึง node AWS Bedrock AI

ข้อมูลประจำตัวของระบบจะเป็นจุดเริ่มต้นสำหรับการสมมติบทบาทเสมอ ไม่ใช่ข้อมูลระบุตัวตนที่ n8n เรียกใช้ AWS โดยตรง คุณยังคงต้องป้อน Role ARN และบทบาทนั้นจะต้องเชื่อถือข้อมูลประจำตัวที่ n8n ทำงานเป็น

หากบทบาท n8n ทำงานตามสิทธิ์ที่ workflow ของคุณต้องการแล้ว ให้ป้อน ARN ของบทบาทเดียวกันนั้นและอนุญาตให้สันนิษฐานได้เอง อ้างถึง นโยบายความน่าเชื่อถือสำหรับ credentials ระบบ .

การเปิดใช้งานการเข้าถึง (Enabling access)

การเข้าถึงข้อมูลประจำตัวของระบบคือ ปิดใช้งานโดยค่าเริ่มต้น (disabled by default) . หากต้องการเปิดใช้งาน ให้ตั้งค่าตัวแปรสภาพแวดล้อมนี้ในทุกอินสแตนซ์ n8n (ตัวหลักและตัวทำงาน):

N8N_AWS_SYSTEM_CREDENTIALS_ACCESS_ENABLED=true

เมื่อเปิดใช้งาน ผู้ใช้ n8n ที่สามารถสร้างข้อมูลประจำตัว AWS (สมมติบทบาท) จะสามารถใช้ข้อมูลประจำตัว AWS ของเซิร์ฟเวอร์เป็นจุดเริ่มต้นสำหรับการสมมติบทบาท เปิดใช้งานสิ่งนี้เฉพาะบนอินสแตนซ์ของผู้เช่ารายเดียวที่โฮสต์เองซึ่งคุณเชื่อถือทุกคนที่สามารถสร้าง credentials ได้

หากต้องการจำกัดสิ่งที่ workflow สามารถทำได้กับข้อมูลระบุตัวตนของเซิร์ฟเวอร์ โปรดรักษาสิทธิ์ IAM ของเซิร์ฟเวอร์ให้น้อยที่สุด ตามหลักการแล้ว ให้สิทธิ์เพียง sts:AssumeRole เกี่ยวกับบทบาทเฉพาะที่ workflow ควรใช้ โดยแต่ละบทบาทได้รับการป้องกันโดยรหัสภายนอก

แหล่ง credentials ที่รองรับ (Supported credential sources)

n8n ลองใช้แหล่งข้อมูลเหล่านี้ตามลำดับและใช้แหล่งข้อมูลแรกที่ส่งคืนข้อมูลประจำตัว:

สิ่งที่ควรทราบ:

• AWS ฉีดตัวแปรการตรวจจับสำหรับแหล่งที่มา 2 ถึง 4 โดยอัตโนมัติเมื่อคุณกำหนดค่าคุณสมบัติแพลตฟอร์ม คุณไม่ได้ตั้งค่าพวกเขาเอง
• หากคุณตั้ง AWS_ACCESS_KEY_ID และ AWS_SECRET_ACCESS_KEY บนคอนเทนเนอร์จะมีความสำคัญเหนือกว่าบทบาท IRSA, Pod Identity และอินสแตนซ์ ลบออกหากคุณต้องการใช้แหล่งข้อมูลแบบรวมศูนย์
• n8n แก้ไขข้อมูลประจำตัวของระบบเมื่อจำเป็น ดังนั้น credentials แหล่งที่มาที่หมุนเวียนหรือมีอายุสั้น (เช่น token IRSA ที่ Kubernetes หมุนเวียน) จะถูกหยิบขึ้นมาโดยอัตโนมัติ
• อ่านโปรไฟล์ AWS CLI จาก ~/.aws (AWS_PROFILE ) ไม่ได้รับการสนับสนุนโดยเจตนา

Amazon EKS with IRSA

บทบาท IAM สำหรับบัญชีบริการ เชื่อมโยงบทบาท IAM กับบัญชีบริการ Kubernetes ที่ทำงาน n8n ใส่คำอธิบายประกอบบัญชีบริการด้วยบทบาท ARN ( eks.amazonaws.com/role-arn ). จากนั้น EKS จะฉีดเข้าไป AWS_ROLE_ARN และ AWS_WEB_IDENTITY_TOKEN_FILE ลงในพ็อด และ n8n จะแลกเปลี่ยน token กับจุดสิ้นสุด STS ระดับภูมิภาค

Amazon EKS with Pod Identity

EKS พ็อดประจำตัว เป็นทางเลือกใหม่กว่า IRSA ติดตั้งส่วนเสริม Pod Identity Agent และสร้างการเชื่อมโยงข้อมูลประจำตัวของ Pod ระหว่างบัญชีบริการ n8n และบทบาท IAM ไม่จำเป็นต้องตั้งค่าผู้ให้บริการ OIDC

Amazon ECS and Fargate

มอบหมายก บทบาทงาน ไปยังคำจำกัดความงาน n8n

Amazon EC2

แนบไฟล์ โปรไฟล์อินสแตนซ์ ไปยังอินสแตนซ์ที่ทำงานอยู่ n8n n8n ใช้ IMDSv2 ดังนั้นอินสแตนซ์ที่ปิดใช้งาน IMDSv1 จึงใช้งานได้

นโยบายความน่าเชื่อถือสำหรับ credentials ระบบ (Trust policy for system credentials)

บทบาทที่คุณเข้าร่วมเป็น Role ARN ต้องเชื่อถือข้อมูลประจำตัวที่ n8n ทำงานเป็น: บทบาท IRSA, บทบาท Pod Identity, บทบาทงาน ECS หรือบทบาทอินสแตนซ์ EC2 ใช้ ARN ของบทบาทนั้นเป็น Principal ไม่ใช่รูทบัญชี

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/n8n-service-account-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "your-unique-external-id"
        }
      }
    }
  ]
}

เพื่อค้นหา ARN เพื่อใช้เป็น Principal วิ่ง aws sts get-caller-identity จากภายในคอนเทนเนอร์หรืออินสแตนซ์ n8n

หากบทบาท n8n ทำงานตามสิทธิ์ที่ workflow ของคุณต้องการแล้ว ให้ใช้บทบาทเดียวกันกับ Role ARN และเพิ่ม ARN ของตนเองลงในนโยบายความน่าเชื่อถือดังที่แสดงไว้ด้านบน AWS ต้องการสิ่งนี้แม้ว่าบทบาทจะเข้ารับเองก็ตาม

บทบาท n8n ทำงานตามความต้องการเช่นกัน sts:AssumeRole การอนุญาตในบทบาทเป้าหมาย กำหนดให้กับ workflow บทบาทเฉพาะที่ควรใช้แทนที่จะเปิด *.

AWS China and GovCloud

มีให้ตั้งแต่ n8n 2.29.0 (Available from n8n 2.29.0) . ในเวอร์ชันก่อนหน้านี้ IRSA จะล้มเหลวในพาร์ติชัน AWS China และ GovCloud เนื่องจาก n8n เรียกว่าตำแหน่งข้อมูล STS ส่วนกลาง

credentials ระบบและการสมมติบทบาทใช้งานได้ในพาร์ติชัน AWS ทั้งหมด n8n เรียกตำแหน่งข้อมูล STS ระดับภูมิภาคสำหรับภูมิภาคของ credentials: sts.{region}.amazonaws.com.cn ใน AWS ประเทศจีน ( cn-* ) และ sts.us-gov-{east,west}-1.amazonaws.com ใน AWS GovCloud ( us-gov-*).

ลักษณะการทำงานของพร็อกซี (Proxy behavior)

หากอินสแตนซ์ของคุณใช้พร็อกซี HTTP(S) ( HTTPS_PROXY, HTTP_PROXY, NO_PROXY ), n8n กำหนดเส้นทางการโทร STS (การแลกเปลี่ยนข้อมูลประจำตัวของเว็บและ AssumeRole ) ผ่านมัน คำขอเชื่อมโยงบริการข้อมูลเมตาภายใน (ปลายทาง EC2 IMDS, ECS และ Pod Identity) จะส่งโดยตรงเสมอ ไม่เคยผ่านพร็อกซี ที่อยู่เหล่านี้สามารถเข้าถึงได้จากโฮสต์เท่านั้น

ตัวแปรสภาพแวดล้อมที่เกี่ยวข้อง (Related environment variables)

Troubleshooting

• "การเข้าถึง credentials ระบบ AWS ถูกปิดใช้งาน โปรดติดต่อผู้ดูแลระบบของคุณ" : เดอะ Use System Credentials ตัวเลือกเปิดอยู่ แต่ N8N_AWS_SYSTEM_CREDENTIALS_ACCESS_ENABLED ไม่ได้ตั้งค่าเป็น true บนเซิร์ฟเวอร์
• มีการใช้ข้อมูลระบุตัวตนที่ไม่ถูกต้อง (The wrong identity is used) : ตัวแปรสภาพแวดล้อมเอาชนะ IRSA ซึ่งเหนือกว่า Pod Identity, ECS และ EC2 เร่ร่อน AWS_ACCESS_KEY_ID ในภาชนะเป็นสาเหตุที่พบบ่อยที่สุด อ้างถึง แหล่ง credentials ที่รองรับ .
• การทดสอบข้อมูลประจำตัวล้มเหลวใน EKS (Credential test fails on EKS) : ตรวจสอบคำอธิบายประกอบบัญชีบริการ (IRSA) หรือการเชื่อมโยงข้อมูลประจำตัวของพ็อด และยืนยันว่าพ็อดได้รับตัวแปรสภาพแวดล้อมที่ถูกแทรก ( kubectl exec <pod-name> -- env | grep AWS).
• AccessDenied เมื่อโทร sts:AssumeRole : n8n พบ credentials ระบบ แต่บทบาทเป้าหมายปฏิเสธ ตรวจสอบว่านโยบายความน่าเชื่อถือของบทบาทตั้งชื่อข้อมูลประจำตัวที่ n8n ทำงานเป็น และตรวจสอบว่า External ID ตรงกับเงื่อนไขของกรมธรรม์ อ้างถึง นโยบายความน่าเชื่อถือสำหรับ credentials ระบบ .