Seccomp in Kubernetes: 7 چیزیں جو آپ کو شروع سے ہی جاننے کی ضرورت ہے۔

نوٹ. ترجمہ: ہم آپ کی توجہ برطانوی کمپنی ASOS.com کے ایک سینئر ایپلیکیشن سیکیورٹی انجینئر کے ایک مضمون کا ترجمہ پیش کرتے ہیں۔ اس کے ساتھ، وہ seccomp کے استعمال کے ذریعے Kubernetes میں سیکورٹی کو بہتر بنانے کے لیے وقف اشاعتوں کا ایک سلسلہ شروع کرتا ہے۔ اگر قارئین کو تعارف پسند آیا تو ہم مصنف کی پیروی کریں گے اور اس موضوع پر اس کے مستقبل کے مواد کو جاری رکھیں گے۔

یہ مضمون جادو اور جادو کا سہارا لیے بغیر، SecDevOps کی روح میں seccomp پروفائلز بنانے کے طریقے پر پوسٹس کے سلسلے میں پہلا مضمون ہے۔ حصہ 1 میں، میں Kubernetes میں seccomp کو نافذ کرنے کی بنیادی باتوں اور اندرونی تفصیلات کا احاطہ کروں گا۔

Kubernetes ماحولیاتی نظام کنٹینرز کو محفوظ اور الگ تھلگ کرنے کے مختلف طریقے پیش کرتا ہے۔ مضمون سیکیور کمپیوٹنگ موڈ کے بارے میں ہے، جسے بھی کہا جاتا ہے۔ سیکومکومپ. اس کا جوہر کنٹینرز کے ذریعے عمل درآمد کے لیے دستیاب سسٹم کالز کو فلٹر کرنا ہے۔

یہ کیوں ضروری ہے؟ ایک کنٹینر صرف ایک مخصوص مشین پر چلنے والا عمل ہے۔ اور یہ دیگر ایپلی کیشنز کی طرح دانا کا استعمال کرتا ہے۔ اگر کنٹینرز کسی بھی سسٹم کال کو انجام دے سکتے ہیں، تو بہت جلد میلویئر کنٹینر کی تنہائی کو نظرانداز کرنے اور دیگر ایپلیکیشنز کو متاثر کرنے کے لیے اس کا فائدہ اٹھائے گا: معلومات کو روکنا، سسٹم کی ترتیبات کو تبدیل کرنا، وغیرہ۔

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 (ساکٹ سے معلومات حاصل کرنے کے لیے استعمال کیا جاتا ہے) میں x64 سسٹمز پر ID = 64 اور x517 پر ID = 86 ہے۔ یہاں آپ x86-x64 فن تعمیر کے لیے تمام سسٹم کالز کی فہرست تلاش کر سکتے ہیں۔

سیکشن میں syscalls تمام سسٹم کالز کی فہرست بناتا ہے اور بتاتا ہے کہ ان کے ساتھ کیا کرنا ہے۔ مثال کے طور پر، آپ ترتیب دے کر وائٹ لسٹ بنا سکتے ہیں۔ defaultAction پر SCMP_ACT_ERRNO، اور سیکشن میں کال کریں۔ syscalls تفویض SCMP_ACT_ALLOW. اس طرح، آپ صرف سیکشن میں مخصوص کالوں کی اجازت دیتے ہیں۔ syscalls، اور باقی سب کو منع کریں۔ بلیک لسٹ کے لیے آپ کو اقدار کو تبدیل کرنا چاہیے۔ defaultAction اور اس کے برعکس اعمال۔

اب ہمیں باریکیوں کے بارے میں چند الفاظ کہنا چاہئے جو اتنے واضح نہیں ہیں۔ براہ کرم نوٹ کریں کہ ذیل میں دی گئی سفارشات یہ مانتی ہیں کہ آپ Kubernetes پر کاروباری ایپلیکیشنز کی ایک لائن تعینات کر رہے ہیں اور آپ چاہتے ہیں کہ وہ کم سے کم مراعات کے ساتھ چلیں۔

1. AllowPrivilegeEscalation=false

В 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لیکن کبرنیٹس کلسٹر میں تعینات کرنے کے بعد کام نہیں کرتا؟

3. رن ٹائم/ڈیفالٹ کو صرف آخری حربے کے طور پر استعمال کریں۔

بلٹ ان پروفائلز کے لیے Kubernetes کے پاس دو اختیارات ہیں: runtime/default и docker/default. دونوں کو کنٹینر رن ٹائم کے ذریعے لاگو کیا جاتا ہے، نہ کہ کبرنیٹس۔ لہذا، وہ استعمال شدہ رن ٹائم ماحول اور اس کے ورژن کے لحاظ سے مختلف ہو سکتے ہیں۔

