Kubernetes හි Seccomp: ඔබ මුල සිටම දැනගත යුතු කරුණු 7ක්

සටහන. පරිවර්තනය.: අපි ඔබේ අවධානයට ඉදිරිපත් කරන්නේ බ්‍රිතාන්‍ය සමාගමක් වන ASOS.com හි ජ්‍යෙෂ්ඨ යෙදුම් ආරක්ෂක ඉංජිනේරුවරයෙකුගේ ලිපියක පරිවර්තනයයි. එය සමඟ, ඔහු seccomp භාවිතයෙන් Kubernetes හි ආරක්ෂාව වැඩි දියුණු කිරීම සඳහා කැප වූ ප්‍රකාශන මාලාවක් ආරම්භ කරයි. පාඨකයන් හැඳින්වීමට කැමති නම්, අපි කතුවරයා අනුගමනය කර මෙම මාතෘකාව පිළිබඳ ඔහුගේ අනාගත ද්රව්ය සමඟ ඉදිරියට යන්නෙමු.

මෙම ලිපිය මැජික් සහ මන්තර ගුරුකම් වලට යොමු නොවී, SecDevOps හි ආත්මය තුළ seccomp පැතිකඩ නිර්මාණය කරන්නේ කෙසේද යන්න පිළිබඳ පළ කිරීම් මාලාවක පළමු ලිපියයි. XNUMX කොටසේදී, මම Kubernetes හි seccomp ක්‍රියාත්මක කිරීමේ මූලික කරුණු සහ අභ්‍යන්තර තොරතුරු ආවරණය කරමි.

Kubernetes පරිසර පද්ධතිය බහාලුම් සුරක්ෂිත කිරීමට සහ හුදකලා කිරීමට විවිධ ක්‍රම ඉදිරිපත් කරයි. ලිපිය Secure Computing Mode, ලෙසද හැඳින්වේ 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"
        }
    ]
}

(මධ්යම-මූලික-seccomp.json)

defaultAction කොටසෙහි නිශ්චිතව දක්වා නොමැති ඕනෑම පද්ධති ඇමතුමක පෙරනිමි ඉරණම තීරණය කරයි syscalls. දේවල් පහසු කිරීම සඳහා, භාවිතා කරන ප්‍රධාන අගයන් දෙක කෙරෙහි අවධානය යොමු කරමු:

• SCMP_ACT_ERRNO - පද්ධති ඇමතුමක් ක්‍රියාත්මක කිරීම අවහිර කරයි,
• SCMP_ACT_ALLOW - ඉඩ දෙයි.

කොටස architectures ඉලක්ක ගෘහ නිර්මාණ ශිල්පය ලැයිස්තුගත කර ඇත. මෙය වැදගත් වන්නේ කර්නල් මට්ටමින් යෙදෙන පෙරණයම රඳා පවතින්නේ පද්ධති ඇමතුම් හඳුනාගැනීම් මත මිස පැතිකඩෙහි දක්වා ඇති නම් මත නොවන බැවිනි. බහාලුම් ධාවන කාලය ඒවා භාවිතයට පෙර හඳුනාගැනීම් වලට ගැලපේ. අදහස නම් පද්ධති ආකිටෙක්චර් මත පදනම්ව පද්ධති ඇමතුම්වලට සම්පූර්ණයෙන්ම වෙනස් හැඳුනුම්පත් තිබිය හැකි බවයි. උදාහරණයක් ලෙස, පද්ධති ඇමතුම recvfrom (සොකට් එකෙන් තොරතුරු ලබා ගැනීමට භාවිතා කරයි) x64 පද්ධතිවල ID = 64 සහ x517 මත ID = 86 ඇත. එය ඔබට x86-x64 ගෘහ නිර්මාණ ශිල්පය සඳහා සියලුම පද්ධති ඇමතුම් ලැයිස්තුවක් සොයාගත හැකිය.

කොටසේ syscalls සියලුම පද්ධති ඇමතුම් ලැයිස්තුගත කර ඒවා සමඟ කළ යුතු දේ නියම කරයි. උදාහරණයක් ලෙස, සැකසීමෙන් ඔබට සුදු ලැයිස්තුවක් සෑදිය හැක defaultAction මත SCMP_ACT_ERRNO, සහ කොටසේ ඇමතුම් syscalls පැවරීම SCMP_ACT_ALLOW. මේ අනුව, ඔබ කොටසේ සඳහන් කර ඇති ඇමතුම් වලට පමණක් ඉඩ දෙයි syscalls, සහ අනෙක් සියල්ල තහනම්. අසාදු ලේඛනය සඳහා ඔබ අගයන් වෙනස් කළ යුතුය defaultAction සහ ප්රතිවිරුද්ධ ක්රියාවන්.

