偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

在Kubernetes部署中如何引導(dǎo)安全性

譯文
云計算
開發(fā)人員需要了解如何在容器化應(yīng)用程序中嵌入控件,以及如何啟用運行時保護機制以阻止黑客訪問容器化系統(tǒng)。

[[426719]]

【51CTO.com快譯】Kubernetes是當前流行和常用的容器編排工具之一。Kubernetes工作負載就像簡單的nginx服務(wù)器或cron作業(yè)一樣執(zhí)行的應(yīng)用程序。Kubernetes部署成為了一種最常用的工作負載,因為它可以輕松更新、擴展和管理。

最近發(fā)布的Kubernetes Hardening指南是一個很好的資源,它提供了有關(guān)如何有效保護Kubernetes的指導(dǎo)。該指南提供的信息清楚地表明,保護和強化Kubernetes不僅是Kubernetes管理員的工作,也是在集群上部署工作負載的開發(fā)人員的工作。

本文討論部署Kubernetes工作負載的開發(fā)人員如何通過應(yīng)用“Kubernetes強化指南”提供的一些指南來引導(dǎo)安全性。

這是一個實用的指南,將采用一個簡單的Dockerfile,然后逐步添加安全優(yōu)秀實踐來創(chuàng)建模板部署清單文件,開發(fā)人員可以快速重用該文件。

先決條件

  • Docker是必需的,因為將從頭開始構(gòu)建。
  • 像minikube這樣的單節(jié)點Kubernetes集群應(yīng)該遵循這一指南以及kubectl實用程序。開發(fā)人員可以使用官方minikube文檔在其環(huán)境中進行設(shè)置。

使用由與WSL2綁定的Docker Desktop創(chuàng)建的獨立集群作為后端。

本指南假設(shè)有一個可通過kubectl實用程序訪問的正在運行的集群,如下面的代碼所示。

  1. Shell 
  2. git clone git@github.com:salecharohit/bootstrapsecurityinkubernetesdeployment.git 
  3. cd springbootmaven 
  4. docker build . -f Dockerfile.basic -t springbootmaven 
  5. docker run --name springboot -d -p 8080:8080 springbootmaven 
  6. curl http://localhost:8080 
  7.  
  8. ​Expected Response: 
  9.  
  10. Hello World From Spring Boot Build Using Maven on Alpine OS! 

安全部署

保護Kubernetes工作負載可以有效地劃分為“構(gòu)建時”的安全性和“運行時”的安全性。為了運行這些示例,將使用這個簡單的Spring Boot Hello World應(yīng)用程序并將其部署在Kubernetes中,并應(yīng)用構(gòu)建時安全性和運行時安全性。相關(guān)網(wǎng)址如下: https://github.com/salecharohit/bootstrapsecurityinkubernetesdeployment

而在開始之前,先要克隆這個存儲庫,構(gòu)建Docker容器,并在本地運行應(yīng)用程序。

構(gòu)建時的安全性

構(gòu)建時的安全性更多地關(guān)注如何以減少的占用空間構(gòu)建底層容器,并編程以盡可能少的權(quán)限執(zhí)行。

以下將使用問題的解決方法討論這兩種方法:

(1)減少攻擊面

在容器中構(gòu)建應(yīng)用程序時,主要目標是讓應(yīng)用程序在不考慮運行環(huán)境的情況下始終獨立運行,無論其運行環(huán)境是數(shù)據(jù)中心、云平臺還是內(nèi)部部署設(shè)施。然而,在構(gòu)建這些應(yīng)用程序時有一條不成文的規(guī)則:它應(yīng)該是一個獨立的應(yīng)用程序,并且沒有很多依賴項。

以SpringBoot應(yīng)用程序為例。這個應(yīng)用程序運行的唯一依賴是它需要一個JVM或Java運行時。任何其他在容器中的東西實際上都是無用的。

例如,在基于AlpineOS構(gòu)建的SpringBoot容器中,沒有任何特定需要安裝apk包管理器。

  1. Shell  
  2. docker exec -it springboot /bin/sh 
  3. apk add curl 

