કુબરનેટ્સમાં સેકકોમ્પ: 7 વસ્તુઓ જે તમારે શરૂઆતથી જ જાણવાની જરૂર છે

નૉૅધ. અનુવાદ: અમે તમારા ધ્યાન પર બ્રિટિશ કંપની ASOS.com પર સિનિયર એપ્લીકેશન સિક્યુરિટી એન્જિનિયરના લેખનો અનુવાદ રજૂ કરીએ છીએ. તેની સાથે, તે seccomp ના ઉપયોગ દ્વારા કુબરનેટ્સમાં સુરક્ષા સુધારવા માટે સમર્પિત પ્રકાશનોની શ્રેણી શરૂ કરે છે. જો વાચકોને પરિચય ગમશે, તો અમે લેખકને અનુસરીશું અને આ વિષય પર તેમની ભાવિ સામગ્રીઓ સાથે ચાલુ રાખીશું.

જાદુ અને મેલીવિદ્યાનો આશરો લીધા વિના, SecDevOps ની ભાવનામાં seccomp પ્રોફાઇલ્સ કેવી રીતે બનાવવી તે અંગેની શ્રેણીબદ્ધ પોસ્ટ્સમાં આ લેખ પહેલો છે. ભાગ XNUMX માં, હું કુબરનેટ્સમાં seccomp અમલમાં મૂકવાની મૂળભૂત બાબતો અને આંતરિક વિગતો આવરી લઈશ.

કુબરનેટીસ ઇકોસિસ્ટમ કન્ટેનરને સુરક્ષિત અને અલગ કરવાની વિવિધ રીતો પ્રદાન કરે છે. આ લેખ સિક્યોર કમ્પ્યુટિંગ મોડ વિશે છે, જેને તરીકે પણ ઓળખવામાં આવે છે સેકમ્પ. તેનો સાર કન્ટેનર દ્વારા એક્ઝેક્યુશન માટે ઉપલબ્ધ સિસ્ટમ કૉલ્સને ફિલ્ટર કરવાનો છે.

શા માટે તે મહત્વનું છે? કન્ટેનર એ ચોક્કસ મશીન પર ચાલતી પ્રક્રિયા છે. અને તે અન્ય એપ્લિકેશન્સની જેમ કર્નલનો ઉપયોગ કરે છે. જો કન્ટેનર કોઈપણ સિસ્ટમ કૉલ્સ કરી શકે છે, તો બહુ જલ્દી માલવેર કન્ટેનર આઇસોલેશનને બાયપાસ કરવા અને અન્ય એપ્લિકેશનોને અસર કરવા માટે તેનો લાભ લેશે: માહિતી અટકાવવી, સિસ્ટમ સેટિંગ્સ બદલવી વગેરે.

seccomp રૂપરેખાઓ વ્યાખ્યાયિત કરે છે કે કઈ સિસ્ટમ કૉલ્સને મંજૂરી આપવી જોઈએ અથવા નિષ્ક્રિય કરવી જોઈએ. કન્ટેનર રનટાઇમ તેમને સક્રિય કરે છે જ્યારે તે શરૂ થાય છે જેથી કર્નલ તેમના અમલને મોનિટર કરી શકે. આવી રૂપરેખાઓનો ઉપયોગ કરવાથી તમે એટેક વેક્ટરને મર્યાદિત કરી શકો છો અને જો કન્ટેનરની અંદરનો કોઈપણ પ્રોગ્રામ (એટલે ​​​​કે, તમારી નિર્ભરતા અથવા તેમની અવલંબન) કંઈક એવું કરવાનું શરૂ કરે છે જે તેને કરવાની મંજૂરી નથી, તો નુકસાન ઘટાડવાની મંજૂરી આપે છે.

મૂળભૂત બાબતો મેળવવામાં

મૂળભૂત seccomp પ્રોફાઇલમાં ત્રણ ઘટકો શામેલ છે: defaultAction, architectures (અથવા archMap) અને syscalls:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "sched_yield",
                "futex",
                "write",
                "mmap",
                "exit_group",
                "madvise",
                "rt_sigprocmask",
                "getpid",
                "gettid",
                "tgkill",
                "rt_sigaction",
                "read",
                "getpgrp"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

