Google Cloud ಒಂದು ಮ್ಯಾನೇಜ್ಡ್ GKE Agent Sandbox ಸೇವೆಯನ್ನು ಪರಿಚಯಿಸಿದೆ, ಅದೇ ಸಮಯದಲ್ಲಿ ಓಪನ್-ಸೋರ್ಸ್ kubernetes-sigs/agent-sandbox ಪ್ರಾಜೆಕ್ಟ್ ಯಾವುದೇ Kubernetes ಕ್ಲಸ್ಟರ್‌ಗೆ ಇದೇ ಸಾಮರ್ಥ್ಯವನ್ನು ತರುತ್ತದೆ. ಇವೆರಡೂ AI ಏಜೆಂಟ್‌ಗಳಿಗಾಗಿ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಒಂದು ಡಿಸ್ಪೋಸಬಲ್ (ಬಳಸಿ ಬಿಸಾಡಬಹುದಾದ) Linux ಕಂಟೇನರ್ ಅನ್ನು ನೀಡುತ್ತವೆ, ಇದರಿಂದ ಉಳಿದ ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಮೇಲೆ ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.

AI-ಜನರೇಟೆಡ್ ಕೋಡ್‌ಗೆ ಏಕೆ ಪ್ಲೇಪೆನ್ (playpen) ಅಗತ್ಯ?

ಆಧುನಿಕ AI ಏಜೆಂಟ್‌ಗಳು ಕೇವಲ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುವುದಿಲ್ಲ. ಅವು ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ಬರೆಯುತ್ತವೆ, ವೆಬ್ ಅನ್ನು ಬ್ರೌಸ್ ಮಾಡುತ್ತವೆ, ಶೆಲ್ ಕಮಾಂಡ್‌ಗಳನ್ನು ರನ್ ಮಾಡುತ್ತವೆ ಮತ್ತು ವೆಬ್ ಸೇವೆಗಳನ್ನು ಸಹ ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಈ ಶಕ್ತಿಯು ಭದ್ರತಾ ಅಂತರವನ್ನು (security gap) ಸೃಷ್ಟಿಸುತ್ತದೆ: ಅವು ನೀಡುವ ಕೋಡ್‌ನಲ್ಲಿ ದೋಷಗಳಿರಬಹುದು (buggy), ಅದು ದುಷ್ಟತನದಿಂದ ಕೂಡಿದ್ದಿರಬಹುದು (malicious) ಅಥವಾ ಅತಿಯಾದ ಪ್ರಭಾವ ಬೀರಬಹುದು. ಅನುಮತಿಯಿಲ್ಲದೆ rm -rf / ಅನ್ನು ರನ್ ಮಾಡುವ ಅಥವಾ ಆಂತರಿಕ ಡೇಟಾಬೇಸ್‌ಗೆ ಕನೆಕ್ಟ್ ಆಗುವ ಏಜೆಂಟ್ ಇಡೀ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅಪಾಯಕ್ಕೆ ತಳ್ಳಬಹುದು.

ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಪ್ರತಿಯೊಂದು ಏಜೆಂಟ್ ಅನ್ನು ಅದರದೇ ಆದ ಕಂಟೇನರ್‌ನಲ್ಲಿ—ಅಂದರೆ ಒಂದು ಸಣ್ಣ, ಬಿಸಾಡಬಹುದಾದ ವರ್ಚುವಲ್ ಮೆಷಿನ್‌ನಲ್ಲಿ—ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ. ಏಜೆಂಟ್ ತಪ್ಪಾಗಿ ವರ್ತಿಸಿದರೆ, ಹಾನಿಯು ಆ ಕಂಟೇನರ್‌ನ ಒಳಗೇ ಇರುತ್ತದೆ; ಹೋಸ್ಟ್ ಮತ್ತು ಇತರ ವರ್ಕ್‌ಲೋಡ್‌ಗಳು ಸುರಕ್ಷಿತವಾಗಿರುತ್ತವೆ. ಹೊಸ GKE ಸೇವೆ ಮತ್ತು ಸಮುದಾಯದ ನೇತೃತ್ವದ ಪ್ರಾಜೆಕ್ಟ್ ಈ ಕಲ್ಪನೆಯನ್ನು ಬಳಸಲು ಸಿದ್ಧವಿರುವ ಸೇವೆಯನ್ನಾಗಿ ಪರಿವರ್ತಿಸುತ್ತವೆ.

ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಪಡೆಯಲು ಎರಡು ಮಾರ್ಗಗಳು

  • GKE Agent Sandbox – Google Cloud ಗ್ರಾಹಕರಿಗಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಮ್ಯಾನೇಜ್ಡ್ ಸೇವೆಯಾಗಿದೆ.
  • kubernetes-sigs/agent-sandbox – ಯಾವುದೇ Kubernetes ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ಇರುವ ಓಪನ್-ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ ಆಗಿದೆ.