因此,可以嘗試刪除apk二進制文件并重建或Docker映像。

此時將使用Dockerfile.asr來重建Docker容器,其共享如下:

  1. Dockerfile  
  2. FROM maven:3.8.1-openjdk-17-slim AS MAVEN_BUILD 
  3. WORKDIR /build/ 
  4. COPY pom.xml /build/ 
  5. COPY src /build/src/ 
  6. RUN mvn package 
  7.  
  8. FROM openjdk:17-alpine 
  9.  
  10. RUN rm -f /sbin/apk && \ 
  11. rm -rf /etc/apk && \ 
  12. rm -rf /lib/apk && \ 
  13. rm -rf /usr/share/apk && \ 
  14. rm -rf rm -rf /var/lib/apk 
  15.  
  16. COPY --from=MAVEN_BUILD /build/target/springbootmaven.jar /springbootmaven.jar 
  17. EXPOSE 8080 
  18. CMD java -jar /springbootmaven.jar 

在此重建并重新運行:

  1. Shell  
  2. First let's stop the previously running container 
  3. docker stop springboot  
  4. Next let's re-build and re-run 
  5. docker build . -f Dockerfile.asr -t springbootmaven  
  6. docker run --name springboot -p 8080:8080 springbootmaven  
  7. docker run --name springboot -d -p 8080:8080 springbootmaven  
  8. curl http://localhost:8080 

現(xiàn)在嘗試再次運行apk add curl命令。

  1. Shell  
  2. docker exec -it springboot /bin/sh  
  3. apk add curl 

因此成功擺脫了apk依賴,并且應(yīng)用程序運行成功!

下面是一些專門為強化Alpine OS編寫的優(yōu)秀腳本。根據(jù)編程語言進行挑選,并相應(yīng)地強化基本alpine圖像。以下是一些參考的網(wǎng)址:

另一方面,還可以查看由谷歌公司創(chuàng)建的distroless容器,這也是非常值得推薦的。

(2)切換用戶場景

有人可能會爭辯說,如果網(wǎng)絡(luò)攻擊者在容器內(nèi)獲得RCE,他們可能無法安裝curl、wget等包來建立持久性。

但是,仍然以“root”用戶身份運行,從技術(shù)上講,仍然可以重新安裝apk。

在此重新運行Docker容器并檢查它當前運行的權(quán)限。

  1. Shell  
  2. docker exec -it springboot /bin/sh  
  3. whoami  
  4. ping rohitsalecha.com  

因此,重要的是不要以root身份運行容器,而是以只有有限權(quán)限的用戶身份運行容器。

Dockerfile.lpr顯示了添加更多命令,這些命令添加了一個名為“boot”的用戶和組,并為其分配一個工作目錄(這是它的主目錄)。還為用戶和組分配了數(shù)值,以下將在Pod安全場景部分詳細討論。

  1. Dockerfile  
  2. FROM maven:3.8.1-openjdk-17-slim AS MAVEN_BUILD 
  3. WORKDIR /build/ 
  4. COPY pom.xml /build/ 
  5. COPY src /build/src/ 
  6. RUN mvn package 
  7.  
  8. FROM openjdk:17-alpine 
  9.  
  10. # Removing apk package manager 
  11. RUN rm -f /sbin/apk && \ 
  12. rm -rf /etc/apk && \ 
  13. rm -rf /lib/apk && \ 
  14. rm -rf /usr/share/apk && \ 
  15. rm -rf rm -rf /var/lib/apk 
  16.  
  17. # Adding a user and group called "boot" 
  18. RUN addgroup boot -g 1337 && \  
  19. adduser -D -h /home/boot -u 1337 -s /bin/ash boot -G boot 
  20.  
  21. # Changing the context that shall run the below commands with User "boot" instead of root 
  22. USER boot 
  23. WORKDIR /home/boot 
  24.  
  25. By default even in a non-root context, Docker copies the file as root. Hence its best practice to chown 
  26. # the files being copied as the user. https://stackoverflow.com/a/44766666/1679541 
  27. COPY --chown=boot:boot --from=MAVEN_BUILD /build/target/springbootmaven.jar /home/boot/springbootmaven.jar 
  28. EXPOSE 8080 
  29. CMD java -jar /home/boot/springbootmaven.jar 