(medium-basic-seccomp.json)

defaultAction વિભાગમાં ઉલ્લેખિત ન હોય તેવા કોઈપણ સિસ્ટમ કૉલનું ડિફોલ્ટ ભાવિ નક્કી કરે છે syscalls. વસ્તુઓને સરળ બનાવવા માટે, ચાલો બે મુખ્ય મૂલ્યો પર ધ્યાન કેન્દ્રિત કરીએ જેનો ઉપયોગ કરવામાં આવશે:

• SCMP_ACT_ERRNO - સિસ્ટમ કૉલના અમલને અવરોધે છે,
• SCMP_ACT_ALLOW - પરવાનગી આપે છે.

કલમ architectures લક્ષ્ય આર્કિટેક્ચર સૂચિબદ્ધ છે. આ અગત્યનું છે કારણ કે ફિલ્ટર પોતે, કર્નલ સ્તરે લાગુ થાય છે, સિસ્ટમ કૉલ ઓળખકર્તાઓ પર આધાર રાખે છે, અને પ્રોફાઇલમાં ઉલ્લેખિત તેમના નામો પર નહીં. ઉપયોગ કરતા પહેલા કન્ટેનર રનટાઈમ તેમને ઓળખકર્તાઓ સાથે મેચ કરશે. વિચાર એ છે કે સિસ્ટમ આર્કિટેક્ચરના આધારે સિસ્ટમ કૉલ્સમાં સંપૂર્ણપણે અલગ ID હોઈ શકે છે. ઉદાહરણ તરીકે, સિસ્ટમ કૉલ recvfrom (સોકેટમાંથી માહિતી મેળવવા માટે વપરાય છે) પાસે x64 સિસ્ટમ પર ID = 64 અને x517 પર ID = 86 છે. તે તમે x86-x64 આર્કિટેક્ચર માટે તમામ સિસ્ટમ કૉલ્સની સૂચિ શોધી શકો છો.

વિભાગમાં syscalls બધા સિસ્ટમ કૉલ્સની યાદી આપે છે અને તેમની સાથે શું કરવું તે સ્પષ્ટ કરે છે. ઉદાહરણ તરીકે, તમે સેટિંગ કરીને વ્હાઇટલિસ્ટ બનાવી શકો છો defaultAction પર SCMP_ACT_ERRNO, અને વિભાગમાં કૉલ કરો syscalls સોંપવું SCMP_ACT_ALLOW. આમ, તમે વિભાગમાં ઉલ્લેખિત કૉલ્સને જ મંજૂરી આપો છો syscalls, અને બીજા બધાને પ્રતિબંધિત કરો. બ્લેકલિસ્ટ માટે તમારે મૂલ્યો બદલવી જોઈએ defaultAction અને વિરુદ્ધ ક્રિયાઓ.

હવે આપણે ઘોંઘાટ વિશે થોડાક શબ્દો કહેવા જોઈએ જે એટલા સ્પષ્ટ નથી. મહેરબાની કરીને નોંધ કરો કે નીચે આપેલી ભલામણો ધારે છે કે તમે કુબરનેટ્સ પર વ્યવસાયિક એપ્લિકેશનોની લાઇન જમાવી રહ્યાં છો અને તમે ઇચ્છો છો કે તે શક્ય તેટલા ઓછા વિશેષાધિકારો સાથે ચાલે.

1. AllowPrivilegeEscalation=false

В securityContext કન્ટેનર એક પરિમાણ ધરાવે છે AllowPrivilegeEscalation. જો તે માં સ્થાપિત થયેલ છે false, કન્ટેનર સાથે શરૂ થશે (on) બીટ no_new_priv. આ પરિમાણનો અર્થ નામ પરથી સ્પષ્ટ છે: તે કન્ટેનરને તેના કરતા વધુ વિશેષાધિકારો સાથે નવી પ્રક્રિયાઓ શરૂ કરવાથી અટકાવે છે.

