Google Cloud એ મેનેજ્ડ GKE Agent Sandbox સેવા રજૂ કરી છે, જ્યારે ઓપન-સોર્સ kubernetes-sigs/agent-sandbox પ્રોજેક્ટ કોઈપણ Kubernetes ક્લસ્ટર માટે સમાન ક્ષમતા લાવે છે. બંને ડેવલપર્સને AI એજન્ટ્સ માટે એક ડિસ્પોઝેબલ (એકવાર વાપરી શકાય તેવું) Linux કન્ટેનર આપે છે, જેનાથી બાકીનું ઇન્ફ્રાસ્ટ્રક્ચર અસ્પૃશ્ય રહે છે.
શા માટે AI-જનરેટેડ કોડને પ્લેપેન (playpen) ની જરૂર છે
આધુનિક AI એજન્ટ્સ માત્ર પ્રશ્નોના જવાબ જ નથી આપતા. તેઓ સ્ક્રિપ્ટ લખે છે, વેબ બ્રાઉઝ કરે છે, શેલ કમાન્ડ્સ ચલાવે છે અને વેબ સેવાઓ પણ શરૂ કરે છે. આ શક્તિ સુરક્ષામાં ખામી (security gap) ઊભી કરે છે: તેઓ દ્વારા જનરેટ થયેલો કોડ બગવાવાળો (buggy), દૂષિત (malicious) અથવા અત્યંત આક્રમક હોઈ શકે છે. એવો એજન્ટ જે rm -rf / ચલાવે છે અથવા પરવાનગી વિના આંતરિક ડેટાબેઝ સાથે જોડાય છે તે આખા સિસ્ટમને જોખમમાં મૂકી શકે છે.
સેન્ડબોક્સ દરેક એજન્ટને તેના પોતાના કન્ટેનરમાં અલગ કરે છે—એક નાનું, ફેંકી શકાય તેવું (throw-away) વર્ચ્યુઅલ મશીન. જો એજન્ટ ખોટું વર્તન કરે, તો નુકસાન તે કન્ટેનરની અંદર જ રહે છે; હોસ્ટ અને અન્ય વર્કલોડ સુરક્ષિત રહે છે. નવી GKE ઓફરિંગ અને સમુદાય-સંચાલિત પ્રોજેક્ટ આ વિચારને તૈયાર-થી-ઉપયોગમાં લઈ શકાય તેવી સેવામાં ફેરવે છે.
સેન્ડબોક્સ મેળવવાની બે રીતો
- GKE Agent Sandbox – Google Cloud ગ્રાહકો માટે સંપૂર્ણ રીતે મેનેજ્ડ સેવા.
kubernetes-sigs/agent-sandbox– કોઈપણ Kubernetes ક્લસ્ટર માટે ઓપન-સોર્સ પ્રોજેક્ટ.
બંને સમાન મુખ્ય આર્કિટેક્ચર ધરાવે છે, જે સ્ટાન્ડર્ડ Kubernetes primitives પર બનેલું છે.
સિસ્ટમ કેવી રીતે બનાવવામાં આવી છે
| ઘટક (Component) | ભૂમિકા (Role) |
|---|---|
| Sandbox | અલગ કરેલું કન્ટેનર જે એજન્ટનો કોડ ચલાવે છે. જો જરૂર હોય તો તેનું સ્થિર નામ અને પર્સિસ્ટન્ટ સ્ટોરેજ હોય છે. |
| SandboxTemplate | એક બ્લુપ્રિન્ટ જે કન્ટેનર ઈમેજ અને સુરક્ષા નીતિઓને વ્યાખ્યાયિત કરે છે—નવા સેન્ડબોક્સ માટે એક રેસીપી. |
| SandboxClaim | ચોક્કસ ટેમ્પલેટમાંથી સેન્ડબોક્સ શરૂ કરવા માટે એજન્ટ (અથવા તેના કંટ્રોલર) દ્વારા કરવામાં આવેલી વિનંતી. |
| SandboxWarmPool | પૂર્વ-નિર્મિત સેન્ડબોક્સનો સમૂહ જે તરત જ આપવા માટે તૈયાર હોય છે. કન્ટેનરને 'વોર્મ' રાખવાથી દરેક વખતે ઈમેજ પુલ કરવાની અને નવો પોડ (pod) શરૂ કરવાની લેટન્સી (વિલંબ) ટાળી શકાય છે. |
જ્યારે એજન્ટને એન્વાયરમેન્ટની જરૂર હોય છે, ત્યારે તે SandboxClaim પોસ્ટ કરે છે. કંટ્રોલર વોર્મ પૂલ તપાસે છે, એક ખાલી (idle) સેન્ડબોક્સ પસંદ કરે છે, અને તેને ક્લેમ સાથે જોડે છે. જો પૂલ ખાલી હોય, તો તે ટેમ્પલેટમાંથી નવું સેન્ડબોક્સ બનાવે છે; અન્યથા, આ પ્રક્રિયા મિલીસેકન્ડમાં પૂર્ણ થાય છે.
સુરક્ષા માટેના વિકલ્પો (Security knobs) જે તમે બદલી શકો છો
- Default-deny networking – ડિફોલ્ટ રીતે સેન્ડબોક્સ આંતરિક નેટવર્ક સુધી પહોંચી શકતું નથી. આઉટબાઉન્ડ અથવા ઇનબાઉન્ડ કનેક્શનની મંજૂરી આપવા માટે તમારે સ્પષ્ટ નિયમો ઉમેરવા પડશે, જે આંતરિક સેવાઓના અકસ્માતે એક્સપોઝરને અટકાવે છે.
- Isolation levels – તમારી જોખમ સહન કરવાની ક્ષમતા (risk tolerance) મુજબ કન્ટેનર રનટાઇમ પસંદ કરો:
- ઝડપ માટે સ્ટાન્ડર્ડ કન્ટેનર્સ,
- વધારાના યુઝર-સ્પેસ આઇસોલેશન લેયર માટે gVisor, અથવા
- હાર્ડવેર-આસિસ્ટેડ આઇસોલેશન માટે Kata Containers જે લાઇટવેઇટ VM ની જેમ કામ કરે છે.
- SDKs – Python અને Go ક્લાયન્ટ લાઇબ્રેરીઝ ડેવલપર્સને પ્રોગ્રામમેટિકલી સેન્ડબોક્સ બનાવવા, ક્લેમ કરવા અને નાશ કરવા દે છે, જે AI-સંચાલિત પાઇપલાઇન્સના વર્કફ્લો સાથે સુસંગત છે.
કોને ફાયદો થાય છે, અને કોણ વિરોધ કરી શકે છે
નિષ્કર્ષ (Bottom line)
AI એજન્ટ્સને તેમનું પોતાનું ડિસ્પોઝેબલ Linux બોક્સ આપવાથી AI-સંચાલિત ઓટોમેશનમાંથી સૌથી મોટું અનિશ્ચિત પરિબળ દૂર થાય છે: જનરેટ થયેલો કોડ હોસ્ટને નુકસાન પહોંચાડશે તેવો જોખમ. Google Cloud ની મેનેજ્ડ GKE Agent Sandbox અને સમુદાય દ્વારા સંચાલિત kubernetes-sigs/agent-sandbox ક્લાઉડ-નેટિવ અને ઓન-પ્રેમ (on-prem) બંને વાતાવરણ માટે તે આઇસોલેશનને વ્યવહારુ બનાવે છે. જે સંસ્થાઓએ ચપળતા (agility) અને સુરક્ષા વચ્ચે સંતુલન જાળવવાની જરૂર છે, તેમની પાસે હવે AI-જનરેટેડ કોડને સેન્ડબોક્સ પ્લેપેનમાં રાખવા માટે એક નક્કર, Kubernetes-નેટિવ સાધન છે.