ಇವೆರಡೂ ಸ್ಟ್ಯಾಂಡರ್ಡ್ Kubernetes primitives ಮೇಲೆ ನಿರ್ಮಿತವಾದ ಒಂದೇ ರೀತಿಯ ಕೋರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ಹೊಂದಿವೆ.

ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೇಗೆ ರೂಪಿಸಲಾಗಿದೆ

ಘಟಕ (Component) ಪಾತ್ರ (Role)
Sandbox ಏಜೆಂಟ್‌ನ ಕೋಡ್ ಅನ್ನು ರನ್ ಮಾಡುವ ಪ್ರತ್ಯೇಕವಾದ ಕಂಟೇನರ್. ಇದು ಸ್ಥಿರವಾದ ಹೆಸರು ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ ಪರ್ಸಿಸ್ಟೆಂಟ್ ಸ್ಟೋರೇಜ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ.
SandboxTemplate ಕಂಟೇನರ್ ಇಮೇಜ್ ಮತ್ತು ಸೆಕ್ಯೂರಿಟಿ ಪಾಲಿಸಿಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಬ್ಲೂಪ್ರಿಂಟ್—ಹೊಸ ಸ್ಯಾಂಡ್‌ಬಾಸ್‌ಗಳಿಗಾಗಿ ಇದು ಒಂದು ರೆಸಿಪಿ ಇದ್ದಂತೆ.
SandboxClaim ನಿರ್ದಿಷ್ಟ ಟೆಂಪ್ಲೇಟ್‌ನಿಂದ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಏಜೆಂಟ್ (ಅಥವಾ ಅದರ ಕಂಟ್ರೋಲರ್) ಮಾಡುವ ವಿನಂತಿ.
SandboxWarmPool ತಕ್ಷಣವೇ ನೀಡಲು ಸಿದ್ಧವಾಗಿರುವ ಮೊದಲೇ ಸೃಷ್ಟಿಸಲಾದ ಸ್ಯಾಂಡ್‌ಬಾಸ್‌ಗಳ ಪೂಲ್. ಕಂಟೇನರ್‌ಗಳನ್ನು 'warm' ಆಗಿ ಇರಿಸುವುದರಿಂದ ಪ್ರತಿ ಬಾರಿಯೂ ಇಮೇಜ್‌ಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುವ ಮತ್ತು ಹೊಸ ಪಾಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ವಿಳಂಬವನ್ನು (latency) ತಪ್ಪಿಸಬಹುದು.

ಏಜೆಂಟ್‌ಗೆ ಎನ್ವಿರಾನ್‌ಮೆಂಟ್ ಅಗತ್ಯವಿದ್ದಾಗ, ಅದು SandboxClaim ಅನ್ನು ಪೋಸ್ಟ್ ಮಾಡುತ್ತದೆ. ಕಂಟ್ರೋಲರ್ ವಾರ್ಮ್ ಪೂಲ್ ಅನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ, ಬಳಕೆಯಲ್ಲಿಲ್ಲದ (idle) ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಕ್ಲೈಮ್‌ಗೆ ಜೋಡಿಸುತ್ತದೆ. ಪೂಲ್ ಖಾಲಿಯಾಗಿದ್ದರೆ, ಅದು ಟೆಂಪ್ಲೇಟ್‌ನಿಂದ ಹೊಸ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ; ಇಲ್ಲದಿದ್ದರೆ ಹ್ಯಾಂಡ್‌ಆಫ್ ಪ್ರಕ್ರಿಯೆಯು ಮಿಲಿಸೆಕೆಂಡುಗಳಲ್ಲಿ ನಡೆಯುತ್ತದೆ.

