🥇Seccomp in Kubernetes៖ ៧ យ៉ាងដែលអ្នកត្រូវដឹងតាំងពីដំបូង

ចំណាំ។ បកប្រែ៖ យើងធ្វើបទបង្ហាញជូនលោកអ្នកនូវការបកប្រែអត្ថបទដោយវិស្វករសុវត្ថិភាពកម្មវិធីជាន់ខ្ពស់នៅក្រុមហ៊ុនអង់គ្លេស ASOS.com ។ ជាមួយវា គាត់ចាប់ផ្តើមការបោះពុម្ពជាបន្តបន្ទាប់ដែលឧទ្ទិសដល់ការកែលម្អសុវត្ថិភាពនៅក្នុង Kubernetes តាមរយៈការប្រើប្រាស់ seccomp ។ ប្រសិនបើអ្នកអានចូលចិត្តការណែនាំនេះ យើងនឹងធ្វើតាមអ្នកនិពន្ធ ហើយបន្តជាមួយនឹងសម្ភារៈនាពេលអនាគតរបស់គាត់លើប្រធានបទនេះ។

អត្ថបទនេះគឺជាលើកដំបូងក្នុងការប្រកាសជាបន្តបន្ទាប់អំពីរបៀបបង្កើតទម្រង់ seccomp នៅក្នុងស្មារតីនៃ SecDevOps ដោយមិនប្រើវេទមន្ត និងអាបធ្មប់។ នៅក្នុងផ្នែកទី 1 ខ្ញុំនឹងរៀបរាប់អំពីមូលដ្ឋាន និងព័ត៌មានលម្អិតផ្ទៃក្នុងនៃការអនុវត្ត seccomp នៅក្នុង Kubernetes ។

ប្រព័ន្ធអេកូឡូស៊ី Kubernetes ផ្តល់នូវវិធីជាច្រើនដើម្បីធានាសុវត្ថិភាព និងដាក់ធុងដាច់ដោយឡែក។ អត្ថបទនេះគឺអំពី Secure Computing Mode ដែលត្រូវបានគេស្គាល់ថាជា ស៊ីមខម. ខ្លឹមសាររបស់វាគឺដើម្បីត្រងការហៅប្រព័ន្ធដែលមានសម្រាប់ការប្រតិបត្តិដោយកុងតឺន័រ។

ហេតុអ្វីបានជាវាសំខាន់? កុងតឺន័រគឺគ្រាន់តែជាដំណើរការដែលដំណើរការលើម៉ាស៊ីនជាក់លាក់មួយ។ ហើយវាប្រើខឺណែលដូចកម្មវិធីផ្សេងទៀតដែរ។ ប្រសិនបើកុងតឺន័រអាចធ្វើការហៅទូរសព្ទតាមប្រព័ន្ធណាមួយនោះ ឆាប់ៗនេះ មេរោគនឹងទាញយកអត្ថប្រយោជន៍ពីវា ដើម្បីឆ្លងកាត់ភាពឯកោនៃកុងតឺន័រ ហើយប៉ះពាល់ដល់កម្មវិធីផ្សេងទៀត៖ ស្ទាក់ចាប់ព័ត៌មាន ផ្លាស់ប្តូរការកំណត់ប្រព័ន្ធ។ល។

កម្រងព័ត៌មាន 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 (ប្រើដើម្បីទទួលព័ត៌មានពីរន្ធ) មាន ID = 64 នៅលើប្រព័ន្ធ x64 និង ID = 517 នៅលើ x86 ។ វាគឺជាការ អ្នកអាចស្វែងរកបញ្ជីនៃការហៅប្រព័ន្ធទាំងអស់សម្រាប់ស្ថាបត្យកម្ម x86-x64 ។

នៅក្នុងផ្នែក syscalls រាយការហៅតាមប្រព័ន្ធទាំងអស់ ហើយបញ្ជាក់អ្វីដែលត្រូវធ្វើជាមួយពួកគេ។ ឧទាហរណ៍ អ្នកអាចបង្កើតបញ្ជីសដោយការកំណត់ defaultAction នៅលើ SCMP_ACT_ERRNOនិងការហៅទូរស័ព្ទនៅក្នុងផ្នែក syscalls ចាត់តាំង SCMP_ACT_ALLOW. ដូច្នេះ អ្នកអនុញ្ញាតឱ្យហៅទូរស័ព្ទដែលបានបញ្ជាក់ក្នុងផ្នែកប៉ុណ្ណោះ។ syscallsនិងហាមឃាត់អ្នកដទៃទាំងអស់។ សម្រាប់បញ្ជីខ្មៅ អ្នកគួរតែផ្លាស់ប្តូរតម្លៃ defaultAction និងសកម្មភាពផ្ទុយ។