දැන් අපි එතරම් පැහැදිලි නැති සූක්ෂ්ම දේ ගැන වචන කිහිපයක් පැවසිය යුතුය. පහත නිර්දේශයන් ඔබ Kubernetes හි ව්‍යාපාරික යෙදුම් පෙළක් යොදවන බව උපකල්පනය කරන බව කරුණාවෙන් සලකන්න සහ ඔබට හැකි අවම වරප්‍රසාද ප්‍රමාණයකින් ඒවා ක්‍රියාත්මක කිරීමට අවශ්‍ය වේ.

1. AllowPrivilegeEscalation=අසත්‍ය

В securityContext කන්ටේනරයට පරාමිතියක් ඇත AllowPrivilegeEscalation. එය ස්ථාපනය කර ඇත්නම් false, බහාලුම් ආරම්භ වනු ඇත (on) ටිකක් no_new_priv. මෙම පරාමිතියේ තේරුම නමෙන් පැහැදිලිය: එය කන්ටේනරයට වඩා වැඩි වරප්‍රසාද සහිත නව ක්‍රියාවලීන් දියත් කිරීමෙන් වළක්වයි.

මෙම විකල්පය සැකසීමේ අතුරු ආබාධයකි true (පෙරනිමිය) යනු ආරම්භක ක්‍රියාවලියේ ආරම්භයේදීම බහාලුම් ධාවන කාලය seccomp පැතිකඩ යොදන බවයි. මේ අනුව, අභ්‍යන්තර ධාවන කාල ක්‍රියාවලීන් ක්‍රියාත්මක කිරීමට අවශ්‍ය සියලුම පද්ධති ඇමතුම් (උදා: පරිශීලක/කණ්ඩායම් හැඳුනුම්පත් සැකසීම, ඇතැම් හැකියාවන් අතහැර දැමීම) පැතිකඩ තුළ සක්‍රීය කළ යුතුය.

පොඩි පොඩි දේවල් කරන කන්ටේනරයකට 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 පැතිකඩ සැකසීම

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 - දළ වශයෙන්. පරිවර්තනය).

Kubernetes සැමවිටම ඇති බව ස්වල්ප දෙනෙක් දනිති දෝෂයඑය seccomp පැතිකඩ යෙදීමට හේතු විය විරාම කන්ටේනරය. ධාවන කාල පරිසරය මෙම අඩුපාඩුව සඳහා අර්ධ වශයෙන් වන්දි ලබා දෙයි, නමුත් මෙම කන්ටේනරය කරල් වලින් අතුරුදහන් නොවේ, මන්ද එය ඒවායේ යටිතල පහසුකම් වින්‍යාස කිරීමට භාවිතා කරයි.

ගැටළුව වන්නේ මෙම කන්ටේනරය සැමවිටම ආරම්භ වීමයි AllowPrivilegeEscalation=true, 1 වන ඡේදයේ දක්වා ඇති ගැටළු වලට තුඩු දෙන අතර මෙය වෙනස් කළ නොහැක.

බහාලුම් මට්ටමින් seccomp පැතිකඩ භාවිතා කිරීමෙන්, ඔබට මෙම අන්තරාය වළක්වා ගත හැකි අතර නිශ්චිත බහාලුමකට ගැලපෙන පැතිකඩක් නිර්මාණය කළ හැකිය. සංවර්ධකයින් දෝෂය නිවැරදි කර නව අනුවාදය (සමහර විට 1.18?) සෑම කෙනෙකුටම ලබා ගත හැකි වන තෙක් මෙය සිදු කිරීමට සිදුවනු ඇත.

ඉඟිය # 2: බහාලුම් මට්ටමින් seccomp පැතිකඩ සකසන්න.

ප්‍රායෝගික අර්ථයකින්, මෙම රීතිය සාමාන්‍යයෙන් ප්‍රශ්නයට විශ්වීය පිළිතුරක් ලෙස ක්‍රියා කරයි: “මගේ seccomp පැතිකඩ ක්‍රියා කරන්නේ ඇයි? docker runනමුත් Kubernetes පොකුරකට යෙදවීමෙන් පසු වැඩ කරන්නේ නැද්ද?