重建并重新運行:

  1. First let's stop the previously running container 
  2. docker stop springboot  
  3. Next let's re-build and re-run 
  4. docker build . -f Dockerfile.lpr -t springbootmaven docker run --name springboot -d -p 8080:8080 springbootmaven curl http://localhost:8080 

現(xiàn)在嘗試運行whoami命令,并檢查現(xiàn)在正在運行哪個容器的哪些權(quán)限。

  1. Shell  
  2. docker exec -it springboot /bin/sh  
  3. whoami  
  4. ping rohitsalecha.com 

運行時的安全性

現(xiàn)在人們對構(gòu)建時安全性有了很大的信心,其中已經(jīng)學會了刪除包并更新用戶場景,以使用有限的權(quán)限運行容器。這些安全特性是在構(gòu)建Docker容器時應(yīng)用的;但是,還需要關(guān)注容器在Kubernetes環(huán)境中運行時的安全狀況,這將在下面進行探討。

在開始保護Kubernetes部署之前,首先將Docker容器推送到hub.docker.com,在Kubernetes集群上運行的應(yīng)用程序??梢允褂眠@一指南開始相同的操作。

  1. Shell  
  2. docker build . -f Dockerfile.lpr -t springbootmaven 
  3. docker tag springbootmaven salecharohit/springbootmaven 
  4. docker push salecharohit/springbootmaven 
  5. docker run -d -p 8080:8080 --name springboot salecharohit/springbootmaven 
  6. curl http://localhost:8080 

現(xiàn)在Docker鏡像已經(jīng)準備好了,應(yīng)用kubernetes-basic.yaml文件來部署這個應(yīng)用程序以及一個可以幫助連接到它的服務(wù)。

  1. YAML  
  2. Create Namespace 
  3. apiVersion: v1 
  4. kind: Namespace 
  5. metadata: 
  6.  name: boot 
  7.  
  8. --- 
  9. Create SpringBoot Deployment 
  10. apiVersion: apps/v1 
  11. kind: Deployment 
  12. metadata: 
  13. labels: 
  14. app: springbootmaven 
  15. name: springbootmaven 
  16. namespace: boot 
  17. spec: 
  18. replicas: 1 
  19. selector: 
  20. matchLabels: 
  21. app: springbootmaven 
  22. template: 
  23. metadata: 
  24. labels: 
  25.  app: springbootmaven 
  26. spec: 
  27. containers: 
  28. - image: salecharohit/springbootmaven 
  29. name: springbootmaven 
  30.  ports: 
  31. - containerPort: 8080 
  32.  
  33. --- 
  34. Create Service for SpringBoot Deployment 
  35. apiVersion: v1 
  36. kind: Service 
  37. metadata: 
  38.  labels: 
  39.  app: springbootmaven 
  40. name: springbootmaven 
  41. namespace: boot 
  42. spec: 
  43. ports: 
  44. name"http" 
  45. port: 8080 
  46. targetPort: 8080 
  47. selector: 
  48. app: springbootmaven 

如果Pod需要與Kubernetes API-Server通信,則需要服務(wù)帳戶令牌進行身份驗證。

  1. Shell  
  2. kubectl apply -f kubernetes-basic.yaml  
  3. kubectl get deploy -n boot 
  4. # Run a temporary container that will only curl our bootservice 
  5. kubectl run -it testpod --image=radial/busyboxplus:curl --restart=Never --rm -- curl http://springbootmaven.boot.svc.cluster.local:8080  
  6.  
  7. ​Expected Output:  
  8. Hello World From Spring Boot Build Using Maven on Alpine OS!pod "testpod" deleted  

(1)服務(wù)帳戶令牌

如果Pod需要與Kubernetes API服務(wù)器通信,則需要服務(wù)帳戶令牌進行身份驗證。