આ વિકલ્પની આડઅસર સેટ કરવામાં આવી રહી છે true (ડિફૉલ્ટ) એ છે કે કન્ટેનર રનટાઇમ સ્ટાર્ટઅપ પ્રક્રિયાની શરૂઆતમાં જ seccomp પ્રોફાઇલને લાગુ કરે છે. આમ, આંતરિક રનટાઇમ પ્રક્રિયાઓ ચલાવવા માટે જરૂરી તમામ સિસ્ટમ કૉલ્સ (દા.ત. વપરાશકર્તા/જૂથ ID સેટ કરવા, અમુક ક્ષમતાઓ છોડવી) પ્રોફાઇલમાં સક્ષમ હોવા જોઈએ.

એક કન્ટેનર કે જે તુચ્છ વસ્તુઓ કરે છે echo hi, નીચેની પરવાનગીઓની જરૂર પડશે:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "brk",
                "capget",
                "capset",
                "chdir",
                "close",
                "execve",
                "exit_group",
                "fstat",
                "fstatfs",
                "futex",
                "getdents64",
                "getppid",
                "lstat",
                "mprotect",
                "nanosleep",
                "newfstatat",
                "openat",
                "prctl",
                "read",
                "rt_sigaction",
                "statfs",
                "setgid",
                "setgroups",
                "setuid",
                "stat",
                "uname",
                "write"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

(hi-pod-seccomp.json)

...આના બદલે:

{
    "defaultAction": "SCMP_ACT_ERRNO",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "brk",
                "close",
                "execve",
                "exit_group",
                "futex",
                "mprotect",
                "nanosleep",
                "stat",
                "write"
            ],
            "action": "SCMP_ACT_ALLOW"
        }
    ]
}

(hi-container-seccomp.json)

પરંતુ ફરીથી, શા માટે આ સમસ્યા છે? વ્યક્તિગત રીતે, હું નીચેના સિસ્ટમ કૉલ્સને વ્હાઇટલિસ્ટ કરવાનું ટાળીશ (સિવાય કે તેમની વાસ્તવિક જરૂરિયાત હોય): capset, set_tid_address, setgid, setgroups и setuid. જો કે, વાસ્તવિક પડકાર એ છે કે પ્રક્રિયાઓને મંજૂરી આપીને કે જેના પર તમારું સંપૂર્ણ નિયંત્રણ નથી, તમે કન્ટેનર રનટાઇમ અમલીકરણ સાથે પ્રોફાઇલ્સને જોડી રહ્યાં છો. બીજા શબ્દોમાં કહીએ તો, એક દિવસ તમે જોશો કે કન્ટેનર રનટાઇમ એન્વાયર્નમેન્ટ અપડેટ કર્યા પછી (ક્યાં તો તમારા દ્વારા અથવા, વધુ સંભવ છે, ક્લાઉડ સેવા પ્રદાતા દ્વારા), કન્ટેનર અચાનક ચાલવાનું બંધ કરી દે છે.

ટીપ # 1: સાથે કન્ટેનર ચલાવો AllowPrivilegeEscaltion=false. આ seccomp પ્રોફાઇલ્સનું કદ ઘટાડશે અને કન્ટેનર રનટાઇમ પર્યાવરણમાં થતા ફેરફારો માટે તેમને ઓછા સંવેદનશીલ બનાવશે.

2. કન્ટેનર લેવલ પર સેકકોમ્પ પ્રોફાઇલ સેટ કરવી

seccomp પ્રોફાઇલ પોડ સ્તર પર સેટ કરી શકાય છે:

annotations:
  seccomp.security.alpha.kubernetes.io/pod: "localhost/profile.json"

...અથવા કન્ટેનર સ્તર પર:

annotations:
  container.security.alpha.kubernetes.io/<container-name>: "localhost/profile.json"

મહેરબાની કરીને નોંધ કરો કે જ્યારે Kubernetes seccomp ત્યારે ઉપરોક્ત વાક્યરચના બદલાશે GA બનશે (આ ઘટના Kubernetes - 1.18 - આશરે અનુવાદની આગામી પ્રકાશનમાં અપેક્ષિત છે).

