Kubernetes қазіргі таңда контейнерлерді басқарудың және оркестрлеудің стандартты шешімі болып табылады, ол бұлттық және жергілікті инфрақұрылымдарда кеңінен қолданылады. Дегенмен, Kubernetes қауіпсіздігі — тек кластердің өзін ғана қорғау емес, контейнерлердің, қосымшалардың және осы контейнерлердегі деректердің де қауіпсіздігін қамтамасыз ету. Бұл мақалада біз Kubernetes контейнерлерінің қауіпсіздігі туралы тереңірек талдаймыз, контейнерлердің бейнелерін қорғаудан бастап, желі, қолжетімділік басқару және лог жүргізуге дейін.
1. Контейнерлердің бейнесін қорғау
1.1. Қауіпсіз контейнер бейнелерін қолдану
Контейнерлер Kubernetes-те Docker бейнелері (немесе басқа форматтар) негізінде жұмыс істейді. Бұл бейнелердің қауіпсіздігі — инфрақұрылымның қорғанысының маңызды бөлігі.
Бейнелердегі мәселелер
Тексерілмеген, ескірген немесе осал бейнелерді қолдану, зиянды кодты немесе осалдықтарды енгізуі мүмкін. Жиі бейнелер жаңартылмайды және сканерленбейді, бұл жүйеде осалдық туғызуы мүмкін.
Ұсыныстар:
-
Ресми бейнелерді қолдану. Әдетте ресми, тексерілген бейнелерді пайдалану ұсынылады, мысалы, Docker Hub немесе басқа сенімді репозиторийлерде жарияланған бейнелер.
Мысал:
FROM node:16-alpine -
Бейнелердің көлемін азайту. Контейнердің көлемі neғұрлым аз болса, соғұрлым ол шабуылдардың әсеріне аз түседі. Alpine негізінде жасалған бейнелер, мысалы, аз пакеттер мен тәуелділіктері арқасында қауіпсіз болады.
Dockerfile мысалы:
FROM alpine:3.15 RUN apk add --no-cache curl -
Бейнелерді осалдықтарға тексеру. Контейнерді іске қоспас бұрын, бейнені танымал осалдықтарға тексеру өте маңызды. Мысалы, бейнелерді тексеру үшін Clair немесе Trivy сияқты құралдарды қолдануға болады.
Trivy көмегімен тексеру мысалы:
trivy image my-app:latestБұл команданы орындау арқылы танымал осалдықтар анықталады және оларды түзету жолдары беріледі.
1.2. Контейнерлер үшін ең аз құқықтар принципі
Контейнерлер тек қажетті минималды құқықтармен жұмыс істеуі керек. Бұл контейнердің осалдықтарын пайдаланып хосттық жүйеге немесе басқа контейнерлерге әсер ету ықтималдығын азайтады.
Минималды құқықтарды орнату мысалы:
Dockerfile ішінде контейнерді әкімші құқықтарынсыз жұмыс істеуге баптауға болады:
FROM node:16-alpine
# Ең аз құқықтармен жаңа қолданушы жасаймыз
RUN adduser -D myuser
USER myuser
Контейнер осы қолданушының құқықтарымен іске қосылады, яғни егер зиянкес контейнерге кірсе, ол жүйеге зиян келтіре алмайды.
Docker қолдану мысалдары:
Контейнерді нақты пайдаланушы құқықтарымен іске қосу:
docker run --user 1001 my-app
Бұл команданы орындау контейнерді root құқықтарымен емес, шектелген құқықтармен іске қосуға мүмкіндік береді.
1.3. Привилегияланған контейнерлерді өшіру
Привилегияланған контейнерлер хост-машинаға толық қолжетімділік береді және шабуыл жасаушының жүйеге зиян келтіруіне мүмкіндік береді. Kubernetes қосымша қауіпсіздік үшін PodSecurityPolicies (PSP) көмегімен привилегияланған контейнерлерді іске қосуды тоқтатуға мүмкіндік береді.
PodSecurityPolicy конфигурациясының мысалы:
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted-psp
spec:
privileged: false # Привилегияланған контейнерлерді өшіреміз
allowPrivilegeEscalation: false # Привилегияларды көтеруге жол бермейміз
volumes:
- 'configMap'
- 'emptyDir'
Бұл саясат контейнерлерді привилегиялармен іске қосуға тыйым салады, бұл жүйені қорғаудың қосымша шарасы болып табылады.
2. Kubernetes кластерінің деңгейінде қауіпсіздік
2.1. Қолжетімділік басқару және аутентификация
Kubernetes-тің қауіпсіздігінің маңызды аспектілерінің бірі — қолжетімділікті басқару. Kubernetes жүйесінде RBAC (Role-Based Access Control) қолжетімділікті шектеу үшін қолданылады, бұл API-ге және кластер ресурстарына қолжетімділікті реттейді.
RBAC көмегімен рөлдер мен құқықтарды баптау
Kubernetes-те қолжетімділік басқарудың ең жақсы тәсілі — минималды құқықтар принципін қолдану.
Құқықтары шектеулі рөлді жасау мысалы:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
pod-reader рөлі тек default кеңістігінде подтар туралы ақпаратты оқу үшін құқықтарды береді.
Рөлді байлау (RoleBinding) мысалы:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: "alice"
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Бұл мысал alice пайдаланушысына default кеңістігінде тек подтарды көруге құқық береді.
2.2. Kubernetes жүйесінде деректерді шифрлау
Kubernetes-те деректерді қауіпсіз сақтаудың маңызды аспектісі — бұл etcd деп аталатын компонентте сақталатын маңызды деректерді шифрлау.
Секреттерді шифрлау конфигурациясы
Kubernetes-де секреттерді шифрлау үшін API серверін баптап, шифрлау конфигурациясын орнату қажет.
Секреттерді шифрлау конфигурациясы мысалы:
apiVersion: encryption.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aes256gcm:
keys:
- name: key1
secret: base64encodedkey
Бұл конфигурация Kubernetes жүйесінде барлық секреттерді AES-256 алгоритмімен шифрлауды орнатады.
2.3. Аудит және лог жүргізу
Қауіпсіздікті қамтамасыз ету үшін кластердегі барлық әрекеттерді қадағалап отыру керек. Kubernetes жүйесінде өздігінен аудит жүргізу мүмкіндігі бар, бұл барлық API сұрауларын бақылауға мүмкіндік береді.
Kubernetes-де аудитті баптау
Аудит конфигурациясын орнату API серверіне жасалған сұраулар мен әрекеттер туралы мәліметтер жинауға мүмкіндік береді.
Аудит саясатының мысалы:
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
resources:
- group: ""
resources: ["pods"]
users: ["alice"]
Бұл конфигурация барлық alice пайдаланушысының подтармен әрекеттерін лог жазады.
3. Желідегі қауіпсіздік
3.1. Желілік саясаттар
Kubernetes желілік саясаттарды қолдайды, олар контейнерлер арасындағы трафикті басқаруға мүмкіндік береді.
Қауіпсіздік саясатын орнату мысалы:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all
namespace: default
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
Бұл саясат барлық трафикті default кеңістігіндегі барлық подтар үшін блоктайды.
Белгілі бір подқа тек қосылуға рұқсат беретін саясат:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-specific-pod
namespace: default
spec:
podSelector:
matchLabels:
app: my-app
ingress:
- from:
- podSelector:
matchLabels:
app: my-other-app
Бұл саясат тек my-app лейблі бар подтардан my-other-app лейблі бар подтарға кіруге рұқсат береді.
3.2. "Man-in-the-Middle" (MitM) шабуылдарынан қорғау
Желідегі деректердің қауіпсіздігін қамтамасыз ету үшін TLS шифрлауын қолдану керек. Kubernetes барлық ішкі байланыстар үшін TLS шифрлауын қолдайды.
Kubernetes ішкі компоненттері арасындағы TLS шифрлауды қосу:
Kubernetes компоненттері арасында шифрлауды орнату үшін сенімді сертификаттарды қолдану қажет.
4. Қауіпсіздікті бақылау
4.1. Falco пайдалану
Falco — контейнерлер мен подтардың қауіпсіздігін бақылауға арналған құрал, ол оларды нақты уақытта бақылап, күдікті әрекеттерді анықтайды.
Falco орнату және пайдалану:
- Kubernetes кластеріне Falco орнату:
kubectl create -f https://raw.githubusercontent.com/falcosecurity/falco/master/deploy/kubernetes/falco.yaml
- Root құқықтарымен командаларды орындауды бақылау үшін қауіпсіздік ережелерін баптау.
4.2. Kube-bench пайдалану
Kube-bench — Kubernetes жүйесінің қауіпсіздігін тексеруге арналған құрал, ол CIS Kubernetes стандарттарына сәйкестігін тексереді.
Kube-bench іске қосу:
kube-bench run --targets node
Бұл құрал Kubernetes жүйесінің қауіпсіздігін тексеріп, анықталған осалдықтар туралы хабарлайды.
Қорытынды
Kubernetes контейнерлерін қорғау — бұл көп деңгейлі процесс, ол контейнер бейнелерінен бастап, кластердің, желінің және жүйенің қауіпсіздігін қамтамасыз етуге дейін қамтиды. Минималды құқықтар принципін қолдану, деректерді шифрлау, мониторинг және қауіпсіздік құралдарын пайдалану сіздің кластеріңіз бен қосымшаларыңыздың қауіпсіздігін едәуір арттыра алады. Ең бастысы, қауіпсіздік — бұл үздіксіз процесс, және әрдайым жаңа шабуылдарға қарсы тұру үшін жүйені үнемі жаңарту мен тексеру қажет.
| Реклама Google |
 |
