Desde que Kubernetes elimin\u00f3 las PodSecurityPolicies en la versi\u00f3n 1.25, el control nativo de qu\u00e9 puede hacer un pod se llama Pod Security Admission. Funciona con tres niveles (Pod Security Standards) que se aplican por namespace con una simple etiqueta. Es de lo m\u00e1s rentable que se puede activar en un cluster. Aun as\u00ed, en muchos clusters que reviso sigue sin configurar o est\u00e1 en modo \u201csolo avisar\u201d desde hace a\u00f1os.<\/p>\n
Los tres niveles, en una frase cada uno:<\/strong><\/p>\n Y tres modos para aplicarlos:<\/strong><\/p>\n El truco est\u00e1 en combinarlos. As\u00ed es como lo activo en un namespace existente sin romper nada:<\/p>\n Con esto, hoy ya no entra nada peligroso (baseline en enforce), y cada despliegue te avisa de lo que le falta para llegar a restricted. Cuando dejan de salir avisos, subes el enforce a restricted.<\/p>\n La checklist que reviso en cada manifiesto antes de aprobarlo:<\/strong><\/p>\n Si el equipo responde \u201cs\u00ed\u201d a todo, el pod pasa restricted sin problemas. Si alguna respuesta es \u201cno, porque\u2026\u201d, ese \u201cporque\u201d tiene que quedar documentado.<\/p>\n Si usas OpenShift<\/strong>, hay un matiz. OpenShift tiene sus propias Security Context Constraints (SCC), que son anteriores y m\u00e1s granulares, y conviven con Pod Security Admission. OpenShift sincroniza autom\u00e1ticamente las etiquetas de PSA seg\u00fan las SCC que tienen disponibles las service accounts del namespace. Por eso los avisos que ves no siempre coinciden con lo que esperar\u00edas de Kubernetes \u201cpuro\u201d. Antes de concluir que algo est\u00e1 mal, revisa qu\u00e9 SCC se le est\u00e1 asignando al pod (la anotaci\u00f3n Activar Pod Security Admission cuesta tres etiquetas por namespace. No tenerlo activado significa que cualquiera con permiso para crear pods puede montar el sistema de ficheros del nodo.<\/p>\n \u00bfEn qu\u00e9 nivel ten\u00e9is vuestros namespaces de aplicaci\u00f3n: baseline, restricted, o todav\u00eda ninguno?<\/p>\n\n
\n
apiVersion: v1\r\nkind: Namespace\r\nmetadata:\r\n name: mi-app\r\n labels:\r\n pod-security.kubernetes.io\/enforce: baseline\r\n pod-security.kubernetes.io\/warn: restricted\r\n pod-security.kubernetes.io\/audit: restricted<\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n\n
runAsNonRoot: true<\/code> y un runAsUser<\/code> distinto de 0?<\/li>\nallowPrivilegeEscalation: false<\/code>?<\/li>\ncapabilities.drop: [\"ALL\"]<\/code>, a\u00f1adiendo solo las que haga falta y justific\u00e1ndolas?<\/li>\nseccompProfile.type: RuntimeDefault<\/code>?<\/li>\nprivileged<\/code>, hostNetwork<\/code>, hostPID<\/code>, hostIPC<\/code> ni vol\u00famenes hostPath<\/code>?<\/li>\nreadOnlyRootFilesystem: true<\/code>) cuando la aplicaci\u00f3n lo permite?<\/li>\n<\/ul>\nopenshift.io\/scc<\/code>).<\/p>\n
\n