બહુ ઓછા લોકો જાણે છે કે કુબરનેટ્સ હંમેશા ધરાવે છે ભૂલજેના કારણે seccomp રૂપરેખાઓ લાગુ થઈ થોભો કન્ટેનર. રનટાઈમ પર્યાવરણ આંશિક રીતે આ ખામીને વળતર આપે છે, પરંતુ આ કન્ટેનર શીંગોમાંથી અદૃશ્ય થતું નથી, કારણ કે તેનો ઉપયોગ તેમના ઈન્ફ્રાસ્ટ્રક્ચરને ગોઠવવા માટે થાય છે.

સમસ્યા એ છે કે આ કન્ટેનર હંમેશા સાથે શરૂ થાય છે AllowPrivilegeEscalation=true, ફકરા 1 માં રજૂ કરવામાં આવેલી સમસ્યાઓ તરફ દોરી જાય છે, અને આ બદલી શકાતી નથી.

કન્ટેનર સ્તરે seccomp પ્રોફાઇલ્સનો ઉપયોગ કરીને, તમે આ મુશ્કેલીને ટાળી શકો છો અને ચોક્કસ કન્ટેનરને અનુરૂપ પ્રોફાઇલ બનાવી શકો છો. વિકાસકર્તાઓ બગને ઠીક કરે અને નવું સંસ્કરણ (કદાચ 1.18?) દરેક માટે ઉપલબ્ધ ન થાય ત્યાં સુધી આ કરવાનું રહેશે.

ટીપ # 2: કન્ટેનર સ્તર પર seccomp પ્રોફાઇલ્સ સેટ કરો.

વ્યવહારિક અર્થમાં, આ નિયમ સામાન્ય રીતે પ્રશ્નના સાર્વત્રિક જવાબ તરીકે સેવા આપે છે: “મારી સેકકોમ્પ પ્રોફાઇલ શા માટે કામ કરે છે docker runપરંતુ કુબરનેટ્સ ક્લસ્ટરમાં જમાવ્યા પછી કામ કરતું નથી?

3. માત્ર છેલ્લા ઉપાય તરીકે રનટાઇમ/ડિફોલ્ટનો ઉપયોગ કરો

બિલ્ટ-ઇન પ્રોફાઇલ્સ માટે કુબરનેટ્સ પાસે બે વિકલ્પો છે: runtime/default и docker/default. બંને કન્ટેનર રનટાઇમ દ્વારા લાગુ કરવામાં આવે છે, કુબરનેટ્સ દ્વારા નહીં. તેથી, ઉપયોગમાં લેવાતા રનટાઇમ એન્વાયર્નમેન્ટ અને તેના વર્ઝનના આધારે તેઓ અલગ હોઈ શકે છે.

બીજા શબ્દોમાં કહીએ તો, રનટાઇમ બદલવાના પરિણામે, કન્ટેનર પાસે સિસ્ટમ કૉલ્સના અલગ સેટની ઍક્સેસ હોઈ શકે છે, જેનો તે ઉપયોગ કરી શકે છે અથવા ન પણ કરી શકે છે. મોટાભાગના રનટાઇમ્સનો ઉપયોગ થાય છે ડોકર અમલીકરણ. જો તમે આ પ્રોફાઇલનો ઉપયોગ કરવા માંગતા હો, તો કૃપા કરીને ખાતરી કરો કે તે તમારા માટે યોગ્ય છે.

પ્રોફાઇલ docker/default Kubernetes 1.11 થી નાપસંદ કરવામાં આવ્યું છે, તેથી તેનો ઉપયોગ કરવાનું ટાળો.

મારા મતે, પ્રોફાઇલ runtime/default જે હેતુ માટે તે બનાવવામાં આવ્યું હતું તેના માટે સંપૂર્ણ રીતે અનુકૂળ છે: આદેશ ચલાવવા સાથે સંકળાયેલા જોખમોથી વપરાશકર્તાઓનું રક્ષણ કરવું docker run તેમની કાર પર. જો કે, જ્યારે કુબરનેટ્સ ક્લસ્ટરો પર ચાલતી વ્યવસાયિક એપ્લિકેશનોની વાત આવે છે, ત્યારે હું એવી દલીલ કરવાની હિંમત કરીશ કે આવી પ્રોફાઇલ ખૂબ ખુલ્લી છે અને વિકાસકર્તાઓએ તેમની એપ્લિકેશનો (અથવા એપ્લિકેશનના પ્રકારો) માટે પ્રોફાઇલ્સ બનાવવા પર ધ્યાન કેન્દ્રિત કરવું જોઈએ.

