რატომ არის ცუდი პრაქტიკა Kubernetes-ში კონტეინერის გაშვება root მომხმარებლად?

კონტეინერების გაშვება Kubernetes-ში root მომხმარებლისგან ზრდის უსაფრთხოების რისკებს:

• მაღალი პრივილეგიების დონე: კონტეინერის დარღვევის შემთხვევაში, დამნაშავე მიიღებს root უფლებებს კონტეინერში. ეს შეიძლება იწვიოს პრივილეგიების გაზრდას ჰოსტის სისტემაში ან სხვა რესურსებზე წვდომას.
• წვდომა ჰოსტის ფაილურ სისტემაზე: საჭირო შეზღუდვების გარეშე, კონტეინერის შიგნით root პროცესი შეიძლება ჰქონდეს წვდომა ნიშნის ფაილურ სისტემაზე, რაც ზრდის არაოფიციალური ცვლილებების ან მონაცემთა გაჟონვის ალბათობას.
• გაფართოებული ბირთვის სუსტი ადგილები: კონტეინერის root მომხმარებელი შეიძლება გამოიყენოს Linux-ის ბირთვის სუსტი ადგილები, რათა გამოვიდეს კონტეინერიდან და მიიღოს კონტროლი ჰოსტზე.
• აუდიტის სირთულე: root მომხმარებლის მოქმედებების თვალთვალი უფრო რთულია, რაც აფერხებს უსაფრთხოების ინციდენტების გამოვლენასა და გამოძიებას.
• პრივილეგიების მემკვიდრეობა: თუ სხვა პროცესები იწყება ძირითადი მომხმარებლიდან, მათაც ექნებათ მაღალი პრივილეგიების დონე.

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

securityContext:
  runAsUser: 1000  # არა-პრივილეგირებულ მომხმარებელზე გამოყენება, ID 1000
  runAsGroup: 3000 # ჯგუფის წევრობა, ID 3000
  allowPrivilegeEscalation: false # პრივილეგიების გაზრდის აკრძალვა
readOnlyRootFilesystem: true # ფაილური სისტემის წერის აკრძალვა

სხვა გამოყენება შესაძლებელია:

• Pod Security Policies / Pod Security Admission: უსაფრთხოების პოლიტიკების გამოყენება პოდზე.
• AppArmor / SELinux: დამატებითი იზოლაციისთვის.
• კონტეინერის გამოსახულებების გამოყენება, სადაც ნათლად მითითებულია არა-პრივილეგირებულ მომხმარებელი: Dockerfile-ში USER ბრძანებით:

# მაგალითი Dockerfile-ით, სადაც მითითებულია მომხმარებელი
FROM ubuntu:latest
# არა-პრივილეგირებულ მომხმარებლის შექმნა
RUN useradd -ms /bin/bash myuser
# გადართვა შექმნილ მომხმარებელზე
USER myuser
CMD ["/bin/bash"]