Seccomp Kubernetes-ში: 7 რამ, რაც თავიდანვე უნდა იცოდეთ

Შენიშვნა. თარგმნა: თქვენს ყურადღებას წარმოგიდგენთ ბრიტანული კომპანია ASOS.com-ის აპლიკაციის უსაფრთხოების უფროსი ინჟინრის სტატიის თარგმანს. მასთან ერთად ის იწყებს პუბლიკაციების სერიას, რომელიც ეძღვნება Kubernetes-ში უსაფრთხოების გაუმჯობესებას seccomp-ის გამოყენებით. თუ მკითხველს შესავალი მოეწონება, მივყვებით ავტორს და გავაგრძელებთ მის შემდგომ მასალებს ამ თემაზე.

ეს სტატია პირველია პოსტების სერიიდან, თუ როგორ შევქმნათ seccomp პროფილები SecDevOps-ის სულისკვეთებით, მაგიის და ჯადოქრობის გარეშე. პირველ ნაწილში მე გავაშუქებ 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 ჩამოთვლილია სამიზნე არქიტექტურები. ეს მნიშვნელოვანია, რადგან თავად ფილტრი, რომელიც გამოიყენება ბირთვის დონეზე, დამოკიდებულია სისტემის ზარის იდენტიფიკატორებზე და არა მათ სახელებზე, რომლებიც მითითებულია პროფილში. კონტეინერის მუშაობის დრო დაემთხვევა მათ იდენტიფიკატორებს გამოყენებამდე. იდეა ისაა, რომ სისტემურ ზარებს შეიძლება ჰქონდეთ სრულიად განსხვავებული ID-ები, რაც დამოკიდებულია სისტემის არქიტექტურაზე. მაგალითად, სისტემური ზარი recvfrom (გამოიყენება სოკეტიდან ინფორმაციის მისაღებად) აქვს ID = 64 x64 სისტემებზე და ID = 517 x86-ზე. აქ თქვენ შეგიძლიათ იპოვოთ სისტემური ზარების სია x86-x64 არქიტექტურებისთვის.

განყოფილებაში syscalls ჩამოთვლის ყველა სისტემურ ზარს და აკონკრეტებს რა უნდა გააკეთოს მათთან. მაგალითად, შეგიძლიათ შექმნათ თეთრი სია პარამეტრით defaultAction on SCMP_ACT_ERRNO, და რეკავს განყოფილებაში syscalls დაავალოს SCMP_ACT_ALLOW. ამრიგად, თქვენ მხოლოდ განყოფილებაში მითითებულ ზარებს უშვებთ syscalls, და აკრძალოს ყველა სხვა. შავი სიისთვის თქვენ უნდა შეცვალოთ მნიშვნელობები defaultAction და საპირისპირო მოქმედებები.

ახლა ჩვენ უნდა ვთქვათ რამდენიმე სიტყვა ნიუანსებზე, რომლებიც არც ისე აშკარაა. გთხოვთ, გაითვალისწინოთ, რომ ქვემოთ მოცემული რეკომენდაციები ვარაუდობს, რომ თქვენ განათავსებთ ბიზნეს აპლიკაციების ხაზს Kubernetes-ზე და გსურთ, რომ ისინი მუშაობდნენ მინიმალური პრივილეგიებით.

1. AllowPrivilegeEscalation=false

В securityContext კონტეინერს აქვს პარამეტრი AllowPrivilegeEscalation. თუ ის დაინსტალირებულია false, კონტეინერები დაიწყება (on) ცოტა no_new_priv. ამ პარამეტრის მნიშვნელობა აშკარაა სახელიდან: ის ხელს უშლის კონტეინერს ახალი პროცესების გაშვებაში მეტი პრივილეგიებით, ვიდრე თავად აქვს.

ამ პარამეტრის დაყენების გვერდითი ეფექტი true (ნაგულისხმევი) არის ის, რომ კონტეინერის გაშვების დრო იყენებს seccomp პროფილს გაშვების პროცესის დასაწყისშივე. ამდენად, ყველა სისტემური ზარი, რომელიც საჭიროა შიდა გაშვების პროცესების გასაშვებად (მაგ. მომხმარებლის/ჯგუფის ID-ების დაყენება, ზოგიერთი შესაძლებლობების ამოღება) ჩართული უნდა იყოს პროფილში.