ឥឡូវនេះយើងគួរតែនិយាយពាក្យពីរបីអំពី nuances ដែលមិនសូវច្បាស់។ សូមចំណាំថាការណែនាំខាងក្រោមសន្មត់ថាអ្នកកំពុងដាក់ពង្រាយបន្ទាត់នៃកម្មវិធីអាជីវកម្មនៅលើ 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. ទោះជាយ៉ាងណាក៏ដោយ បញ្ហាប្រឈមពិតប្រាកដគឺថាដោយអនុញ្ញាតឱ្យដំណើរការដែលអ្នកគ្មានការគ្រប់គ្រងទាំងស្រុង អ្នកកំពុងភ្ជាប់ទម្រង់ទៅនឹងការអនុវត្តកុងតឺន័រពេលដំណើរការ។ ម្យ៉ាងវិញទៀត ថ្ងៃណាមួយ អ្នកអាចនឹងដឹងថា បន្ទាប់ពីធ្វើបច្ចុប្បន្នភាពបរិយាកាសពេលដំណើរការកុងតឺន័រ (ដោយអ្នក ឬទំនងជាដោយអ្នកផ្តល់សេវាពពក) ធុងផ្ទុកភ្លាមៗឈប់ដំណើរការ។

គន្លឹះលេខ ៤៖ ដំណើរការធុងជាមួយ AllowPrivilegeEscaltion=false. វានឹងកាត់បន្ថយទំហំនៃទម្រង់ seccomp និងធ្វើឱ្យពួកវាមិនសូវចាប់អារម្មណ៍ចំពោះការផ្លាស់ប្តូរនៅក្នុងបរិយាកាសដំណើរការកុងតឺន័រ។

2. ការកំណត់ទម្រង់ seccomp នៅកម្រិតកុងតឺន័រ

ទម្រង់ seccomp អាចត្រូវបានកំណត់នៅកម្រិត pod៖

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 - ប្រហាក់ប្រហែល។ transl ។ )

មានមនុស្សតិចណាស់ដែលដឹងថា Kubernetes តែងតែមាន កំហុសដែលបណ្តាលឱ្យទម្រង់ seccomp ត្រូវបានអនុវត្តទៅ ផ្អាកកុងតឺន័រ. បរិយាកាសពេលដំណើរការផ្តល់សំណងដោយផ្នែកសម្រាប់ការខ្វះខាតនេះ ប៉ុន្តែកុងតឺន័រនេះមិនបាត់ពីផតទេ ដោយសារវាត្រូវបានប្រើដើម្បីកំណត់រចនាសម្ព័ន្ធរបស់ពួកគេ។

បញ្ហាគឺថាធុងនេះតែងតែចាប់ផ្តើមជាមួយ AllowPrivilegeEscalation=trueដែលនាំទៅដល់បញ្ហាដែលបានបញ្ចេញក្នុងកថាខណ្ឌទី 1 ហើយនេះមិនអាចផ្លាស់ប្តូរបានទេ។

ដោយប្រើទម្រង់ seccomp នៅកម្រិតកុងតឺន័រ អ្នកជៀសវាងការធ្លាក់នេះ ហើយអាចបង្កើតទម្រង់ដែលតម្រូវតាមកុងតឺន័រជាក់លាក់មួយ។ វានឹងត្រូវធ្វើរហូតដល់អ្នកអភិវឌ្ឍន៍ជួសជុលកំហុស ហើយកំណែថ្មី (ប្រហែលជា 1.18?) មានសម្រាប់អ្នករាល់គ្នា។

គន្លឹះលេខ ៤៖ កំណត់ទម្រង់ seccomp នៅកម្រិតកុងតឺន័រ។