ನೀವು ನಿಯಂತ್ರಿಸಬಹುದಾದ ಸೆಕ್ಯೂರಿಟಿ ಆಯ್ಕೆಗಳು

  • Default-deny networking – ಡಿಫಾಲ್ಟ್ ಆಗಿ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಆಂತರಿಕ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ. ಆಂತರಿಕ ಸೇವೆಗಳು ಅಕಸ್ಮಾತ್ ಬಹಿರಂಗಗೊಳ್ಳುವುದನ್ನು ತಡೆಯಲು, ಔಟ್‌ಬೌಂಡ್ ಅಥವಾ ಇನ್‌ಬೌಂಡ್ ಕನೆಕ್ಷನ್‌ಗಳನ್ನು ಅನುಮತಿಸಲು ನೀವು ಸ್ಪಷ್ಟ ನಿಯಮಗಳನ್ನು ಸೇರಿಸಬೇಕು.
  • Isolation levels – ನಿಮ್ಮ ರಿಸ್ಕ್ ಟಾಲರೆನ್ಸ್‌ಗೆ (risk tolerance) ಹೊಂದಿಕೆಯಾಗುವ ಕಂಟೇನರ್ ರನ್‌ಟೈಮ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿ:
    • ವೇಗಕ್ಕಾಗಿ Standard containers,
    • ಹೆಚ್ಚುವರಿ ಯೂಸರ್-ಸ್ಪೇಸ್ ಐಸೊಲೇಶನ್ ಲೇಯರ್ ಪಡೆಯಲು gVisor, ಅಥವಾ
    • ಲೈಟ್‌ವೇಟ್ VM ನಂತೆ ವರ್ತಿಸುವ ಹಾರ್ಡ್‌ವೇರ್-ಅಸಿಸ್ಟೆಡ್ ಐಸೊಲೇಶನ್‌ಗಾಗಿ Kata Containers.
  • SDKs – Python ಮತ್ತು Go ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಗಳು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಪ್ರೋಗ್ರಾಮ್ಯಾಟಿಕ್ ಆಗಿ ಸ್ಯಾಂಡ್‌ಬಾಸ್‌ಗಳನ್ನು ರಚಿಸಲು, ಕ್ಲೈಮ್ ಮಾಡಲು ಮತ್ತು ನಾಶಪಡಿಸಲು ಅನುಮತಿಸುತ್ತವೆ, ಇದು AI-ಚಾಲಿತ ಪೈಪ್‌ಲೈನ್‌ಗಳ ವರ್ಕ್‌ಫ್ಲೋಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ.

ಯಾರು ಪ್ರಯೋಜನ ಪಡೆಯುತ್ತಾರೆ ಮತ್ತು ಯಾರು ವಿರೋಧಿಸಬಹುದು

ಸಾರಾಂಶ

AI ಏಜೆಂಟ್‌ಗಳಿಗೆ ಅವರದೇ ಆದ ಡಿಸ್ಪೋಸಬಲ್ Linux ಬಾಕ್ಸ್ ನೀಡುವುದರಿಂದ AI-ಚಾಲಿತ ಆಟೊಮೇಷನ್‌ನಲ್ಲಿರುವ ಅತಿದೊಡ್ಡ ಅನಿಶ್ಚಿತತೆಯನ್ನು ಹೋಗಲಾಡಿಸಬಹುದು: ಅಂದರೆ ಜನರೇಟ್ ಮಾಡಿದ ಕೋಡ್ ಹೋಸ್ಟ್ ಅನ್ನು ಹಾಳುಮಾಡುವ ಅಪಾಯ. Google Cloud ನ ಮ್ಯಾನೇಜ್ಡ್ GKE Agent Sandbox ಮತ್ತು ಸಮುದಾಯದ ನೇತೃತ್ವದ kubernetes-sigs/agent-sandbox ಎರಡೂ ಕ್ಲೌಡ್-ನೇಟಿವ್ ಮತ್ತು ಆನ್-ಪ್ರೆಮ್ (on-prem) ಪರಿಸರಗಳಿಗೆ ಆ ಐಸೊಲೇಶನ್ ಅನ್ನು ಪ್ರಾಯೋಗಿಕವಾಗಿಸುತ್ತದೆ. ಚುರುಕುತನ (agility) ಮತ್ತು ಭದ್ರತೆಯ ನಡುವೆ ಸಮತೋಲನವನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಬೇಕಾದ ಸಂಸ್ಥೆಗಳು, AI-ಜನರೇಟೆಡ್ ಕೋಡ್ ಅನ್ನು ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಪ್ಲೇಪೆನ್‌ನಲ್ಲಿ ಇರಿಸಲು ಈಗ ಒಂದು ನಿರ್ದಿಷ್ಟವಾದ, Kubernetes-ನೇಟಿವ್ ಪರಿಕರವನ್ನು ಹೊಂದಿವೆ.