Назар аударыңыз! Бұл мақала ресми құжат емес.Ақпаратты сақтықпен және сынақ ортасында пайдалану керек.
Заманауи сақтық көшірме жасау, репликациялау, деректерді синхрондау және төлемдік бағдарламадан қорғау жүйелерін құру туралы сұрақтарыңыз болса, қазіргі заманғы деректердің сақтық көшірмесін жасау және қалпына келтіру технологиялары бойынша кеңес алу үшін біздің компанияға хабарласыңыз . Біздің компанияның осы салада 20 жылдан астам тәжірибесі бар. |
||||
Қазақстандағы резервтік көшірудің ең жақсы он тәжірибесі
- oVirt гипервизорын қорғау — терең талдау
- oVirt жүйесінен Proxmox жүйесіне виртуалды машинаны көшіру
- Proxmox-тан oVirt-ке виртуалды машинаны көшіру
- Kubernetes контейнерлерін қорғау — терең талдау
- Proxmox гипервизорын бұзудан қалай қорғауға болады - Терең талдау
- Fail2Ban-ды oVirt жүйесін қорғауда қолдану - Терең талдау
- oVirt гипервизорын сақтандыруды ұйымдастыру — Терең талдау
- Виртуалды машинаны гипервизорлар арасында Proxmox арқылы көшіру
- Proxmox гипервизорын виртуалды машиналардың оңтайлы жұмысын қамтамасыз ету үшін конфигурациялау
- Proxmox-те SSH арқылы root құқықтарының бұзылуынан қорғау: терең талдау
