কুবারনেটসে সেকমপ: 7টি জিনিস আপনার প্রথম থেকেই জানা দরকার

বিঃদ্রঃ. অনুবাদ: আমরা আপনার নজরে ব্রিটিশ কোম্পানি ASOS.com-এর একজন সিনিয়র অ্যাপ্লিকেশন সিকিউরিটি ইঞ্জিনিয়ারের একটি নিবন্ধের অনুবাদ উপস্থাপন করছি। এটির সাথে, তিনি seccomp ব্যবহারের মাধ্যমে কুবারনেটসে নিরাপত্তার উন্নতির জন্য নিবেদিত প্রকাশনার একটি সিরিজ শুরু করেন। পাঠকরা যদি ভূমিকাটি পছন্দ করেন তবে আমরা লেখককে অনুসরণ করব এবং এই বিষয়ে তার ভবিষ্যতের উপকরণগুলি চালিয়ে যাব।

জাদুবিদ্যা এবং জাদুবিদ্যার আশ্রয় না নিয়ে কীভাবে SecDevOps-এর চেতনায় seccomp প্রোফাইল তৈরি করা যায় তার ধারাবাহিক পোস্টগুলির মধ্যে এই নিবন্ধটি প্রথম। পার্ট XNUMX-এ, আমি 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 লক্ষ্য আর্কিটেকচার তালিকাভুক্ত করা হয়. এটি গুরুত্বপূর্ণ কারণ কার্নেল স্তরে প্রয়োগ করা ফিল্টারটি সিস্টেম কল শনাক্তকারীর উপর নির্ভর করে, প্রোফাইলে নির্দিষ্ট করা নামের উপর নয়। কন্টেইনার রানটাইম ব্যবহারের আগে শনাক্তকারীর সাথে তাদের মিলবে। ধারণাটি হল যে সিস্টেম আর্কিটেকচারের উপর নির্ভর করে সিস্টেম কলগুলিতে সম্পূর্ণ ভিন্ন আইডি থাকতে পারে। উদাহরণস্বরূপ, সিস্টেম কল 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 প্রোফাইল সেট করুন।

একটি ব্যবহারিক অর্থে, এই নিয়মটি সাধারণত এই প্রশ্নের সার্বজনীন উত্তর হিসাবে কাজ করে: "কেন আমার সেককম্প প্রোফাইল এর সাথে কাজ করে docker runকিন্তু কুবারনেটস ক্লাস্টারে স্থাপন করার পরে কাজ করে না?

3. শুধুমাত্র শেষ অবলম্বন হিসাবে রানটাইম/ডিফল্ট ব্যবহার করুন

বিল্ট-ইন প্রোফাইলের জন্য কুবারনেটসের দুটি বিকল্প রয়েছে: 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. "অডিট মোড"

এই পয়েন্টটি Kubernetes-এর জন্য অনন্য নয়, তবে এখনও "শুরু করার আগে জেনে রাখা জিনিস" বিভাগে পড়ে।

যেহেতু এটি ঘটে, 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"
        }
    ]
}

(medium-mixed-seccomp.json)

কিন্তু মনে রাখবেন যে আপনাকে এমন সমস্ত কল ব্লক করতে হবে যা আপনি জানেন যে ব্যবহার করা হবে না এবং এটি ক্লাস্টারের সম্ভাব্য ক্ষতি করতে পারে। একটি তালিকা কম্পাইল করার জন্য একটি ভাল ভিত্তি হল অফিসিয়াল ডকার ডকুমেন্টেশন. এটি বিস্তারিতভাবে ব্যাখ্যা করে যে ডিফল্ট প্রোফাইলে কোন সিস্টেম কলগুলি ব্লক করা হয়েছে এবং কেন।

তবে একটি ক্যাচ আছে। যদিও SCMT_ACT_LOG 2017 সালের শেষ থেকে লিনাক্স কার্নেল দ্বারা সমর্থিত, এটি তুলনামূলকভাবে সম্প্রতি কুবারনেটস ইকোসিস্টেমে প্রবেশ করেছে। অতএব, এই পদ্ধতিটি ব্যবহার করার জন্য আপনার একটি লিনাক্স কার্নেল 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+ কুবারনেটস নিরাপত্তা সরঞ্জাম";
• «নিরাপত্তা-চাহিদার পরিবেশে ডকার এবং কুবারনেটস";
• «9 Kubernetes নিরাপত্তা সর্বোত্তম অভ্যাস».

উত্স: www.habr.com