在默認情況下,每個Pod都會分配一個服務(wù)帳戶令牌,該令牌安裝在/var/run/secrets/kubernetes.io/serviceaccount/token上??梢酝ㄟ^部署SpringBoot應(yīng)用程序在實踐中查看這一點。

  1. Shell  
  2. kubectl get pods -n boot 
  3. kubectl exec -it springbootmaven-7d7c5c8597-mndv9 -n boot -- /bin/sh 
  4. TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) 
  5. curl -k -H "Authorization:Bearer $TOKEN" https://kubernetes.docker.internal:6443/version 

應(yīng)用程序上的RCE漏洞可以將此訪問令牌泄露給網(wǎng)絡(luò)攻擊者,他們可以濫用該令牌來讀寫同一命名空間中的資源,甚至具有全局讀取權(quán)限。

解決這一問題有兩個解決方案,具體取決于具體情況:一是Pod不需要訪問API-Server。 二是Pod需要訪問API-Server。

  • 不需要訪問API-Server的Pod

這種情況很容易解決,只需在Kubernetes清單文件中添加兩行,如下所示:

  1. YAML  
  2. 1 serviceAccountName: "" 
  3. 2 automountServiceAccountToken: false 

完整的部署文件kubernetes-nosa.yaml如下:

  1. YAML  
  2. apiVersion: apps/v1 
  3. kind: Deployment 
  4. metadata: 
  5. labels: 
  6. app: springbootmaven 
  7.  name: springbootmaven 
  8. namespace: boot 
  9. spec: 
  10. eplicas: 1 
  11. selector: 
  12. matchLabels: 
  13. app: springbootmaven 
  14. template: 
  15. metadata: 
  16. labels: 
  17. app: springbootmaven 
  18. spec: 
  19. containers: 
  20. image: salecharohit/springbootmaven 
  21. name: springbootmaven 
  22. ports: 
  23. - containerPort: 8080 
  24. serviceAccountName: "" 
  25. automountServiceAccountToken: false   

然后檢查服務(wù)帳戶令牌現(xiàn)在是否已安裝。

  1. Shell  
  2. # Ensure our previous deploy is deleted.  
  3. kubectl delete ns boot 
  4.  
  5. # Apply with no service account token 
  6. kubectl apply -f kubernetes-nosa.yaml 
  7. kubectl get pods -n boot 
  8. kubectl exec -it springbootmaven-5568b9874f-8nml8 -n boot -- /bin/sh 
  9. cat /var/run/secrets/kubernetes.io/serviceaccount/token 

如上所示,不再掛載默認服務(wù)帳戶令牌。

  • 需要訪問API-Server的Pod

在這種情況下,需要創(chuàng)建將ServiceAccount映射到角色的ServiceAccount、Role和RoleBinding。以下是Kubernetes清單:

  • 為特定命名空間(即boot)創(chuàng)建一個名為bootserviceaccount的ServiceAccount。
  • 創(chuàng)建一個名為bootservicerole的角色,該角色只有查看正在運行的Pod的權(quán)限。
  • 創(chuàng)建一個名為bootservicerolebinding的RoleBinding。
  • 掛載ServiceAccount,從而在部署中使用以下幾行進行創(chuàng)建。
  1. YAML  
  2. --- 
  3. spec: 
  4. containers: 
  5. - image: salecharohit/springbootmaven 
  6. name: springbootmaven 
  7. ports: 
  8. - containerPort: 8080 
  9.  serviceAccountName: bootserviceaccount 
  10. --- 

這將允許僅讀取“boot”命名空間中的Pod。