კონტეინერამდე, რომელიც წვრილმან საქმეებს აკეთებს 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 პროფილის დაყენება შესაძლებელია 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 - დაახლ. თარგმანი).

ცოტამ თუ იცის, რომ Kubernetes ყოველთვის ჰქონდა შეცდომარამაც გამოიწვია seccomp პროფილების გამოყენება პაუზის კონტეინერი. გაშვების გარემო ნაწილობრივ ანაზღაურებს ამ ხარვეზს, მაგრამ ეს კონტეინერი არ ქრება პოდებიდან, რადგან ის გამოიყენება მათი ინფრასტრუქტურის კონფიგურაციისთვის.

პრობლემა ის არის, რომ ეს კონტეინერი ყოველთვის იწყება AllowPrivilegeEscalation=true, რაც იწვევს პირველ პუნქტში გაჟღერებულ პრობლემებს და ამის შეცვლა შეუძლებელია.

კონტეინერის დონეზე seccomp პროფილების გამოყენებით, თქვენ თავიდან აიცილებთ ამ ხარვეზს და შეგიძლიათ შექმნათ პროფილი, რომელიც მორგებულია კონკრეტულ კონტეინერზე. ეს უნდა გაკეთდეს მანამ, სანამ დეველოპერები არ გამოასწორებენ შეცდომას და ახალი ვერსია (იქნებ 1.18?) ყველასთვის ხელმისაწვდომი გახდება.

რჩევა # 2: დააყენეთ seccomp პროფილები კონტეინერის დონეზე.

პრაქტიკული გაგებით, ეს წესი ჩვეულებრივ ემსახურება როგორც უნივერსალურ პასუხს კითხვაზე: „რატომ მუშაობს ჩემი სეკკომპ პროფილი docker runმაგრამ არ მუშაობს კუბერნეტის კლასტერში განლაგების შემდეგ?

3. გამოიყენეთ Runtime/Default მხოლოდ როგორც ბოლო საშუალება

Kubernetes-ს აქვს ორი ვარიანტი ჩაშენებული პროფილებისთვის: runtime/default и docker/default. ორივე ხორციელდება კონტეინერის გაშვების დროით და არა Kubernetes-ით. ამიტომ, ისინი შეიძლება განსხვავდებოდეს გამოყენებული გაშვების გარემოსა და მისი ვერსიის მიხედვით.

სხვა სიტყვებით რომ ვთქვათ, მუშაობის დროის შეცვლის შედეგად, კონტეინერს შეიძლება ჰქონდეს წვდომა სხვადასხვა სისტემური ზარების კომპლექტზე, რომელიც მან შეიძლება გამოიყენოს ან არ გამოიყენოს. გაშვების უმეტესობა იყენებს დოკერის განხორციელება. თუ გსურთ ამ პროფილის გამოყენება, დარწმუნდით, რომ ის თქვენთვის შესაფერისია.

პროფილის docker/default მოძველებულია Kubernetes 1.11-ის შემდეგ, ამიტომ მოერიდეთ მის გამოყენებას.

ჩემი აზრით, პროფილი runtime/default იდეალურად შეეფერება იმ მიზნებს, რისთვისაც შეიქმნა: მომხმარებლების დაცვა ბრძანების შესრულებასთან დაკავშირებული რისკებისგან docker run მათ მანქანებზე. თუმცა, როდესაც საქმე ეხება Kubernetes კლასტერებზე გაშვებულ ბიზნეს აპლიკაციებს, მე გავბედავ ამტკიცებს, რომ ასეთი პროფილი ძალიან ღიაა და დეველოპერებმა უნდა გაამახვილონ ყურადღება მათი აპლიკაციების (ან აპლიკაციების ტიპების) პროფილების შექმნაზე.

რჩევა # 3: შექმენით seccomp პროფილები კონკრეტული აპლიკაციებისთვის. თუ ეს შეუძლებელია, შექმენით პროფილები აპლიკაციის ტიპებისთვის, მაგალითად, შექმენით გაფართოებული პროფილი, რომელიც მოიცავს Golang აპლიკაციის ყველა ვებ API-ს. გამოიყენეთ გაშვების/ნაგულისხმევი დრო მხოლოდ როგორც ბოლო საშუალება.

მომავალ პოსტებში მე განვიხილავ, თუ როგორ შევქმნათ SecDevOps-ით შთაგონებული seccomp პროფილები, ავტომატიზირება და ტესტირება მილსადენებში. სხვა სიტყვებით რომ ვთქვათ, თქვენ არ გექნებათ საბაბი, რომ არ განაახლოთ პროგრამის სპეციფიკურ პროფილებზე.

