پرو هوسٽر > بلاگ > انتظاميه > Seccomp in Kubernetes: 7 شيون جيڪي توھان کي شروعات کان ڄاڻڻ جي ضرورت آھي

Seccomp in Kubernetes: 7 شيون جيڪي توھان کي شروعات کان ڄاڻڻ جي ضرورت آھي

نوٽ. ترجمو: اسان توهان جي توجه لاءِ پيش ڪريون ٿا هڪ آرٽيڪل جو ترجمو هڪ سينئر ايپليڪيشن سيڪيورٽي انجنيئر طرفان برطانوي ڪمپني ASOS.com تي. ان سان گڏ، هو ڪبرنيٽس ۾ سيڪيورٽي کي بهتر ڪرڻ لاء وقف ڪيل اشاعتن جو هڪ سلسلو شروع ڪري ٿو seccomp جي استعمال ذريعي. جيڪڏهن پڙهندڙن کي تعارف پسند آهي، اسان مصنف جي پيروي ڪنداسين ۽ هن موضوع تي مستقبل جي مواد سان جاري رکنداسين.

Seccomp in Kubernetes: 7 شيون جيڪي توھان کي شروعات کان ڄاڻڻ جي ضرورت آھي

هي آرٽيڪل پوسٽن جي هڪ سيريز ۾ پهريون آهي ته ڪيئن SecDevOps جي جذبي ۾ سيڪڪمپ پروفائلز ٺاهيا وڃن، بغير جادو ۽ جادوگريء جو رستو اختيار ڪرڻ جي. حصو 1 ۾، مان ڪبرنيٽس ۾ 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 ٽارگيٽ آرڪيٽيڪچر درج ٿيل آهن. اهو ضروري آهي ڇاڪاڻ ته فلٽر پاڻ، ڪرنل سطح تي لاڳو ٿئي ٿو، سسٽم ڪال جي سڃاڻپ ڪندڙ تي منحصر آهي، ۽ پروفائل ۾ بيان ڪيل انهن جي نالن تي نه. ڪنٽينر جو رن ٽائيم استعمال ڪرڻ کان اڳ انھن کي سڃاڻڻ وارن سان ملندو. خيال اهو آهي ته سسٽم ڪالون مڪمل طور تي مختلف IDs هوندا سسٽم جي فن تعمير جي لحاظ سان. مثال طور، سسٽم ڪال recvfrom (ساڪيٽ مان معلومات حاصل ڪرڻ لاءِ استعمال ڪيو ويندو آهي) ID = 64 تي x64 سسٽم ۽ ID = 517 تي x86 آهي. اهو آهي توهان x86-x64 آرڪيٽيڪچرز لاءِ سڀني سسٽم ڪالن جي لسٽ ڳولي سگهو ٿا.

سيڪشن ۾ syscalls سڀني سسٽم ڪالن کي لسٽ ڪري ٿو ۽ وضاحت ڪري ٿو ته انهن سان ڇا ڪجي. مثال طور، توهان سيٽنگ ذريعي هڪ وائيٽ لسٽ ٺاهي سگهو ٿا defaultAction تي SCMP_ACT_ERRNO، ۽ سيڪشن ۾ ڪالون syscalls تفويض ڪرڻ SCMP_ACT_ALLOW. ان ڪري، توهان صرف سيڪشن ۾ بيان ڪيل ڪالن جي اجازت ڏيو ٿا syscalls، ۽ ٻين سڀني کي منع ڪريو. بليڪ لسٽ لاءِ توھان کي قدر تبديل ڪرڻ گھرجي defaultAction ۽ خلاف عمل.

هاڻي اسان کي nuances جي باري ۾ چند لفظن جو چوڻ آهي ته ايترو واضح نه آهن. مهرباني ڪري نوٽ ڪريو ته هيٺ ڏنل سفارشون فرض ڪن ٿيون ته توهان ڪبرنيٽس تي ڪاروباري ايپليڪيشنن جي هڪ قطار کي ترتيب ڏئي رهيا آهيو ۽ توهان چاهيو ٿا ته انهن کي گهٽ ۾ گهٽ امتياز سان هلائڻ.

1. اجازت ڏيوPrivilegeEscalation = غلط

В securityContext ڪنٽينر وٽ هڪ پيٽرول آهي AllowPrivilegeEscalation. جيڪڏهن اهو نصب ٿيل آهي falseڪنٽينر شروع ٿيندا (on) سا no_new_priv. ھن پيٽرولر جو مطلب نالو مان پڌرو آھي: اھو ڪنٽينر کي روڪي ٿو نون عملن کي شروع ڪرڻ کان وڌيڪ استحقاق سان پاڻ وٽ.

هن اختيار جو هڪ طرفي اثر مقرر ڪيو پيو وڃي true (ڊفالٽ) اهو آهي ته ڪنٽينر رن ٽائم لاڳو ٿئي ٿو seccomp پروفائل کي شروعاتي عمل جي شروعات ۾. اھڙيءَ طرح، اندروني رن ٽائم جي عملن کي هلائڻ لاءِ گھربل سڀ سسٽم ڪالز (مثال طور صارف/گروپ IDs کي ترتيب ڏيڻ، خاص صلاحيتن کي ختم ڪرڻ) پروفائل ۾ فعال ٿيڻ گھرجي.