完整的部署文件kubernetes-withsa.yaml如下:

  1. YAML  
  2. Create Namespace 
  3. apiVersion: v1 
  4. kind: Namespace 
  5. metadata: 
  6. name: boot 
  7.  
  8. --- 
  9. apiVersion: v1 
  10. kind: ServiceAccount 
  11. metadata: 
  12. name: bootserviceaccount 
  13. namespace: boot 
  14.  
  15. --- 
  16. kind: Role 
  17. apiVersion: rbac.authorization.k8s.io/v1 
  18. metadata: 
  19. name: bootservicerole 
  20. namespace: boot 
  21. rules: 
  22. - apiGroups: [""
  23. resources: ["pods"
  24. verbs: ["get""list""watch"
  25.  
  26. --- 
  27. kind: RoleBinding 
  28. apiVersion: rbac.authorization.k8s.io/v1 
  29. metadata: 
  30. name: bootservicerolebinding 
  31. namespace: boot 
  32. subjects: 
  33. - kind: ServiceAccount 
  34. name: bootserviceaccount 
  35. namespace: boot 
  36. roleRef: 
  37. kind: Role 
  38. name: bootservicerole 
  39. apiGroup: rbac.authorization.k8s.io 
  40.  
  41. --- 
  42. Create SpringBoot Deployment 
  43. apiVersion: apps/v1 
  44. kind: Deployment 
  45. metadata: 
  46. labels: 
  47. app: springbootmaven 
  48. name: springbootmaven 
  49. namespace: boot 
  50. spec: 
  51. replicas: 1 
  52. selector: 
  53. matchLabels: 
  54. app: springbootmaven 
  55. template: 
  56. metadata: 
  57. labels: 
  58. app: springbootmaven 
  59. spec: 
  60. containers: 
  61. - image: salecharohit/springbootmaven 
  62. name: springbootmaven 
  63. ports: 
  64.  - containerPort: 8080 
  65. serviceAccountName: bootserviceaccount 
  66.  
  67. --- 
  68. Create Service for SpringBoot Deployment 
  69. apiVersion: v1 
  70. kind: Service 
  71. metadata: 
  72. labels: 
  73. app: springbootmaven 
  74. name: springbootmaven 
  75. namespace: boot 
  76. spec: 
  77. ports: 
  78.  - name"http" 
  79. port: 8080 
  80. targetPort: 8080 
  81. selector: 
  82. app: springbootmaven 

現(xiàn)在運行并檢查的應(yīng)用程序是否運行良好。

  1. # Ensure our previous deploy is deleted.  
  2. kubectl delete ns boot  
  3. kubectl apply -f kubernetes-withsa.yaml  
  4. kubectl run -it testpod --image=radial/busyboxplus:curl --restart=Never --rm -- curl http://springbootmaven.boot.svc.cluster.local:8080 

#確保刪除以前的部署。

(2)Pod的安全場景

盡管已將基本Docker映像配置為以非root權(quán)限運行,但仍需要添加少量配置作為安全優(yōu)秀實踐。因此需要:

①限制容器和Pod的能力。

②禁用權(quán)限提升。

③將容器配置為使用先前在Dockerfile.lpr中創(chuàng)建的特定uid/gid運行。

在Kubernetes清單文件中,定義了兩種類型的“安全場景(SecurityContexts)”。

  • 在 Pod 級別運行,這將應(yīng)用到在這個Pod中運行的所有容器
  1. YAML  
  2.  --- 
  3. securityContext: 
  4. fsGroup: 1337 
  5. runAsNonRoot: true 
  6. runAsUser: 1337 
  7. containers: 
  8. --- 
  • 在容器級別運行
  1. YAML  
  2. --- 
  3. securityContext: 
  4. allowPrivilegeEscalation: false 
  5. privileged: false 
  6. runAsUser: 1337 
  7. capabilities: 
  8. drop: ["SETUID""SETGID"
  9. serviceAccountName: "" 
  10. automountServiceAccountToken: false 
  11. --- 

嵌入PodSecurity場景的完整部署文件kubernetes-ps.yaml如下:

  1. YAML  
  2. Create Namespace 
  3. apiVersion: v1 
  4. kind: Namespace 
  5. metadata: 
  6. name: boot 
  7. --- 
  8. Create SpringBoot Deployment 
  9. apiVersion: apps/v1 
  10. kind: Deployment 
  11. metadata: 
  12. labels: 
  13. app: springbootmaven 
  14. name: springbootmaven 
  15. namespace: boot 
  16. spec: 
  17. replicas: 1 
  18. selector: 
  19. matchLabels: 
  20. app: springbootmaven 
  21. template: 
  22. metadata: 
  23. labels: 
  24. app: springbootmaven 
  25. spec: 
  26. securityContext: 
  27. fsGroup: 1337 
  28. runAsNonRoot: true 
  29. runAsUser: 1337 
  30.  containers: 
  31. - image: salecharohit/springbootmaven 
  32. name: springbootmaven 
  33. ports: 
  34. - containerPort: 8080 
  35. securityContext: 
  36. allowPrivilegeEscalation: false 
  37. privileged: false 
  38. runAsUser: 1337 
  39. capabilities: 
  40. drop: ["SETUID""SETGID"
  41. erviceAccountName: "" 
  42. automountServiceAccountToken: false 
  43. --- 
  44. Create Service for SpringBoot Deployment 
  45. apiVersion: v1 
  46. kind: Service 
  47. metadata: 
  48. labels: 
  49.  app: springbootmaven 
  50. name: springbootmaven 
  51. namespace: boot 
  52. spec: 
  53. ports: 
  54. name"http" 
  55. port: 8080 
  56. targetPort: 8080 
  57. selector: 
  58. app: springbootmaven 

運行并測試應(yīng)用程序是否正在運行。

  1. Shell  
  2. # Ensure our previous apply is deleted 
  3. kubectl delete ns boot  
  4. kubectl apply -f kubernetes-ps.yaml  
  5. kubectl run -it testpod --image=radial/busyboxplus:curl --restart=Never --rm -- curl http://springbootmaven.boot.svc.cluster.local:8080  
  6. kubectl get pods -n boot  
  7. kubectl exec -it springbootmaven-56c64ff85-mqz2z -n boot -- /bin/sh  
  8. whoami  
  9. id  
  10. ping google.com 

開發(fā)人員可以根據(jù)自己的需求刪除更多功能。

AppArmor或SecComp等功能需要控制平面組件的附加配置。因此,我的討論僅限于開箱即用的功能,這些功能可以輕松激活并確保良好的安全保證水平。

(3)不可變文件系統(tǒng)

在容器化環(huán)境中運行的應(yīng)用程序很少寫入數(shù)據(jù),因為這實際上違背了擁有不可變系統(tǒng)的邏輯。但是,有時可能需要它來緩存或臨時交換/處理文件。因此,為了向開發(fā)人員提供此功能,可以將emptyDir裝載為臨時卷,一旦容器被終止,該臨時卷就會丟失。

有了它,還可以添加另一個名為“readOnlyRootFilesystem”的安全場景屬性,并將其設(shè)置為true,因為在容器中運行的應(yīng)用程序不再需要在文件系統(tǒng)上除“tmp”目錄以外的任何位置寫入。

可以按如下所示配置上述要求。

  1. YAML  
  2. --- 
  3. containers: 
  4. - image: salecharohit/springbootmaven 
  5. name: springbootmaven 
  6. ports: 
  7. - containerPort: 8080 
  8. securityContext: 
  9. readOnlyRootFilesystem: true 
  10. volumeMounts: 
  11. - mountPath: /tmp 
  12. name: tmp 
  13. volumes: 
  14. - emptyDir: {} 
  15. name: tmp 
  16.  --- 

完整的部署文件kubernetes-rofs.yaml如下面的代碼所示:

  1. YAML  
  2. Create Namespace 
  3. apiVersion: v1 
  4. kind: Namespace 
  5. metadata: 
  6. name: boot 
  7. --- 
  8. Create SpringBoot Deployment 
  9. apiVersion: apps/v1 
  10. kind: Deployment 
  11.  metadata: 
  12. labels: 
  13. app: springbootmaven 
  14. name: springbootmaven 
  15. namespace: boot 
  16. spec: 
  17. replicas: 1 
  18. selector: 
  19. matchLabels: 
  20. app: springbootmaven 
  21. template: 
  22. metadata: 
  23. labels: 
  24. app: springbootmaven 
  25. spec: 
  26. securityContext: 
  27. fsGroup: 1337 
  28. runAsNonRoot: true 
  29. runAsUser: 1337 
  30. containers: 
  31. - image: salecharohit/springbootmaven 
  32. name: springbootmaven 
  33. ports: 
  34. - containerPort: 8080 
  35. securityContext: 
  36. allowPrivilegeEscalation: false 
  37. readOnlyRootFilesystem: true 
  38. privileged: false 
  39. runAsUser: 1337 
  40. capabilities: 
  41. drop: ["SETUID""SETGID"
  42. volumeMounts: 
  43. - mountPath: /tmp 
  44. name: tmp 
  45. serviceAccountName: "" 
  46. automountServiceAccountToken: false 
  47.  volumes: 
  48. - emptyDir: {} 
  49. name: tmp 
  50.  
  51. --- 
  52. Create Service for SpringBoot Deployment 
  53. apiVersion: v1 
  54. kind: Service 
  55. metadata: 
  56. labels: 
  57. app: springbootmaven 
  58. name: springbootmaven 
  59. namespace: boot 
  60. spec: 
  61. ports: 
  62. name"http" 
  63. port: 8080 
  64. targetPort: 8080 
  65. selector: 
  66. app: springbootmaven 

開始應(yīng)用并測試應(yīng)用程序是否正在運行。

  1. Shell  
  2. # Ensure our previous apply is deleted 
  3. kubectl delete ns boot  
  4. kubectl apply -f kubernetes-rofs.yaml  
  5. kubectl run -it testpod --image=radial/busyboxplus:curl --restart=Never --rm -- curl http://springbootmaven.boot.svc.cluster.local:8080  
  6. kubectl get pods -n boot  
  7. kubectl exec -it springbootmaven-56c64ff85-mqz2z -n boot -- /bin/sh 
  8. pwd 
  9. touch test.txt 

結(jié)論

如今已經(jīng)了解了可以在容器化應(yīng)用程序中嵌入哪些不同的控件,還了解了如何啟用運行時保護機制,這些機制可以使網(wǎng)絡(luò)攻擊者難以在容器化系統(tǒng)中站穩(wěn)腳跟。

kubernetes-rofs.yaml可以作為一個很好的模板,供開發(fā)人員在kubernetes環(huán)境中部署時使用默認的安全功能對其應(yīng)用程序進行容器化。

當然,企業(yè)需要為特定的應(yīng)用程序創(chuàng)建Dockerfile。

原文標題:Bootstrap Security in Kubernetes Deployments,作者:Rohit Salecha

【51CTO譯稿,合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】

責任編輯:華軒 來源: 51CTO
相關(guān)推薦

2017-06-12 08:47:14

ESXi安全vSphere

2022-07-04 09:30:59

Kubernetes云安全

2020-08-16 09:01:14

削減預(yù)算CEO首席信息安全官

2016-09-04 16:20:09

2016-03-14 12:36:29

2009-11-30 09:41:38

2022-10-10 13:22:38

物聯(lián)網(wǎng)安全隱私

2021-10-19 06:05:20

網(wǎng)站安全網(wǎng)絡(luò)威脅網(wǎng)絡(luò)攻擊

2020-09-06 22:33:04

WPA身份驗證網(wǎng)絡(luò)安全

2013-12-23 09:36:31

IaaS虛擬機

2011-10-11 09:13:15

2012-08-22 10:27:16

2012-05-14 11:39:58

2019-12-04 07:12:41

前端后端web安全

2012-05-10 09:50:53

云計算安全

2024-04-11 09:45:31

2023-11-17 12:29:57

API安全性零信任

2021-03-15 14:59:28

物聯(lián)網(wǎng)互聯(lián)網(wǎng)IoT

2022-03-10 14:17:11

區(qū)塊鏈數(shù)據(jù)安全技術(shù)

2010-09-06 10:47:56

點贊
收藏

51CTO技術(shù)棧公眾號