ટીપ # 3: ચોક્કસ એપ્લિકેશનો માટે seccomp પ્રોફાઇલ્સ બનાવો. જો આ શક્ય ન હોય તો, એપ્લિકેશન પ્રકારો માટે પ્રોફાઇલ્સ બનાવો, ઉદાહરણ તરીકે, એક અદ્યતન પ્રોફાઇલ બનાવો જેમાં ગોલાંગ એપ્લિકેશનના તમામ વેબ API શામેલ હોય. માત્ર છેલ્લા ઉપાય તરીકે રનટાઇમ/ડિફોલ્ટનો ઉપયોગ કરો.

ભવિષ્યની પોસ્ટ્સમાં, હું SecDevOps-પ્રેરિત seccomp પ્રોફાઇલ્સ કેવી રીતે બનાવવી, તેમને સ્વચાલિત કરવા અને પાઇપલાઇન્સમાં તેનું પરીક્ષણ કેવી રીતે કરવું તે આવરી લઈશ. બીજા શબ્દોમાં કહીએ તો, તમારી પાસે એપ્લિકેશન-વિશિષ્ટ પ્રોફાઇલ્સમાં અપગ્રેડ ન થવાનું કોઈ બહાનું નથી.

4. અમર્યાદિત એ વિકલ્પ નથી.

ના પ્રથમ કુબરનેટ્સ સુરક્ષા ઓડિટ તે મૂળભૂત રીતે બહાર આવ્યું છે seccomp અક્ષમ. મતલબ કે જો તમે સેટ ન કરો PodSecurityPolicy, જે તેને ક્લસ્ટરમાં સક્ષમ કરશે, બધા પોડ્સ કે જેના માટે seccomp પ્રોફાઇલ વ્યાખ્યાયિત નથી તેમાં કામ કરશે. seccomp=unconfined.

આ મોડમાં કામ કરવાનો અર્થ એ છે કે ઇન્સ્યુલેશનનો એક સંપૂર્ણ સ્તર ખોવાઈ ગયો છે જે ક્લસ્ટરને સુરક્ષિત કરે છે. સુરક્ષા નિષ્ણાતો દ્વારા આ અભિગમની ભલામણ કરવામાં આવતી નથી.

ટીપ # 4: ક્લસ્ટરમાં કોઈ કન્ટેનર અંદર ચાલતું હોવું જોઈએ નહીં seccomp=unconfined, ખાસ કરીને ઉત્પાદન વાતાવરણમાં.

5. "ઓડિટ મોડ"

આ બિંદુ કુબરનેટ્સ માટે અનન્ય નથી, પરંતુ તેમ છતાં તે "શરૂ કરતા પહેલા જાણવા જેવી બાબતો" શ્રેણીમાં આવે છે.

જેમ તેમ થાય છે તેમ, seccomp પ્રોફાઇલ્સ બનાવવી હંમેશા પડકારજનક રહી છે અને ટ્રાયલ અને એરર પર ખૂબ આધાર રાખે છે. હકીકત એ છે કે વપરાશકર્તાઓ પાસે એપ્લિકેશનને "ડ્રોપ" કરવાનું જોખમ લીધા વિના ઉત્પાદન વાતાવરણમાં તેનું પરીક્ષણ કરવાની તક નથી.

Linux કર્નલ 4.14 ના પ્રકાશન પછી, પ્રોફાઇલના ભાગોને ઓડિટ મોડમાં ચલાવવાનું શક્ય બન્યું, syslog માં તમામ સિસ્ટમ કૉલ્સ વિશેની માહિતી રેકોર્ડ કરવી, પરંતુ તેમને અવરોધિત કર્યા વિના. તમે પરિમાણનો ઉપયોગ કરીને આ મોડને સક્રિય કરી શકો છો SCMT_ACT_LOG:

SCMP_ACT_LOG: seccomp સિસ્ટમ કૉલ કરવા માટેના થ્રેડને અસર કરશે નહીં જો તે ફિલ્ટરમાં કોઈપણ નિયમ સાથે મેળ ખાતું નથી, પરંતુ સિસ્ટમ કૉલ વિશેની માહિતી લૉગ કરવામાં આવશે.

આ સુવિધાનો ઉપયોગ કરવા માટે અહીં એક લાક્ષણિક વ્યૂહરચના છે:

1. સિસ્ટમ કૉલ્સને મંજૂરી આપો જે જરૂરી છે.
2. તમે જાણો છો તે સિસ્ટમમાંથી કૉલ્સને અવરોધિત કરો ઉપયોગી થશે નહીં.
3. લોગમાં અન્ય તમામ કોલ્સ વિશેની માહિતી રેકોર્ડ કરો.

એક સરળ ઉદાહરણ આના જેવું લાગે છે:

{
    "defaultAction": "SCMP_ACT_LOG",
    "architectures": [
        "SCMP_ARCH_X86_64",
        "SCMP_ARCH_X86",
        "SCMP_ARCH_X32"
    ],
    "syscalls": [
        {
            "names": [
                "arch_prctl",
                "sched_yield",
                "futex",
                "write",
                "mmap",
                "exit_group",
                "madvise",
                "rt_sigprocmask",
                "getpid",
                "gettid",
                "tgkill",
                "rt_sigaction",
                "read",
                "getpgrp"
            ],
            "action": "SCMP_ACT_ALLOW"
        },
        {
            "names": [
                "add_key",
                "keyctl",
                "ptrace"
            ],
            "action": "SCMP_ACT_ERRNO"
        }
    ]
}

(મધ્યમ-મિશ્રિત-seccomp.json)

પરંતુ યાદ રાખો કે તમારે એવા બધા કૉલ્સને અવરોધિત કરવાની જરૂર છે જેનો તમે ઉપયોગ કરશો નહીં અને તે ક્લસ્ટરને સંભવિત રીતે નુકસાન પહોંચાડી શકે છે. યાદી તૈયાર કરવા માટેનો એક સારો આધાર સત્તાવાર છે ડોકર દસ્તાવેજીકરણ. તે વિગતવાર સમજાવે છે કે ડિફોલ્ટ પ્રોફાઇલમાં કયા સિસ્ટમ કૉલ્સ અવરોધિત છે અને શા માટે.

જો કે, ત્યાં એક કેચ છે. જોકે SCMT_ACT_LOG 2017 ના અંતથી લિનક્સ કર્નલ દ્વારા સમર્થિત, તે પ્રમાણમાં તાજેતરમાં જ કુબરનેટ્સ ઇકોસિસ્ટમમાં પ્રવેશ્યું. તેથી, આ પદ્ધતિનો ઉપયોગ કરવા માટે તમારે Linux કર્નલ 4.14 અને runC વર્ઝનની જરૂર પડશે v1.0.0-rc9.

ટીપ # 5: ઉત્પાદનમાં પરીક્ષણ માટે ઓડિટ મોડ પ્રોફાઇલ બ્લેક એન્ડ વ્હાઇટ લિસ્ટને જોડીને બનાવી શકાય છે અને તમામ અપવાદોને લૉગ કરી શકાય છે.

6. વ્હાઇટલિસ્ટનો ઉપયોગ કરો

વ્હાઇટલિસ્ટિંગ માટે વધારાના પ્રયત્નોની જરૂર છે કારણ કે તમારે દરેક કૉલને ઓળખવો પડશે જેની એપ્લિકેશનને જરૂર પડી શકે છે, પરંતુ આ અભિગમ સુરક્ષાને મોટા પ્રમાણમાં સુધારે છે:

વ્હાઇટલિસ્ટ અભિગમનો ઉપયોગ કરવાની ખૂબ ભલામણ કરવામાં આવે છે કારણ કે તે સરળ અને વધુ વિશ્વસનીય છે. જ્યારે પણ સંભવિત જોખમી સિસ્ટમ કૉલ (અથવા જો તે બ્લેકલિસ્ટમાં હોય તો ખતરનાક ફ્લેગ/વિકલ્પ) ઉમેરવામાં આવે ત્યારે બ્લેકલિસ્ટને અપડેટ કરવાની જરૂર પડશે. વધુમાં, પરિમાણની રજૂઆતને તેના સારને બદલ્યા વિના બદલવાનું અને ત્યાંથી બ્લેકલિસ્ટના પ્રતિબંધોને બાયપાસ કરવું ઘણીવાર શક્ય છે.