3. ධාවන කාලය/පෙරනිමිය අවසාන විසඳුම ලෙස පමණක් භාවිතා කරන්න

කුබර්නෙටස් හි ඇති පැතිකඩ සඳහා විකල්ප දෙකක් ඇත: runtime/default и docker/default. දෙකම ක්‍රියාත්මක කරනු ලබන්නේ බහාලුම් ධාවන කාලය මගිනි, කුබර්නෙටස් නොවේ. එබැවින්, භාවිතා කරන ධාවන පරිසරය සහ එහි අනුවාදය අනුව ඒවා වෙනස් විය හැක.

වෙනත් වචන වලින් කිවහොත්, ධාවන කාලය වෙනස් කිරීමේ ප්‍රතිඵලයක් ලෙස, බහාලුමට වෙනත් පද්ධති ඇමතුම් කට්ටලයකට ප්‍රවේශ විය හැකිය, එය භාවිතා කළ හැකි හෝ නොකළ හැකිය. බොහෝ ධාවන කාල භාවිතා වේ ඩොකර් ක්රියාත්මක කිරීම. ඔබට මෙම පැතිකඩ භාවිතා කිරීමට අවශ්‍ය නම්, කරුණාකර එය ඔබට සුදුසු බව සහතික කර ගන්න.

පැතිකඩ docker/default Kubernetes 1.11 ලෙස අවලංගු කර ඇත, එබැවින් එය භාවිතා කිරීමෙන් වළකින්න.

මගේ මතය අනුව, පැතිකඩ runtime/default එය නිර්මාණය කරන ලද අරමුණ සඳහා හොඳින් ගැලපේ: විධානයක් ක්‍රියාත්මක කිරීම හා සම්බන්ධ අවදානම් වලින් පරිශීලකයින් ආරක්ෂා කිරීම docker run ඔවුන්ගේ කාර් මත. කෙසේ වෙතත්, Kubernetes පොකුරු මත ක්‍රියාත්මක වන ව්‍යාපාරික යෙදුම් සම්බන්ධයෙන්, එවැනි පැතිකඩක් ඉතා විවෘත බව තර්ක කිරීමට මම නිර්භීත වන අතර සංවර්ධකයින් ඔවුන්ගේ යෙදුම් (හෝ යෙදුම් වර්ග) සඳහා පැතිකඩ නිර්මාණය කිරීම කෙරෙහි අවධානය යොමු කළ යුතුය.

ඉඟිය # 3: විශේෂිත යෙදුම් සඳහා seccomp පැතිකඩ සාදන්න. මෙය කළ නොහැකි නම්, යෙදුම් වර්ග සඳහා පැතිකඩ සාදන්න, උදාහරණයක් ලෙස, Golang යෙදුමේ සියලුම වෙබ් API ඇතුළත් උසස් පැතිකඩක් සාදන්න. අවසාන විසඳුම ලෙස ධාවන කාලය/පෙරනිමිය පමණක් භාවිතා කරන්න.

ඉදිරි පළ කිරීම් වලදී, මම SecDevOps-ආනුභාව ලත් seccomp පැතිකඩ නිර්මාණය කරන්නේ කෙසේද, ඒවා ස්වයංක්‍රීය කරන්නේ කෙසේද සහ ඒවා නල මාර්ගවල පරීක්ෂා කරන්නේ කෙසේද යන්න ආවරණය කරමි. වෙනත් වචන වලින් කිවහොත්, යෙදුම් විශේෂිත පැතිකඩ වෙත යාවත්කාලීන නොකිරීමට ඔබට නිදහසට කරුණක් නැත.

4. Unconfined යනු විකල්පයක් නොවේ.

සිට පළමු Kubernetes ආරක්ෂක විගණනය එය පෙරනිමියෙන් බව පෙනී ගියේය seccomp අක්‍රීය කර ඇත. මෙයින් අදහස් කරන්නේ ඔබ සැකසෙන්නේ නැත්නම් PodSecurityPolicy, එය පොකුරේ එය සක්‍රීය කරනු ඇත, seccomp පැතිකඩ නිර්වචනය කර නොමැති සියලුම කරල් ක්‍රියා කරයි seccomp=unconfined.

මෙම මාදිලියේ ක්රියා කිරීම යනු පොකුර ආරක්ෂා කරන පරිවරණයේ සම්පූර්ණ ස්ථරයක් අහිමි වීමයි. මෙම ප්රවේශය ආරක්ෂක විශේෂඥයින් විසින් නිර්දේශ නොකරයි.