ڪنٽينر ڏانهن جيڪو ٿورڙو ڪم ڪري ٿو 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. اهو سيڪڪمپ پروفائلز جي سائيز کي گھٽائي ڇڏيندو ۽ ڪنٽينر رن ٽائم ماحول ۾ تبديلين کي گھٽ حساس بڻائيندو.

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 بڻجي ويندو (هي واقعو ڪبرنيٽس جي ايندڙ رليز ۾ متوقع آهي - 1.18 - تقريبن ترجمو.).

ٿورا ماڻهو ڄاڻن ٿا ته ڪبرنيٽس هميشه ڪيو آهي بگجنهن سبب seccomp پروفائلز تي لاڳو ڪيو ويو ڪنٽينر کي روڪيو. رن ٽائم ماحول جزوي طور تي ھن نقص لاءِ معاوضو ڏئي ٿو، پر ھي ڪنٽينر پوڊن مان غائب نه ٿيندو آھي، ڇاڪاڻ⁠تہ اھو انھن جي انفراسٽرڪچر کي ترتيب ڏيڻ لاءِ استعمال ڪيو ويندو آھي.

مسئلو اهو آهي ته هي ڪنٽينر هميشه سان شروع ٿئي ٿو AllowPrivilegeEscalation=trueپيراگراف 1 ۾ پيش ڪيل مسئلن جي ڪري، ۽ اهو تبديل نٿو ڪري سگهجي.

ڪنٽينر جي سطح تي seccomp پروفائلز استعمال ڪندي، توھان ھن نقصان کان بچو ٿا ۽ ھڪڙو پروفائل ٺاھي سگھو ٿا جيڪو ھڪڙي مخصوص ڪنٽينر سان ٺھيل آھي. اهو ٿيڻو پوندو جيستائين ڊولپرز بگ کي درست ڪن ۽ نئون ورزن (شايد 1.18؟) هر ڪنهن لاءِ دستياب ٿي وڃي.

ڪائونسل نمبر 2: ڪنٽينر جي سطح تي seccomp پروفائلز سيٽ ڪريو.

عملي معنى ۾، هي قاعدو عام طور تي سوال جي عالمگير جواب جي طور تي ڪم ڪري ٿو: "منهنجي سيڪنڊ جي پروفائيل سان ڇو ڪم ڪندو آهي؟ docker runپر ڪبرنيٽس ڪلستر تي لڳائڻ کان پوءِ ڪم نٿو ڪري؟

3. استعمال ڪريو رن ٽائم/ڊفالٽ صرف آخري روٽ طور

Kubernetes وٽ تعمير ٿيل پروفائلز لاءِ ٻه اختيار آھن: runtime/default и docker/default. ٻئي ڪنٽينر رن ٽائيم طرفان لاڳو ڪيا ويا آهن، نه ڪبرنيٽس. تنهن ڪري، اهي استعمال ٿيل رن ٽائم ماحول ۽ ان جي ورزن تي منحصر ڪري سگھن ٿا.

ٻين لفظن ۾، رن ٽائم کي تبديل ڪرڻ جي نتيجي ۾، ڪنٽينر کي سسٽم ڪالن جي مختلف سيٽ تائين رسائي ٿي سگھي ٿي، جيڪا شايد استعمال ڪري سگھي ٿي يا نه. اڪثر رن ٽائمز استعمال ڪندا آهن ڊڪر تي عملدرآمد. جيڪڏهن توهان هن پروفائل کي استعمال ڪرڻ چاهيو ٿا، مهرباني ڪري پڪ ڪريو ته اهو توهان لاء مناسب آهي.

پروفائيل docker/default Kubernetes 1.11 کان ختم ٿي چڪو آهي، تنهنڪري ان کي استعمال ڪرڻ کان پاسو ڪريو.

منهنجي خيال ۾، پروفائيل runtime/default مڪمل طور تي ان مقصد لاءِ موزون آھي جنھن لاءِ اھو ٺاھيو ويو آھي: استعمال ڪندڙن کي تحفظ ڏيڻ سان لاڳاپيل خطرن کان ڪمانڊ تي عمل ڪرڻ سان docker run انهن جي گاڏين تي. بهرحال، جڏهن اها ڪبرنيٽس ڪلستر تي هلندڙ ڪاروباري ايپليڪيشنن تي اچي ٿي، مان بحث ڪرڻ جي جرئت ڪندس ته اهڙي پروفائل تمام کليل آهي ۽ ڊولپرز کي انهن جي ايپليڪيشنن (يا ايپليڪيشنن جي قسمن) لاء پروفائل ٺاهڻ تي ڌيان ڏيڻ گهرجي.

