อินสแตนซ์ RDS ของคุณไม่มีปลายทางสาธารณะ
เข้าถึงมันผ่าน AWS SSM โดยไม่ต้องมี Bastion
AgentsRoom เปิดเซสชันฟอร์เวิร์ดพอร์ตของ AWS Session Manager ไปยังฐานข้อมูลของคุณ แล้วต่อไคลเอนต์ SQL ของมันผ่านเซสชันนั้น เซสชันนี้รัน aws ssm start-session ด้วยเอกสาร AWS-StartPortForwardingSessionToRemoteHost โดยได้รับอนุญาตจากโปรไฟล์ AWS ที่ตั้งค่าไว้บนเครื่องของคุณอยู่แล้ว
ฐานข้อมูลยังอยู่ในซับเน็ตส่วนตัวของมัน security group ยังคงปิดอยู่ และไม่มีอะไรใหม่ถูกเปิดออกสู่อินเทอร์เน็ต สิ่งที่เปลี่ยนไปคือคุณคิวรีมันได้เสียที และตัวแทนเขียนโค้ด AI ก็คิวรีได้เช่นกัน แบบอ่านอย่างเดียว
วิธีที่ AgentsRoom เข้าถึงอินสแตนซ์ RDS ในซับเน็ตส่วนตัวผ่าน AWS Systems Manager โดยไม่ต้องเปิดอะไรสู่อินเทอร์เน็ตเลย
สถาปัตยกรรมแบบนี้พบบ่อยจนน่าเบื่อ และน่าปวดหัวพอที่จะกินเวลาไปทั้งบ่าย อินสแตนซ์ Amazon RDS นั่งอยู่ในซับเน็ตส่วนตัว มันไม่มีปลายทางสาธารณะ security group ของมันรับทราฟฟิกจากแอปพลิเคชันเท่านั้น ไม่รับจากที่อื่นเลย ไม่มีพอร์ต SSH ขาเข้าอยู่ที่ไหนใน VPC นั้น เพราะมีคนทำในสิ่งที่ถูกต้องและปิดมันไปแล้ว และตอนนี้คุณต้องดูข้อมูลสามแถวเพื่อทำความเข้าใจบั๊กหนึ่งตัว
AWS Systems Manager Session Manager แก้เรื่องการรับส่งข้อมูลนี้ไว้ให้แล้ว โหนด EC2 ที่ถูกจัดการซึ่งอยู่ภายใน VPC สามารถฟอร์เวิร์ดพอร์ตในเครื่องของคุณไปยังโฮสต์ที่สามที่มันเข้าถึงได้ ซึ่งก็คืออินสแตนซ์ RDS ในซับเน็ตส่วนตัวพอดี เอกสารที่ทำหน้าที่นี้คือ AWS-StartPortForwardingSessionToRemoteHost และคำสั่งคือ aws ssm start-session ไม่มีอะไรแปลกใหม่ และไม่มีอะไรต้องติดตั้งบนฐานข้อมูล
AgentsRoom รันคำสั่งนั้นให้คุณ และวางไคลเอนต์ SQL ไว้ที่ปลายอีกด้าน คุณเลือกอินสแตนซ์ ภูมิภาค และโปรไฟล์เพียงครั้งเดียว ผูกการเชื่อมต่อฐานข้อมูลเข้ากับมัน จากนั้นการเปิดฐานข้อมูลนั้นก็เหลือแค่คลิกเดียว เซสชันได้รับอนุญาตจากโปรไฟล์ AWS หรือการล็อกอิน SSO ของคุณเอง จึงไม่มีคีย์และไม่มีรหัสผ่านถูกเก็บไว้สำหรับการกระโดดข้ามนี้
ทางออกที่คนใช้กันมีราคาที่ต้องจ่ายทุกทาง
สามคำตอบสำหรับปัญหาเดียวกัน และสิ่งที่แต่ละคำตอบเรียกเก็บจากคุณ
เครื่อง bastion ที่ต้องคอยดูแล
jump box ในซับเน็ตสาธารณะคือเซิร์ฟเวอร์อีกเครื่องที่คุณต้องแพตช์ ต้องเฝ้าดู ต้องจ่ายเงิน และสุดท้ายก็ลืมมันไป มันแบกพอร์ต SSH ขาเข้าเอาไว้ แบกรายการคีย์ที่ได้รับอนุญาตซึ่งค่อย ๆ เพี้ยนไปตามคนที่เข้าและออกจากทีม และแบก security group ที่ห่างจากการเปิดสู่ทั้งโลกเพียงแค่การแก้ไขที่เผลอเรอครั้งเดียว มันมีอยู่เพียงเพื่อให้ใครสักคนเข้าถึงฐานข้อมูลได้เป็นครั้งคราวเท่านั้น
VPN ทั้งตัว เพื่อคำถามที่ตอบได้ด้วยข้อมูลสามแถว
client VPN ลากเครื่องทั้งเครื่องของคุณเข้าไปอยู่ในเครือข่าย เพียงเพื่อตอบคำถามเกี่ยวกับข้อมูลสามแถว มันต้องถูกจัดเตรียม แจกจ่าย ต่ออายุ และเพิกถอน มันตีกันกับการเชื่อมต่ออื่น ๆ ของคุณ และบนแล็ปท็อปที่ย้ายไปมาระหว่างเครือข่าย มันคือชิ้นส่วนที่พังเป็นชิ้นแรก ทีมส่วนใหญ่ที่มี VPN ก็ยังเก็บ bastion ไว้ข้าง ๆ อยู่ดี
ข้อมูลประจำตัวที่ถูกคัดลอกไปทั่ว
ทางเลือกที่ทุกคนถอยไปใช้นั้นแย่กว่า : ปลายทางและรหัสผ่านไปจบลงในข้อความแชท ในโน้ตที่แชร์กัน ในสคริปต์ที่เผลอคอมมิต หรือในพรอมต์ที่ส่งให้ตัวแทน AI สิทธิ์เข้าถึงกระจายไปยังที่ที่ไม่มีใครตามดู และการเพิกถอนมันภายหลังก็แปลว่าต้องหมุนข้อมูลประจำตัวใหม่ แล้วภาวนาว่าสำเนาทุกชุดหายไปหมดแล้ว
จากอินสแตนซ์ RDS ส่วนตัว สู่ชุดผลลัพธ์
สี่ขั้นตอน ทำครั้งเดียว จากนั้นเหลือแค่คลิกเดียว
บันทึกการเชื่อมต่อ AWS SSM
ในตัวจัดการการเชื่อมต่อ ให้เพิ่มการเชื่อมต่อหนึ่งรายการแล้วตั้งค่าช่องทางรับส่งข้อมูลของมันเป็น AWS SSM คุณใส่ instance ID ของโหนด EC2 ที่ถูกจัดการซึ่งเข้าถึงฐานข้อมูลได้ (i-0123456789abcdef0), โปรไฟล์ AWS ของคุณ และภูมิภาค ไม่มีช่องรหัสผ่านและไม่มีช่องคีย์ เพราะเซสชันได้รับอนุญาตจากข้อมูลประจำตัว AWS ที่อยู่บนเครื่องของคุณอยู่แล้ว
เพิ่มฐานข้อมูล แล้วให้มันวิ่งผ่านการเชื่อมต่อนั้น
เพิ่มการเชื่อมต่อ MySQL หรือ MariaDB โดยใช้ปลายทาง RDS เป็นโฮสต์ พร้อมพอร์ต ผู้ใช้ และฐานข้อมูล ในช่อง Reach through ให้เลือกการเชื่อมต่อ AWS SSM ที่คุณเพิ่งบันทึกไว้ แทนการเชื่อมต่อโดยตรง เท่านี้คือการตั้งค่าทั้งหมด : ปลายทางยังคงเป็นส่วนตัว และ security group ยังคงปิดอยู่
AgentsRoom เปิดเซสชันให้
เมื่อคุณเปิดการเชื่อมต่อ AgentsRoom จะขอพอร์ต loopback ที่ว่างจากระบบปฏิบัติการ แล้วเริ่ม aws ssm start-session ด้วยเอกสาร AWS-StartPortForwardingSessionToRemoteHost โดยส่งปลายทาง RDS เป็น host, พอร์ตของฐานข้อมูลเป็น portNumber และพอร์ตที่จองไว้เป็น localPortNumber มันจะรอจนกว่าพอร์ตนั้นจะรับการเชื่อมต่อ TCP ได้จริง ก่อนจะประกาศว่าอุโมงค์พร้อมใช้งาน ไคลเอนต์จึงไม่มีทางเชื่อมต่อเร็วเกินไป
คิวรีเอง หรือให้ตัวแทนคิวรี
คอนโซล SQL เชื่อมต่อไปที่ 127.0.0.1 บนพอร์ตที่ฟอร์เวิร์ดไว้ และทำงานเหมือนการเชื่อมต่ออื่น ๆ ทุกประการ : ตัวเรียกดูสคีมา ทีละหนึ่งคำสั่ง และชุดผลลัพธ์ที่ถูกจำกัดจำนวน ตัวแทนเขียนโค้ด AI คิวรีการเชื่อมต่อเดียวกันนี้ผ่าน MCP ได้แบบอ่านอย่างเดียว โดยไม่เคยได้รับรหัสผ่าน และเมื่อคุณปิดการเชื่อมต่อ โปรเซสของเซสชันก็ถูกปิดตามไปด้วย
คำสั่งที่ AgentsRoom เรียกขึ้นมา
ที่นี่ไม่มีโปรโตคอลเฉพาะของใคร และไม่มีอะไรถูกเขียนขึ้นใหม่ใน JavaScript AgentsRoom เรียก AWS CLI ขึ้นมาเป็นโปรเซสลูก โดยส่งอาร์กิวเมนต์ตรง ๆ แทนที่จะผ่านเชลล์ แล้วอ่านผลลัพธ์ของมัน ถ้าคุณเคยเปิดเซสชันฟอร์เวิร์ดพอร์ตด้วยมือมาก่อน นี่คือบรรทัดที่คุณรู้จักอยู่แล้ว
aws ssm start-session \
--target i-0a1b2c3d4e5f \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters host=acme-prod.abc123.eu-west-1.rds.amazonaws.com,\
portNumber=3306,localPortNumber=54321 \
--profile acme-prod --region eu-west-1instance ID, ปลายทาง, ภูมิภาค และโปรไฟล์ มาจากการเชื่อมต่อที่คุณบันทึกไว้ ส่วนพอร์ตในเครื่องถูกเลือกโดยระบบปฏิบัติการตอนเปิดการเชื่อมต่อ
การฟอร์เวิร์ดไปที่ตัวโหนดที่ถูกจัดการเอง แทนที่จะไปยังฐานข้อมูลที่อยู่ข้างหลังมัน ก็คือเอกสารตัวเดียวกันโดยตั้ง host=localhost นั่นคือเหตุผลที่การเชื่อมต่อชนิดเดียวกันครอบคลุมทั้งฐานข้อมูลในซับเน็ตส่วนตัว และบริการที่รันอยู่บนอินสแตนซ์ที่คุณเชื่อมต่ออยู่
เงื่อนไขที่ต้องเป็นจริงก่อนมันจะทำงาน
AgentsRoom เป็นตัวขับการตั้งค่า AWS ของคุณ ไม่ได้มาแทนที่มัน มีห้าอย่างที่ต้องพร้อมอยู่ก่อน และมันคือห้าอย่างเดียวกับที่ Session Manager ต้องการอยู่แล้วในตัวมันเอง
AWS CLI บนเครื่องของคุณ
AgentsRoom เรียกไบนารี aws โดยตรง ถ้า aws ssm start-session ใช้งานได้ในเทอร์มินัลของคุณ มันก็ใช้งานได้ที่นี่
ปลั๊กอิน session-manager-plugin
Session Manager ต้องการให้ติดตั้งปลั๊กอินของมันไว้ข้าง ๆ CLI ถ้าไม่มีมัน เซสชันจะจบลงทันที และ AgentsRoom จะแสดงข้อผิดพลาดที่ CLI พิมพ์ออกมาให้คุณเห็น แทนที่จะค้างรอไปเฉย ๆ
โปรไฟล์ AWS หรือการล็อกอิน SSO ที่ใช้งานได้
การอนุญาตมาจากข้อมูลประจำตัวของคุณเอง ซึ่งถูกส่งเป็น --profile และ --region AgentsRoom เก็บแค่ชื่อโปรไฟล์และภูมิภาค ไม่เคยเก็บคีย์ ไม่เคยเก็บความลับ
โหนดที่ถูกจัดการอยู่ใน VPC
อินสแตนซ์ EC2 ที่ลงทะเบียนไว้กับ Systems Manager รัน SSM Agent อยู่ และมี instance profile ที่อนุญาตให้เปิดเซสชันได้ มันคือโหนดที่ทราฟฟิกวิ่งผ่าน และตัวมันเองไม่ต้องเปิดพอร์ตขาเข้าใด ๆ เลย
เส้นทางจากโหนดไปยังฐานข้อมูล
security group ของฐานข้อมูลต้องยอมรับทราฟฟิกจากโหนดบนพอร์ตของฐานข้อมูล และนโยบาย IAM ของคุณต้องอนุญาต ssm:StartSession กับเอกสารนั้น นอกเหนือจากนี้ไม่มีอะไรใน VPC ที่ต้องเปลี่ยนอีก
อุโมงค์นี้ทำอะไร และปฏิเสธที่จะทำอะไร
คุณสมบัติที่ตัดสินว่าการทิ้งการตั้งค่านี้ไว้บนแล็ปท็อปนั้นปลอดภัยหรือไม่
เฉพาะ loopback เท่านั้น
พอร์ตที่ฟอร์เวิร์ดถูกผูกไว้กับ 127.0.0.1 เท่านั้น ไม่มีอย่างอื่น ฐานข้อมูลที่เข้าถึงด้วยวิธีนี้จะไม่ถูกเผยแพร่ซ้ำบนเครือข่ายท้องถิ่น Wi-Fi ของร้านกาแฟจึงไม่เปลี่ยนแล็ปท็อปของคุณให้กลายเป็นพร็อกซีเปิดที่พาไปถึงโปรดักชัน
พอร์ตที่ระบบปฏิบัติการเลือกให้
AgentsRoom ขอพอร์ตที่ว่างจากระบบปฏิบัติการแล้วส่งต่อให้เซสชัน ไม่มีพอร์ตตายตัวให้ใครเดา ไม่มีอะไรต้องจองไว้ล่วงหน้า และไม่ชนกับอย่างอื่นที่คุณกำลังรันอยู่
พร้อม คือพร้อมจริง
อุโมงค์จะถือว่าสำเร็จก็ต่อเมื่อพอร์ตในเครื่องรับการเชื่อมต่อ TCP ได้จริงเท่านั้น และถ้ามันไม่เคยรับเลย มันก็จะยอมแพ้พร้อมข้อผิดพลาดที่ CLI พิมพ์ออกมา ไม่มีการหน่วงเวลาแบบสุ่มสี่สุ่มห้า และไม่มีไคลเอนต์ที่ไปต่อกับพอร์ตซึ่งยังไม่ได้ฟังอยู่
ไม่มีคีย์ ไม่มีรหัสผ่านสำหรับการกระโดดข้าม
เซสชัน SSM ได้รับอนุญาตจากโปรไฟล์ AWS หรือเซสชัน SSO ของคุณ AgentsRoom เก็บแค่ instance ID, ชื่อโปรไฟล์ และภูมิภาค ไม่มีอะไรที่คนซึ่งอ่านการตั้งค่านั้นจะเอาไปเล่นซ้ำได้
ฐานข้อมูลยังคงเป็นแบบอ่านอย่างเดียว
การเชื่อมต่อฐานข้อมูลเป็นแบบอ่านอย่างเดียวตั้งแต่ตอนสร้าง การเขียนต้องอาศัยการทำให้การเชื่อมต่อนั้นเขียนได้ บวกกับการยืนยันอย่างชัดเจน และการเชื่อมต่อที่ถูกทำเครื่องหมายเป็นโปรดักชันจะประกาศตัวออกมาดัง ๆ ในการยืนยันนั้น
หนึ่งคำสั่งต่อหนึ่งการเรียก
การเรียกแต่ละครั้งพาไปได้เพียงหนึ่งคำสั่งเท่านั้น จึงไม่มีอะไรแอบซ่อนอยู่หลังเซมิโคลอน และชุดผลลัพธ์ถูกจำกัดจำนวน คิวรีที่กว้างเกินไปจึงท่วมหน้าต่างหรือบริบทของตัวแทนไม่ได้
ทำไมนี่คือการเข้าถึงที่น้อยลง ไม่ใช่มากขึ้น
อุโมงค์ฟังดูเหมือนรูรั่ว และสัญชาตญาณนั้นก็ถูก : วิธีเข้าถึงฐานข้อมูลส่วนตัวส่วนใหญ่ทำให้พื้นที่ถูกโจมตีกว้างขึ้นจริง ๆ แต่วิธีนี้ทำให้มันแคบลง ไม่มีอะไรถูกเปิดฝั่งฐานข้อมูล ไม่มีพอร์ตขาเข้าถูกสร้างขึ้นที่ไหนใน VPC และโหนดที่ถูกจัดการก็ไม่ต้องมีตัวรับ SSH ของตัวเอง ทราฟฟิกวิ่งออกจากโหนดไปหาบริการ Systems Manager และเครื่องของคุณไปพบกับมันที่นั่น
การให้สิทธิ์ยังคงอยู่ในที่ที่องค์กรของคุณจัดการมันอยู่แล้ว เซสชันถูกอนุมัติด้วยตัวตน AWS ของคุณ ผ่านโปรไฟล์หรือการล็อกอิน SSO ที่ตั้งค่าไว้บนเครื่องอยู่แล้ว ซึ่งแปลว่ามันถูกบันทึกล็อกเหมือนเซสชัน Session Manager อื่น ๆ ถูกเพิกถอนในวันที่ตัวตนนั้นถูกเพิกถอน และถูกจำกัดขอบเขตด้วยนโยบาย IAM แทนที่จะขึ้นอยู่กับว่าใครบังเอิญถือคีย์อยู่ AgentsRoom เก็บแค่ instance ID, ชื่อโปรไฟล์ และภูมิภาค : ไม่มีอะไรในนั้นเป็นข้อมูลประจำตัวเลย
ฝั่งฐานข้อมูล การ์ดเรลก็เป็นชุดเดียวกับที่ทุกการเชื่อมต่อของ AgentsRoom ได้รับ อ่านอย่างเดียวโดยค่าเริ่มต้น หนึ่งคำสั่งต่อหนึ่งการเรียก ชุดผลลัพธ์ถูกจำกัดจำนวน และมีธงโปรดักชันที่ทำให้การยืนยันการเขียนเข้มขึ้น ตัวแทน AI ที่คิวรีผ่าน MCP ได้รับเพียงชุดผลลัพธ์ ไม่เคยได้รหัสผ่าน และเครื่องมือที่มันใช้คิวรีก็ปฏิเสธทุกอย่างที่ไม่ใช่การอ่าน ไม่ว่าการเชื่อมต่อนั้นจะอนุญาตให้มนุษย์ทำอะไรได้ก็ตาม
MySQL และ MariaDB เท่านั้น และ PostgreSQL ไม่ใช่หนึ่งในนั้น
ไคลเอนต์ฐานข้อมูลพูดโปรโตคอลระดับสายของ MySQL เอนจินที่ใช้งานได้จึงเป็น MySQL และ MariaDB บน RDS นั่นหมายถึง RDS for MySQL, RDS for MariaDB และ Aurora รุ่นที่เข้ากันได้กับ MySQL ส่วน RDS for PostgreSQL และ Aurora PostgreSQL ยังไม่รองรับ เช่นเดียวกับ SQL Server, Oracle, MongoDB และ SQLite คุณควรได้รู้เรื่องนี้ก่อนดาวน์โหลด ไม่ใช่หลังจากนั้น
ตัวช่องทางรับส่งข้อมูลของ SSM เองไม่ผูกกับเอนจินใด เพราะมันแค่ฟอร์เวิร์ดพอร์ต TCP สิ่งที่ยังขาดสำหรับ PostgreSQL คือไคลเอนต์ที่อยู่ข้างบน ไม่ใช่อุโมงค์ที่อยู่ข้างล่าง เอนจินตัวถัดไปถูกตัดสินจากสิ่งที่ผู้คนร้องขอ ถ้าตัวของคุณยังไม่มี บอกว่าเป็นตัวไหนบน backlog สาธารณะ แล้วมันจะถูกนับ
ขอเอนจินฐานข้อมูลของคุณตัวแทนก็คิวรีมันได้เช่นกัน แบบอ่านอย่างเดียว
เมื่อการเชื่อมต่อมีอยู่แล้ว ตัวแทนเขียนโค้ด AI ก็ใช้มันผ่าน AgentsRoom MCP ได้ด้วยการเรียกชื่อมัน db_list คืนการเชื่อมต่อที่บันทึกไว้พร้อมข้อมูลเมตาของมัน, db_schema ไล่ดูสคีมา ตาราง และคอลัมน์โดยไม่ต้องใช้ SQL สักบรรทัด, db_query รันหนึ่งคำสั่งและคืนแถวข้อมูลที่ถูกจำกัดจำนวน และ db_connection_new เสนอฐานข้อมูลที่ยังไม่ได้บันทึกไว้ ด้วยการกรอกฟอร์มไว้ล่วงหน้าให้คุณตรวจทานและบันทึกเอง
AgentsRoom เป็นฝ่ายเปิดเซสชัน SSM เองเมื่อตัวแทนร้องขอ ตัวแทนจึงไม่เคยแตะข้อมูลประจำตัว AWS รหัสผ่านฐานข้อมูล หรือหมายเลขพอร์ตเลย สิ่งที่เดินทางกลับไปคือชุดผลลัพธ์ db_query เป็นแบบอ่านอย่างเดียวไม่ว่าการเชื่อมต่อจะอนุญาตอะไรก็ตาม และกฎข้อนี้อยู่ในแอปเดสก์ท็อป ไม่ใช่ในโปรเซส MCP มันจึงยังยืนอยู่แม้ตัวแทนจะถูกหว่านล้อมให้ขออย่างอื่น
นั่นคือประเด็นทั้งหมดของการทำเรื่องนี้ให้ถูกต้อง ตัวแทนที่กำลังดีบักกับ replica ของโปรดักชันในซับเน็ตส่วนตัวจะอ่านแถวข้อมูลที่อธิบายบั๊กได้ แต่ไม่มีเส้นทางไหนให้มันเปลี่ยนแปลงข้อมูลนั้น ไม่มีข้อมูลประจำตัวให้รั่วเข้าไปในบริบทของมัน และไม่มีทางเข้าถึงฐานข้อมูลนั้นได้อีกเมื่อแอปถูกปิดลง
คำถามที่พบบ่อย
ฉันจะเชื่อมต่อกับอินสแตนซ์ RDS ที่ไม่มีปลายทางสาธารณะได้อย่างไร?
ผ่านเซสชันฟอร์เวิร์ดพอร์ตของ AWS SSM บันทึกการเชื่อมต่อ AWS SSM ที่ชี้ไปยังโหนด EC2 ที่ถูกจัดการซึ่งเข้าถึงฐานข้อมูลได้ จากนั้นสร้างการเชื่อมต่อ MySQL หรือ MariaDB โดยใช้ปลายทาง RDS เป็นโฮสต์ แล้วเลือกการเชื่อมต่อ SSM นั้นในช่อง Reach through AgentsRoom จะเปิดเซสชันด้วย aws ssm start-session และต่อไคลเอนต์ SQL เข้ากับพอร์ต loopback ที่ฟอร์เวิร์ดไว้ ฐานข้อมูลยังคงไม่มีปลายทางสาธารณะ และ security group ของมันไม่ถูกแตะต้อง
AgentsRoom ใช้เอกสาร SSM ตัวไหน?
AWS-StartPortForwardingSessionToRemoteHost โดยตั้ง host เป็นปลายทางของฐานข้อมูล, portNumber เป็นพอร์ตของฐานข้อมูล และ localPortNumber เป็นพอร์ต loopback ที่จองไว้บนเครื่องของคุณ เอกสารตัวนี้ฟอร์เวิร์ดผ่านโหนดที่ถูกจัดการไปยังโฮสต์ที่สาม ซึ่งก็คือกรณีของอินสแตนซ์ RDS ในซับเน็ตส่วนตัวพอดี ส่วนการฟอร์เวิร์ดไปยังตัวโหนดเองก็คือเอกสารเดียวกันโดยตั้ง host=localhost
ฉันยังต้องมีเครื่อง bastion อยู่หรือไม่?
ไม่ต้อง Session Manager มาแทนที่ jump box ในกรณีใช้งานนี้ : โหนดที่ถูกจัดการไม่ต้องมีพอร์ต SSH ขาเข้าและไม่ต้องมี IP สาธารณะ ทราฟฟิกออกจากโหนดไปหาบริการ Systems Manager และเครื่องของคุณเข้าร่วมเซสชันจากภายนอก ไม่มีรายการคีย์ให้ต้องคอยดูแล และไม่มีซับเน็ตสาธารณะให้ต้องคอยจับตา
ฉันต้องติดตั้งอะไรบนเครื่องของฉันบ้าง?
AWS CLI และ session-manager-plugin บวกกับโปรไฟล์ AWS หรือการล็อกอิน SSO ที่ใช้งานได้ AgentsRoom เรียกไบนารี aws โดยตรง ดังนั้นถ้า aws ssm start-session ใช้งานได้ในเทอร์มินัลของคุณ มันก็ใช้งานได้ที่นี่ ถ้าปลั๊กอินหายไป เซสชันจะจบลงทันที และ AgentsRoom จะแสดงข้อผิดพลาดที่ CLI พิมพ์ออกมาให้คุณเห็น แทนที่จะค้างรออยู่กับพรอมต์ที่มองไม่เห็น
AgentsRoom เก็บคีย์ AWS ไว้สำหรับเรื่องนี้หรือไม่?
ไม่เก็บ เซสชันได้รับอนุญาตจากข้อมูลประจำตัว AWS ที่ตั้งค่าไว้บนเครื่องของคุณอยู่แล้ว ซึ่งถูกส่งให้ CLI เป็น --profile และ --region AgentsRoom เก็บ instance ID, ชื่อโปรไฟล์ และภูมิภาค ซึ่งไม่ใช่ข้อมูลประจำตัว ส่วนรหัสผ่านฐานข้อมูลเป็นคนละเรื่อง : มันถูกเก็บไว้ในห้องนิรภัยแบบเข้ารหัสผ่านคีย์เชนของระบบปฏิบัติการ และไม่เคยถูกคืนกลับไปให้ตัวแทน AI
อุโมงค์ใช้พอร์ตในเครื่องพอร์ตไหน และใครเข้าถึงมันได้บ้าง?
ระบบปฏิบัติการเลือกพอร์ตที่ว่างให้ตอนเปิดการเชื่อมต่อ และอุโมงค์ผูกมันไว้กับ 127.0.0.1 เท่านั้น ไม่มีอะไรบนเครือข่ายท้องถิ่นเข้าถึงมันได้ และไม่มีพอร์ตตายตัวให้ใครเดา อุโมงค์จะถือว่าพร้อมใช้งานก็ต่อเมื่อพอร์ตนั้นรับการเชื่อมต่อ TCP ได้จริง และมันถูกปิดลงพร้อมกับการเชื่อมต่อ
วิธีนี้ใช้กับ RDS for PostgreSQL ได้หรือไม่?
ไม่ได้ ไคลเอนต์ฐานข้อมูลรองรับ MySQL และ MariaDB เท่านั้น บน RDS จึงหมายถึง RDS for MySQL, RDS for MariaDB และ Aurora รุ่นที่เข้ากันได้กับ MySQL ส่วน RDS for PostgreSQL และ Aurora PostgreSQL ยังไม่รองรับในวันนี้ เช่นเดียวกับ SQL Server, Oracle, MongoDB และ SQLite ตัวอุโมงค์ SSM เองแค่ฟอร์เวิร์ดพอร์ต TCP และไม่สนใจว่าเป็นเอนจินอะไร สิ่งที่ยังขาดคือไคลเอนต์ที่อยู่ข้างบน ขอเอนจินได้บน backlog สาธารณะ แล้วมันจะถูกนับ
ฉันฟอร์เวิร์ดไปยังตัวอินสแตนซ์ EC2 เองแทนฐานข้อมูลได้หรือไม่?
ได้ มันคือเอกสารเดียวกันโดยตั้ง host=localhost บริการที่ฟังอยู่บนโหนดที่ถูกจัดการจึงเข้าถึงได้ด้วยวิธีเดียวกัน การเชื่อมต่อ AWS SSM เดียวกันนี้ยังเปิดเซสชันเทอร์มินัลธรรมดาบนอินสแตนซ์นั้นได้ด้วย ซึ่งเป็นวิธีที่คุณใช้รัน agent CLI บนเครื่องที่ไม่มีพอร์ต SSH ขาเข้าเลยแม้แต่พอร์ตเดียว
ตัวแทน AI คิวรีฐานข้อมูลผ่านอุโมงค์นี้ได้หรือไม่?
ได้ แบบอ่านอย่างเดียว ตัวแทนเรียกชื่อการเชื่อมต่อที่บันทึกไว้ผ่าน AgentsRoom MCP แอปเป็นฝ่ายเปิดเซสชัน SSM และรันคำสั่งเอง แล้วมีเพียงชุดผลลัพธ์เท่านั้นที่เดินทางกลับไป ตัวแทนไม่เคยได้รับโปรไฟล์ AWS ข้อมูลประจำตัวของปลายทาง หรือรหัสผ่านฐานข้อมูล และ db_query ปฏิเสธทุกอย่างที่ไม่ใช่การอ่าน ไม่ว่าการเชื่อมต่อนั้นจะอนุญาตให้มนุษย์ทำอะไรได้ก็ตาม
คุณอาจจะชอบ
การเชื่อมต่อฐานข้อมูล
บันทึกการเชื่อมต่อ MySQL และ MariaDB ของคุณ เข้าถึงฐานข้อมูลในซับเน็ตส่วนตัวผ่านอุโมงค์ SSH หรือเซสชัน AWS SSM แล้วให้ตัวแทน AI ของคุณคิวรีมันผ่าน MCP อ่านอย่างเดียวโดยค่าเริ่มต้น หนึ่งคำสั่งต่อหนึ่งการเรียก ชุดผลลัพธ์ถูกจำกัดจำนวน และรหัสผ่านไม่เคยไปถึงตัวแทน
การเชื่อมต่อ SSH
บันทึกการเชื่อมต่อ SSH ของคุณ เปิดเทอร์มินัลในตัวผ่าน SSH และรัน Claude Code, Codex หรือ Antigravity CLI โดยตรงบนเซิร์ฟเวอร์ระยะไกลหรือ VPS ของคุณ ใช้การรับรองความถูกต้องด้วยคีย์ SSH หรือรหัสผ่าน โปรไฟล์การเชื่อมต่อแบบต่อโครงการ ไม่ต้องใช้ไคลเอนต์ SSH แยกต่างหาก
ตัวจัดการความลับ
เก็บคีย์ API, โทเค็น และรหัสผ่านไว้ในคีย์เชนของระบบปฏิบัติการ อ้างอิงถึงมันด้วย {{secret:NAME}} ในคำสั่งพัฒนาและสภาพแวดล้อมของตัวแทน แล้วให้ AgentsRoom แทนค่าให้ตอนเปิดใช้งาน ตัวแทนเห็นเพียงชื่อ ไม่เคยเห็นค่า และไม่มีอะไรถูกซิงก์ขึ้นเซิร์ฟเวอร์
Remote Fleet
รัน Claude, Codex และ Antigravity coding agents บน Mac ทุกเครื่องที่คุณมี และเชิญเพื่อนร่วมทีมให้ร่วมมือกับเอเจนต์เดียวกันแบบเรียลไทม์ เครื่องสำนักงาน, เครื่องที่บ้าน, เซิร์ฟเวอร์สำหรับการสร้าง, โครงการทีมที่แชร์ : ทั้งหมดในมุมมองที่รวมกันเดียวที่เข้ารหัสแบบ end-to-end.
คิวรีฐานข้อมูลที่ไม่มีใครเข้าถึงได้
ดาวน์โหลด AgentsRoom บันทึกการเชื่อมต่อ AWS SSM ชี้ฐานข้อมูล MySQL หรือ MariaDB ไปที่มัน แล้วคิวรีอินสแตนซ์ RDS ส่วนตัวของคุณได้ โดยไม่ต้องมี bastion ไม่ต้องมี VPN และไม่ต้องมีรหัสผ่านที่แชร์กัน
แอปคู่หู: ตรวจสอบตัวแทนของคุณได้ทุกที่
นำของคุณเอง: Claude, Codex, Antigravity CLI, หรือผู้ให้บริการ AI อื่น ๆ
ส่งข้อบกพร่องและคำขอไปยังแบ็คล็อกสาธารณะของคุณโดยตรง
มองเห็น AgentsRoom ในการทำงาน