ඉඟිය # 4: පොකුරේ කිසිදු බහාලුමක් ධාවනය නොවිය යුතුය seccomp=unconfined, විශේෂයෙන්ම නිෂ්පාදන පරිසරයන් තුළ.

5. "විගණන මාදිලිය"

මෙම කරුණ Kubernetes සඳහා සුවිශේෂී නොවේ, නමුත් තවමත් "ඔබ ආරම්භ කිරීමට පෙර දැනගත යුතු දේවල්" කාණ්ඩයට වැටේ.

එය සිදු වන පරිදි, seccomp පැතිකඩ නිර්මාණය කිරීම සැමවිටම අභියෝගාත්මක වන අතර අත්හදා බැලීම් සහ දෝෂයන් මත දැඩි ලෙස රඳා පවතී. කාරණය නම්, යෙදුම “අතහැරීම” අවදානමකින් තොරව නිෂ්පාදන පරිසරයන් තුළ ඒවා පරීක්ෂා කිරීමට පරිශීලකයින්ට අවස්ථාව නොමැති වීමයි.

ලිනක්ස් කර්නලය 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 කර්නලය විසින් සහාය දක්වන ලද, එය Kubernetes පරිසර පද්ධතියට ඇතුළු වූයේ සාපේක්ෂව මෑතදී පමණි. එබැවින්, මෙම ක්‍රමය භාවිතා කිරීම සඳහා ඔබට ලිනක්ස් කර්නලයක් 4.14 සහ අඩු නොවන runC අනුවාදයක් අවශ්‍ය වේ. v1.0.0-rc9.

ඉඟිය # 5: නිෂ්පාදනයේදී පරීක්ෂා කිරීම සඳහා විගණන මාදිලියේ පැතිකඩක් කළු සහ සුදු ලැයිස්තු ඒකාබද්ධ කිරීමෙන් නිර්මාණය කළ හැකි අතර, සියලු ව්‍යතිරේක ලොග් කළ හැක.

6. සුදු ලැයිස්තු භාවිතා කරන්න

යෙදුමට අවශ්‍ය විය හැකි සෑම ඇමතුමක්ම ඔබට හඳුනාගත යුතු බැවින් සුදු ලැයිස්තුගත කිරීම සඳහා අමතර උත්සාහයක් අවශ්‍ය වේ, නමුත් මෙම ප්‍රවේශය ආරක්ෂාව බෙහෙවින් වැඩි දියුණු කරයි:

සුදු ලැයිස්තු ප්‍රවේශය සරල සහ වඩා විශ්වාසදායක බැවින් එය භාවිතා කිරීම බෙහෙවින් නිර්දේශ කෙරේ. අනතුරුදායක විය හැකි පද්ධති ඇමතුමක් (හෝ එය අසාදු ලේඛනයේ තිබේ නම් භයානක ධජයක්/විකල්පයක්) එක් කළ විට අසාදු ලේඛනය යාවත්කාලීන කිරීමට අවශ්‍ය වනු ඇත. ඊට අමතරව, පරාමිතියක සාරය වෙනස් නොකර එහි නිරූපණය වෙනස් කිරීමට සහ එමඟින් අසාදු ලේඛනයේ සීමාවන් මඟ හැරීමට බොහෝ විට හැකි ය.

Go යෙදුම් සඳහා, මම යෙදුම සමඟ විශේෂ මෙවලමක් සංවර්ධනය කළ අතර ක්‍රියාත්මක කිරීමේදී කරන ලද සියලුම ඇමතුම් එකතු කරමි. උදාහරණයක් ලෙස, පහත යෙදුම සඳහා:

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 භාවිතා කිරීම පිළිබඳ ලිපි මාලාවක පළමු කොටස අවසන් කරයි. මෙය වැදගත් වන්නේ ඇයි සහ ක්‍රියාවලිය ස්වයංක්‍රීය කරන්නේ කෙසේද යන්න පහත කොටස් වලින් අපි කතා කරමු.

පරිවර්තකගෙන් PS

අපගේ බ්ලොග් අඩවියේ ද කියවන්න:

• «ඩොකර් බහාලුම් සඳහා ආරක්ෂාව»;
• «33+ Kubernetes ආරක්ෂක මෙවලම්»;
• «ආරක්‍ෂාව ඉල්ලන පරිසරයක ඩොකර් සහ කුබර්නෙට්ස්»;
• «9 Kubernetes ආරක්ෂක හොඳම භාවිතයන්".

මූලාශ්රය: www.habr.com