នៅក្នុងន័យជាក់ស្តែង ច្បាប់នេះជាធម្មតាបម្រើជាចម្លើយជាសកលចំពោះសំណួរ៖ “ហេតុអ្វីបានជាទម្រង់ seccomp របស់ខ្ញុំដំណើរការជាមួយ docker runប៉ុន្តែមិនដំណើរការបន្ទាប់ពីដាក់ពង្រាយទៅក្រុម Kubernetes?

3. ប្រើពេលដំណើរការ/លំនាំដើមគ្រាន់តែជាមធ្យោបាយចុងក្រោយប៉ុណ្ណោះ។

Kubernetes មានជម្រើសពីរសម្រាប់ទម្រង់ដែលភ្ជាប់មកជាមួយ៖ runtime/default и docker/default. ទាំងពីរត្រូវបានអនុវត្តដោយកុងតឺន័រដំណើរការ មិនមែន Kubernetes ទេ។ ដូច្នេះពួកវាអាចខុសគ្នាអាស្រ័យលើបរិយាកាសពេលដំណើរការដែលបានប្រើ និងកំណែរបស់វា។

ម្យ៉ាងវិញទៀត ជាលទ្ធផលនៃការផ្លាស់ប្តូរពេលដំណើរការ កុងតឺន័រអាចចូលប្រើសំណុំផ្សេងគ្នានៃការហៅប្រព័ន្ធ ដែលវាអាចប្រើ ឬមិនប្រើ។ ពេលវេលាដំណើរការភាគច្រើនប្រើ ការអនុវត្ត Docker. ប្រសិនបើអ្នកចង់ប្រើទម្រង់នេះ សូមប្រាកដថាវាសាកសមសម្រាប់អ្នក។

អាន docker/default ត្រូវបានបដិសេធចាប់តាំងពី Kubernetes 1.11 ដូច្នេះសូមជៀសវាងការប្រើវា។

តាមគំនិតរបស់ខ្ញុំ ប្រវត្តិរូប runtime/default សមឥតខ្ចោះសម្រាប់គោលបំណងដែលវាត្រូវបានបង្កើតឡើង៖ ការពារអ្នកប្រើប្រាស់ពីហានិភ័យដែលទាក់ទងនឹងការប្រតិបត្តិពាក្យបញ្ជា docker run នៅលើរថយន្តរបស់ពួកគេ។ ទោះជាយ៉ាងណាក៏ដោយ នៅពេលនិយាយអំពីកម្មវិធីអាជីវកម្មដែលដំណើរការលើចង្កោម Kubernetes ខ្ញុំនឹងហ៊ានប្រកែកថាទម្រង់បែបនេះគឺបើកចំហពេក ហើយអ្នកអភិវឌ្ឍន៍គួរតែផ្តោតលើការបង្កើតទម្រង់សម្រាប់កម្មវិធីរបស់ពួកគេ (ឬប្រភេទនៃកម្មវិធី)។

គន្លឹះលេខ ៤៖ បង្កើតទម្រង់ seccomp សម្រាប់កម្មវិធីជាក់លាក់។ ប្រសិនបើវាមិនអាចទៅរួច បង្កើតទម្រង់សម្រាប់ប្រភេទកម្មវិធី ឧទាហរណ៍ បង្កើតទម្រង់កម្រិតខ្ពស់ដែលរួមបញ្ចូល API បណ្ដាញទាំងអស់នៃកម្មវិធី Golang ។ ប្រើតែពេលរត់/លំនាំដើមជាជម្រើសចុងក្រោយប៉ុណ្ណោះ។

នៅក្នុងការបង្ហោះនាពេលអនាគត ខ្ញុំនឹងរៀបរាប់អំពីរបៀបបង្កើតទម្រង់ seccomp ដែលបំផុសគំនិតដោយ SecDevOps ស្វ័យប្រវត្តិកម្មពួកវា និងសាកល្បងពួកវានៅក្នុងបំពង់។ ម្យ៉ាងវិញទៀត អ្នកនឹងគ្មានលេសមិនធ្វើបច្ចុប្បន្នភាពទៅទម្រង់ជាក់លាក់នៃកម្មវិធីនោះទេ។

4. Unconfined មិនមែនជាជម្រើសទេ។