ڪائونسل نمبر 3: مخصوص ايپليڪيشنن لاءِ seccomp پروفائل ٺاھيو. جيڪڏهن اهو ممڪن نه آهي، ايپليڪيشن جي قسمن لاءِ پروفائل ٺاهيو، مثال طور، هڪ ترقي يافته پروفائل ٺاهيو جنهن ۾ گولنگ ايپليڪيشن جا سڀئي ويب API شامل آهن. صرف آخري ريزورٽ طور رن ٽائم/ڊفالٽ استعمال ڪريو.

مستقبل جي پوسٽن ۾، مان ڍڪيندس ته ڪيئن ٺاهيو SecDevOps-حوصلو رکندڙ seccomp پروفائلز، انهن کي خودڪار ڪرڻ، ۽ انهن کي پائپ لائنن ۾ جانچيو. ٻين لفظن ۾، توهان وٽ ڪو به عذر نه هوندو ته اپ گريڊ نه ڪرڻ لاءِ ايپليڪيشن-مخصوص پروفائلز.

4. اڻڄاتل اختيار نه آهي.

کان پهريون Kubernetes سيڪيورٽي آڊٽ اهو ظاهر ٿيو ته ڊفالٽ طرفان seccomp بند ٿيل. ان جو مطلب اهو آهي ته جيڪڏهن توهان مقرر نه ڪيو PodSecurityPolicy، جيڪو ان کي ڪلستر ۾ چالو ڪندو، سڀئي پوڊس جن لاءِ seccomp پروفائل بيان نه ڪئي وئي آھي ان ۾ ڪم ڪندو. seccomp=unconfined.

هن موڊ ۾ ڪم ڪرڻ جو مطلب آهي ته موصليت جو هڪ سڄو پرت گم ٿي ويو آهي جيڪو ڪلستر کي بچائيندو آهي. هي طريقو سيڪيورٽي ماهرن طرفان سفارش نه ڪئي وئي آهي.

ڪائونسل نمبر 4: ڪلستر ۾ ڪو به ڪنٽينر اندر نه ھلڻ گھرجي seccomp=unconfinedخاص طور تي پيداوار جي ماحول ۾.

5. "آڊيٽ موڊ"

هي نقطو ڪوبرنيٽس لاءِ منفرد ناهي، پر اڃا تائين ”شروع ڪرڻ کان پهريان ڄاڻڻ جي شين“ جي درجي ۾ اچي ٿو.

جيئن ته اهو ٿئي ٿو، 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"
        }
    ]
}

(medium-mixed-seccomp.json)

پر ياد رکو ته توهان سڀني ڪالن کي بلاڪ ڪرڻ جي ضرورت آهي جيڪي توهان ڄاڻو ٿا استعمال نه ڪيا ويندا ۽ اهو ممڪن طور تي ڪلستر کي نقصان پهچائي سگهي ٿو. هڪ فهرست مرتب ڪرڻ لاء هڪ سٺو بنياد سرڪاري آهي Docker دستاويز. اهو تفصيل سان بيان ڪري ٿو ته سسٽم ڪالز کي ڊفالٽ پروفائل ۾ بلاڪ ڪيو ويو آهي ۽ ڇو.

بهرحال، اتي هڪ پڪڙي آهي. جيتوڻيڪ SCMT_ACT_LOG 2017 جي آخر کان لينڪس ڪنييل جي حمايت ڪئي، اهو صرف نسبتا تازو ڪبرنيٽس ايڪو سسٽم ۾ داخل ٿيو. تنهن ڪري، هن طريقي کي استعمال ڪرڻ لاء توهان کي لينڪس ڪنييل 4.14 ۽ رن سي ورزن جي ضرورت هوندي 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 غير معين مدت لاءِ. نتيجي طور، توهان ڪلستر ۾ اعلي سي پي يو استعمال حاصل ڪندا:

Seccomp in Kubernetes: 7 شيون جيڪي توھان کي شروعات کان ڄاڻڻ جي ضرورت آھي

اهڙين حالتن ۾، هڪ افاديت بچاء لاء اچي سگهي ٿو strace - اهو ڏيکاريندو ته مسئلو ڇا ٿي سگهي ٿو:

Seccomp in Kubernetes: 7 شيون جيڪي توھان کي شروعات کان ڄاڻڻ جي ضرورت آھي
sudo strace -c -p 9331

پڪ ڪريو ته پروفائيل ۾ سڀ سسٽم ڪالون شامل آهن جيڪي ايپليڪيشن کي رن ٽائم تي گهربل آهن.

ڪائونسل نمبر 7: تفصيل تي ڌيان ڏيو ۽ پڪ ڪريو ته سڀئي ضروري سسٽم ڪالون وائيٽ لسٽ ٿيل آهن.

هي ختم ڪري ٿو مضمونن جي هڪ سيريز جو پهريون حصو ڪبرنيٽس ۾ سيڪڪمپ استعمال ڪرڻ تي SecDevOps جي روح ۾. هيٺ ڏنل حصن ۾ اسين ڳالهائينداسين ڇو ته اهو اهم آهي ۽ پروسيس کي خودڪار ڪيئن ڪجي.

پي ايس مترجم کان

اسان جي بلاگ تي پڻ پڙهو:

جو ذريعو: www.habr.com

تبصرو شامل ڪريو