ગો એપ્લીકેશન માટે, મેં એક ખાસ સાધન વિકસાવ્યું છે જે એપ્લિકેશન સાથે છે અને એક્ઝેક્યુશન દરમિયાન કરવામાં આવેલ તમામ કોલ્સ એકત્રિત કરે છે. ઉદાહરણ તરીકે, નીચેની એપ્લિકેશન માટે:

package main

import "fmt"

func main() {
	fmt.Println("test")
}

... ચાલો લોન્ચ કરીએ gosystract તેથી

go install https://github.com/pjbgf/gosystract
gosystract --template='{{- range . }}{{printf ""%s",n" .Name}}{{- end}}' application-path

... અને અમને નીચેનું પરિણામ મળે છે:

"sched_yield",
"futex",
"write",
"mmap",
"exit_group",
"madvise",
"rt_sigprocmask",
"getpid",
"gettid",
"tgkill",
"rt_sigaction",
"read",
"getpgrp",
"arch_prctl",

હમણાં માટે, આ માત્ર એક ઉદાહરણ છે—ટૂલ્સ વિશે વધુ વિગતો અનુસરવામાં આવશે.

ટીપ # 6: ફક્ત તે જ કૉલ્સને મંજૂરી આપો જેની તમને ખરેખર જરૂર હોય અને અન્ય તમામને અવરોધિત કરો.

7. યોગ્ય પાયો નાખો (અથવા અનપેક્ષિત વર્તન માટે તૈયારી કરો)

કર્નલ તમે તેમાં શું લખો છો તેના પર ધ્યાન આપ્યા વિના રૂપરેખાને લાગુ કરશે. ભલે તે તમને જે જોઈએ તે બરાબર ન હોય. ઉદાહરણ તરીકે, જો તમે જેવા કૉલ્સની ઍક્સેસને અવરોધિત કરો છો exit અથવા exit_group, કન્ટેનર યોગ્ય રીતે બંધ કરી શકશે નહીં અને એક સરળ આદેશ પણ echo hi તેને અટકી દોo અનિશ્ચિત સમય માટે. પરિણામે, તમને ક્લસ્ટરમાં ઉચ્ચ CPU વપરાશ મળશે:

આવા કિસ્સાઓમાં, ઉપયોગિતા બચાવમાં આવી શકે છે strace - તે બતાવશે કે સમસ્યા શું હોઈ શકે છે:

sudo strace -c -p 9331

ખાતરી કરો કે રૂપરેખાઓ એ તમામ સિસ્ટમ કોલ્સ ધરાવે છે જેની એપ્લિકેશનને રનટાઈમ પર જરૂર હોય છે.

ટીપ # 7: વિગત પર ધ્યાન આપો અને ખાતરી કરો કે તમામ જરૂરી સિસ્ટમ કોલ્સ વ્હાઇટલિસ્ટેડ છે.

આ SecDevOps ની ભાવનામાં Kubernetes માં seccomp નો ઉપયોગ કરવા પરના લેખોની શ્રેણીના પ્રથમ ભાગને સમાપ્ત કરે છે. નીચેના ભાગોમાં આપણે આ શા માટે મહત્વપૂર્ણ છે અને પ્રક્રિયાને કેવી રીતે સ્વચાલિત કરવી તે વિશે વાત કરીશું.

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર પણ વાંચો:

• «ડોકર કન્ટેનર માટે સુરક્ષા»;
• «33+ કુબરનેટ્સ સુરક્ષા સાધનો»;
• «ડોકર અને કુબરનેટ્સ સુરક્ષાની માંગ કરતા વાતાવરણમાં»;
• «કુબરનેટ્સ સુરક્ષા માટે 9 શ્રેષ્ઠ પ્રયાસો».

સોર્સ: www.habr.com