4. შეუზღუდავი არ არის ვარიანტი.

Of პირველი Kubernetes უსაფრთხოების აუდიტი აღმოჩნდა რომ ნაგულისხმევად seccomp გამორთულია. ეს ნიშნავს, რომ თუ არ დააყენეთ PodSecurityPolicy, რომელიც ჩართავს მას კლასტერში, ყველა პოდი, რომლისთვისაც seccomp პროფილი არ არის განსაზღვრული, იმუშავებს seccomp=unconfined.

ამ რეჟიმში მუშაობა ნიშნავს, რომ იკარგება იზოლაციის მთელი ფენა, რომელიც იცავს კლასტერს. ეს მიდგომა არ არის რეკომენდებული უსაფრთხოების ექსპერტების მიერ.

რჩევა # 4: კლასტერში არცერთი კონტეინერი არ უნდა იყოს გაშვებული seccomp=unconfinedგანსაკუთრებით საწარმოო გარემოში.

5. "აუდიტის რეჟიმი"

ეს პუნქტი არ არის უნიკალური Kubernetes-ისთვის, მაგრამ მაინც მიეკუთვნება „რაც უნდა იცოდე დაწყებამდე“ კატეგორიაში.

როგორც ეს ხდება, seccomp პროფილების შექმნა ყოველთვის რთული იყო და დიდწილად ეყრდნობა საცდელსა და შეცდომებს. ფაქტია, რომ მომხმარებლებს უბრალოდ არ აქვთ შესაძლებლობა შეამოწმონ ისინი საწარმოო გარემოში აპლიკაციის „ჩავარდნის“ რისკის გარეშე.

Linux kernel 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 Linux-ის ბირთვის მხარდაჭერით 2017 წლის ბოლოდან, იგი შედარებით ცოტა ხნის წინ შევიდა Kubernetes-ის ეკოსისტემაში. ამიტომ, ამ მეთოდის გამოსაყენებლად დაგჭირდებათ Linux kernel 4.14 და runC ვერსია არა დაბალი v1.0.0-rc9.

რჩევა # 5: წარმოებაში ტესტირებისთვის აუდიტის რეჟიმის პროფილი შეიძლება შეიქმნას შავი და თეთრი სიების კომბინაციით და ყველა გამონაკლისის დარეგისტრირება შესაძლებელია.

6. გამოიყენეთ თეთრი სიები

Whitelisting მოითხოვს დამატებით ძალისხმევას, რადგან თქვენ უნდა დაადგინოთ ყველა ზარი, რომელიც შეიძლება დაგჭირდეს აპლიკაციას, მაგრამ ეს მიდგომა მნიშვნელოვნად აუმჯობესებს უსაფრთხოებას:

რეკომენდებულია თეთრი სიის მიდგომის გამოყენება, რადგან ის უფრო მარტივი და საიმედოა. შავი სია უნდა განახლდეს, როდესაც ემატება პოტენციურად საშიში სისტემური ზარი (ან საშიში დროშა/ოფცია, თუ ის შავ სიაშია). გარდა ამისა, ხშირად შესაძლებელია პარამეტრის წარმოდგენის შეცვლა მისი არსის შეცვლის გარეშე და ამით შავი სიის შეზღუდვების გვერდის ავლით.

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: ყურადღება მიაქციეთ დეტალებს და დარწმუნდით, რომ ყველა საჭირო სისტემური ზარი არის თეთრ სიაში.

ამით დასრულდა სტატიების სერიის პირველი ნაწილი Kubernetes-ში seccomp-ის გამოყენების შესახებ SecDevOps-ის სულისკვეთებით. შემდეგ ნაწილებში ვისაუბრებთ იმაზე, თუ რატომ არის ეს მნიშვნელოვანი და როგორ მოვახდინოთ პროცესის ავტომატიზაცია.

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «უსაფრთხოება Docker კონტეინერებისთვის";
• «33+ Kubernetes უსაფრთხოების ინსტრუმენტები";
• «Docker და Kubernetes უსაფრთხოებისადმი მგრძნობიარე გარემოში";
• «9 საუკეთესო პრაქტიკა Kubernetes უსაფრთხოებისთვის".

წყარო: www.habr.com