ពី សវនកម្មសុវត្ថិភាព Kubernetes ដំបូង វាប្រែថាតាមលំនាំដើម seccomp ត្រូវបានបិទ. នេះមានន័យថាប្រសិនបើអ្នកមិនកំណត់ PodSecurityPolicyដែលនឹងបើកវានៅក្នុងចង្កោម ផតទាំងអស់ដែលទម្រង់ seccomp មិនត្រូវបានកំណត់នឹងដំណើរការនៅក្នុង seccomp=unconfined.

ដំណើរការនៅក្នុងរបៀបនេះមានន័យថាស្រទាប់អ៊ីសូឡង់ទាំងមូលត្រូវបានបាត់បង់ដែលការពារចង្កោម។ វិធីសាស្រ្តនេះមិនត្រូវបានណែនាំដោយអ្នកជំនាញសន្តិសុខទេ។

គន្លឹះលេខ ៤៖ គ្មានកុងតឺន័រនៅក្នុងចង្កោមគួរតែដំណើរការនៅក្នុង seccomp=unconfinedជាពិសេសនៅក្នុងបរិយាកាសផលិតកម្ម។

5. "របៀបសវនកម្ម"

ចំណុចនេះមិនមានតែមួយគត់សម្រាប់ Kubernetes នោះទេ ប៉ុន្តែនៅតែស្ថិតក្នុងប្រភេទ "រឿងដែលត្រូវដឹងមុនពេលអ្នកចាប់ផ្តើម"។

ដូចដែលវាកើតឡើង ការបង្កើតទម្រង់ seccomp តែងតែមានបញ្ហាប្រឈម និងពឹងផ្អែកខ្លាំងលើការសាកល្បង និងកំហុស។ ការពិតគឺថាអ្នកប្រើប្រាស់មិនមានឱកាសសាកល្បងពួកវានៅក្នុងបរិយាកាសផលិតកម្មដោយមិនប្រថុយនឹង "ទម្លាក់" កម្មវិធីនោះទេ។

បន្ទាប់ពីការចេញផ្សាយនៃខឺណែលលីនុច 4.14 វាអាចដំណើរការផ្នែកនៃទម្រង់នៅក្នុងរបៀបសវនកម្ម ដោយកត់ត្រាព័ត៌មានអំពីការហៅប្រព័ន្ធទាំងអស់នៅក្នុង syslog ប៉ុន្តែដោយមិនរារាំងពួកគេ។ អ្នកអាចធ្វើឱ្យរបៀបនេះសកម្មដោយប្រើប៉ារ៉ាម៉ែត្រ SCMT_ACT_LOG:

SCMP_ACT_LOG: seccomp នឹងមិនប៉ះពាល់ដល់ខ្សែស្រឡាយដែលធ្វើការហៅប្រព័ន្ធប្រសិនបើវាមិនត្រូវគ្នានឹងច្បាប់ណាមួយនៅក្នុងតម្រង ប៉ុន្តែព័ត៌មានអំពីការហៅប្រព័ន្ធនឹងត្រូវបានកត់ត្រា។

នេះជាយុទ្ធសាស្ត្រធម្មតាសម្រាប់ការប្រើប្រាស់មុខងារនេះ៖

អនុញ្ញាតការហៅតាមប្រព័ន្ធដែលត្រូវការ។
រារាំងការហៅចេញពីប្រព័ន្ធដែលអ្នកដឹងថានឹងមិនមានប្រយោជន៍ទេ។
កត់ត្រាព័ត៌មានអំពីការហៅទូរសព្ទផ្សេងទៀតទាំងអស់នៅក្នុងកំណត់ហេតុ។

ឧទាហរណ៍សាមញ្ញមើលទៅដូចនេះ៖

{
    "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"
        }
    ]
}

(មធ្យម-mixed-seccomp.json)

ប៉ុន្តែត្រូវចាំថា អ្នកត្រូវបិទការហៅទូរសព្ទទាំងអស់ដែលអ្នកដឹងថានឹងមិនត្រូវបានប្រើ ហើយវាអាចបង្កគ្រោះថ្នាក់ដល់ចង្កោម។ មូលដ្ឋានដ៏ល្អសម្រាប់ការចងក្រងបញ្ជីគឺជាផ្លូវការ ឯកសារ Docker. វាពន្យល់យ៉ាងលម្អិតថាតើការហៅប្រព័ន្ធណាមួយត្រូវបានរារាំងនៅក្នុងទម្រង់លំនាំដើម និងមូលហេតុ។