دوسرے الفاظ میں، رن ٹائم تبدیل کرنے کے نتیجے میں، کنٹینر کو سسٹم کالز کے مختلف سیٹ تک رسائی حاصل ہو سکتی ہے، جسے وہ استعمال کر سکتا ہے یا نہیں کر سکتا۔ زیادہ تر رن ٹائم استعمال کرتے ہیں۔ ڈاکر کا نفاذ. اگر آپ اس پروفائل کو استعمال کرنا چاہتے ہیں، تو براہ کرم یقینی بنائیں کہ یہ آپ کے لیے موزوں ہے۔

پروفائل docker/default Kubernetes 1.11 کے بعد سے فرسودہ ہے، لہذا اسے استعمال کرنے سے گریز کریں۔

میری رائے میں، پروفائل runtime/default اس مقصد کے لیے بالکل موزوں ہے جس کے لیے اسے بنایا گیا تھا: صارفین کو کمانڈ پر عمل کرنے سے وابستہ خطرات سے بچانا docker run ان کی گاڑیوں پر. تاہم، جب Kubernetes کلسٹرز پر چلنے والی کاروباری ایپلی کیشنز کی بات آتی ہے، تو میں یہ بحث کرنے کی جسارت کروں گا کہ ایسا پروفائل بہت کھلا ہے اور ڈویلپرز کو اپنی ایپلی کیشنز (یا ایپلی کیشنز کی اقسام) کے لیے پروفائلز بنانے پر توجہ دینی چاہیے۔

ٹپ نمبر 3۔: مخصوص ایپلی کیشنز کے لیے seccomp پروفائلز بنائیں۔ اگر یہ ممکن نہیں ہے تو، ایپلیکیشن کی اقسام کے لیے پروفائلز بنائیں، مثال کے طور پر، ایک ایڈوانس پروفائل بنائیں جس میں Golang ایپلیکیشن کے تمام ویب APIs شامل ہوں۔ صرف آخری حربے کے طور پر رن ​​ٹائم/ڈیفالٹ استعمال کریں۔

مستقبل کی پوسٹس میں، میں اس بات کا احاطہ کروں گا کہ SecDevOps سے متاثر seccomp پروفائلز کیسے بنائیں، انہیں خودکار بنائیں، اور پائپ لائنز میں ان کی جانچ کریں۔ دوسرے لفظوں میں، آپ کے پاس ایپلیکیشن مخصوص پروفائلز میں اپ گریڈ نہ کرنے کا کوئی عذر نہیں ہوگا۔

4. غیر محدود ایک آپشن نہیں ہے۔

میں سے پہلا 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"
        }
    ]
}

(medium-mixed-seccomp.json)

لیکن یاد رکھیں کہ آپ کو ان تمام کالوں کو بلاک کرنے کی ضرورت ہے جن کے بارے میں آپ جانتے ہیں کہ استعمال نہیں کیا جائے گا اور اس سے کلسٹر کو ممکنہ طور پر نقصان پہنچ سکتا ہے۔ فہرست مرتب کرنے کی ایک اچھی بنیاد سرکاری ہے۔ ڈاکر دستاویزات. یہ تفصیل سے بتاتا ہے کہ ڈیفالٹ پروفائل میں کون سی سسٹم کالز بلاک ہیں اور کیوں۔

تاہم، ایک کیچ ہے. اگرچہ SCMT_ACT_LOG 2017 کے آخر سے لینکس کرنل کی مدد سے، یہ نسبتاً حال ہی میں کبرنیٹس ایکو سسٹم میں داخل ہوا۔ لہذا، اس طریقہ کو استعمال کرنے کے لیے آپ کو لینکس کرنل 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 کے استعمال پر مضامین کی ایک سیریز کا پہلا حصہ ختم کرتا ہے۔ مندرجہ ذیل حصوں میں ہم اس بارے میں بات کریں گے کہ یہ کیوں ضروری ہے اور اس عمل کو خودکار کیسے بنایا جائے۔

مترجم سے PS

ہمارے بلاگ پر بھی پڑھیں:

• «ڈاکر کنٹینرز کے لیے سیکیورٹی؛ "
• «33+ Kubernetes سیکیورٹی ٹولز؛ "
• «سیکیورٹی کا مطالبہ کرنے والے ماحول میں ڈوکر اور کبرنیٹس؛ "
• «Kubernetes سیکیورٹی کے لیے 9 بہترین طریقے'.

ماخذ: www.habr.com