ទោះយ៉ាងណាក៏ដោយមានការចាប់មួយ។ ទោះបីជា SCMT_ACT_LOG គាំទ្រដោយខឺណែលលីនុចចាប់តាំងពីចុងឆ្នាំ 2017 វាបានចូលទៅក្នុងប្រព័ន្ធអេកូ Kubernetes ថ្មីៗនេះប៉ុណ្ណោះ។ ដូច្នេះ ដើម្បីប្រើវិធីនេះ អ្នកនឹងត្រូវការខឺណែលលីនុច 4.14 និងកំណែ runC មិនទាបជាង v1.0.0-rc9.

គន្លឹះលេខ ៤៖ ទម្រង់បែបបទសវនកម្មសម្រាប់ការធ្វើតេស្តនៅក្នុងការផលិតអាចត្រូវបានបង្កើតដោយការរួមបញ្ចូលបញ្ជីខ្មៅ និងស ហើយករណីលើកលែងទាំងអស់អាចចូលបាន។

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",

សម្រាប់ពេលនេះ នេះគ្រាន់តែជាឧទាហរណ៍ប៉ុណ្ណោះ ព័ត៌មានលម្អិតបន្ថែមអំពីឧបករណ៍នឹងធ្វើតាម។

គន្លឹះលេខ ៤៖ អនុញ្ញាតឱ្យតែការហៅទូរសព្ទដែលអ្នកពិតជាត្រូវការ ហើយរារាំងអ្នកផ្សេងទាំងអស់។

7. ដាក់មូលដ្ឋានគ្រឹះត្រឹមត្រូវ (ឬរៀបចំសម្រាប់អាកប្បកិរិយាដែលមិននឹកស្មានដល់)

ខឺណែលនឹងពង្រឹងទម្រង់ដោយមិនគិតពីអ្វីដែលអ្នកសរសេរនៅក្នុងវា។ ទោះបីជាវាមិនមែនជាអ្វីដែលអ្នកចង់បានក៏ដោយ។ ឧទាហរណ៍ប្រសិនបើអ្នករារាំងការចូលប្រើការហៅទូរស័ព្ទដូចជា exit ឬ exit_groupកុងតឺន័រនឹងមិនអាចបិទបានត្រឹមត្រូវ និងសូម្បីតែពាក្យបញ្ជាសាមញ្ញដូចជា echo hi ព្យួរគាត់o សម្រាប់រយៈពេលមិនកំណត់។ ជាលទ្ធផល អ្នកនឹងទទួលបានការប្រើប្រាស់ CPU ខ្ពស់នៅក្នុងចង្កោម៖

ក្នុងករណីបែបនេះ ឧបករណ៍ប្រើប្រាស់អាចមកជួយសង្គ្រោះបាន។ strace - វានឹងបង្ហាញពីបញ្ហាដែលអាចកើតមាន៖

sudo strace -c -p 9331

ត្រូវប្រាកដថាទម្រង់មានការហៅប្រព័ន្ធទាំងអស់ដែលកម្មវិធីត្រូវការនៅពេលដំណើរការ។

គន្លឹះលេខ ៤៖ យកចិត្តទុកដាក់ចំពោះព័ត៌មានលម្អិត និងត្រូវប្រាកដថាការហៅតាមប្រព័ន្ធចាំបាច់ទាំងអស់ត្រូវបានដាក់ក្នុងបញ្ជីស។

នេះបញ្ចប់ផ្នែកដំបូងនៃអត្ថបទជាបន្តបន្ទាប់អំពីការប្រើប្រាស់ seccomp នៅក្នុង Kubernetes ក្នុងស្មារតីនៃ SecDevOps ។ នៅក្នុងផ្នែកខាងក្រោម យើងនឹងនិយាយអំពីមូលហេតុដែលវាសំខាន់ និងរបៀបធ្វើឱ្យដំណើរការដោយស្វ័យប្រវត្តិ។

PS ពីអ្នកបកប្រែ

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

ប្រភព: www.habr.com

Seccomp in Kubernetes៖ ៧ យ៉ាងដែលអ្នកត្រូវដឹងតាំងពីដំបូង