{"id":32641,"date":"2019-10-31T21:48:11","date_gmt":"2019-10-31T18:48:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\/"},"modified":"2019-10-31T21:48:11","modified_gmt":"2019-10-31T18:48:11","slug":"vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","title":{"rendered":"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/6972a1e1385463b1fcc723c09036a565.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Nota de traducci\u00f3n.<\/b>: El autor del art\u00edculo, Reuven Harrison, tiene m\u00e1s de 20 a\u00f1os de experiencia en desarrollo de software y actualmente es director t\u00e9cnico y cofundador de Tufin, que crea soluciones para la gesti\u00f3n de pol\u00edticas de seguridad. Al considerar las pol\u00edticas de red de Kubernetes como una herramienta poderosa para la segmentaci\u00f3n de red en un cl\u00faster, tambi\u00e9n opina que no son tan f\u00e1ciles de aplicar en la pr\u00e1ctica. Este material (bastante extenso) tiene como objetivo aumentar la concienciaci\u00f3n de los especialistas en el tema y ayudarlos a crear las configuraciones necesarias.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Hoy en d\u00eda, muchas empresas eligen cada vez m\u00e1s Kubernetes para ejecutar sus aplicaciones. El inter\u00e9s en este software es tan alto que algunos lo llaman \"el nuevo sistema operativo para los centros de datos\". Poco a poco, Kubernetes (o k8s) comienza a ser visto como una parte cr\u00edtica del negocio que requiere la organizaci\u00f3n de procesos de negocio maduros, incluida la garant\u00eda de seguridad de la red.<\/p>\n<p>Para los especialistas en seguridad que se han visto sorprendidos por el trabajo con Kubernetes, su pol\u00edtica predeterminada puede ser una revelaci\u00f3n: permitir todo.<\/p>\n<p>Esta gu\u00eda ayudar\u00e1 a comprender la estructura interna de las pol\u00edticas de red; entender en qu\u00e9 se diferencian de las reglas de los cortafuegos comunes. Tambi\u00e9n se discutir\u00e1n algunas trampas ocultas y se ofrecer\u00e1n recomendaciones que ayudar\u00e1n a proteger las aplicaciones en Kubernetes.<\/p>\n<h2>Pol\u00edticas de red de Kubernetes<\/h2>\n<p>\nEl mecanismo de pol\u00edticas de red de Kubernetes permite gestionar la interacci\u00f3n entre las aplicaciones desplegadas en la plataforma a nivel de red (capa tres en el modelo OSI). Las pol\u00edticas de red carecen de algunas caracter\u00edsticas avanzadas de los cortafuegos modernos, como el control a nivel 7 del OSI y la detecci\u00f3n de amenazas, sin embargo, proporcionan un nivel b\u00e1sico de seguridad de la red que es un buen punto de partida.<\/p>\n<h2>Las pol\u00edticas de red controlan las comunicaciones entre pods.<\/h2>\n<p>\nLas cargas de trabajo en Kubernetes se distribuyen entre pods, que consisten en uno o varios contenedores desplegados juntos. Kubernetes asigna a cada pod una direcci\u00f3n IP accesible desde otros pods. Las pol\u00edticas de red de Kubernetes establecen permisos de acceso para grupos de pods de manera similar a como se utilizan los grupos de seguridad en la nube para gestionar el acceso a las instancias de m\u00e1quinas virtuales.<\/p>\n<h2>Definici\u00f3n de pol\u00edticas de red<\/h2>\n<p>\nAl igual que otros recursos de Kubernetes, las pol\u00edticas de red se definen en YAML. En el siguiente ejemplo, la aplicaci\u00f3n <code>balance<\/code> obtiene acceso a <code>postgres<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: balance\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/ff5857af2641e62558b035bab9c413dc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>(<b>Nota de traducci\u00f3n.<\/b>: esta captura de pantalla, al igual que todas las siguientes similares, fue creada no con las herramientas nativas de Kubernetes, sino con la herramienta Tufin Orca, desarrollada por la compa\u00f1\u00eda detr\u00e1s del art\u00edculo original y que se menciona al final del material.)<\/i><\/p>\n<p>Para definir una pol\u00edtica de red propia, se requieren conocimientos b\u00e1sicos de YAML. Este lenguaje se basa en indentaciones (establecidas por espacios, no por tabulaciones). Un elemento con indentaci\u00f3n pertenece al elemento m\u00e1s cercano con indentaci\u00f3n encima de \u00e9l. Un nuevo elemento de lista comienza con un guion, y todos los dem\u00e1s elementos tienen el formato <i>clave-valor<\/i>.<\/p>\n<p>Una vez que haya descrito la pol\u00edtica en YAML, utilice <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/kubectl\/kubectl\/\">kubectl<\/a><\/noindex>, para crearla en el cl\u00faster:<\/p>\n<pre><code class=\"bash\">kubectl create -f policy.yaml<\/code><\/pre>\n<p><\/p>\n<h2>Especificaci\u00f3n de la pol\u00edtica de red<\/h2>\n<p>\nLa especificaci\u00f3n de la pol\u00edtica de red de Kubernetes incluye cuatro elementos:<\/p>\n<ol>\n<li> <code>podSelector<\/code>: define los pods afectados por esta pol\u00edtica (objetivos) \u2014 obligatorio;<\/li>\n<li> <code>policyTypes<\/code>: indica qu\u00e9 tipos de pol\u00edticas est\u00e1n incluidas en esta: ingress y\/o egress \u2014 opcional, sin embargo, recomiendo describirlo expl\u00edcitamente en todos los casos;<\/li>\n<li> <code>ingress<\/code>: define el tr\u00e1fico permitido <b>entrante<\/b> el tr\u00e1fico hacia los pods objetivo \u2014 opcional;<\/li>\n<li> <code>egress<\/code>: define el tr\u00e1fico permitido <b>tr\u00e1fico saliente<\/b> el tr\u00e1fico desde los pods objetivo \u2014 opcional.<\/li>\n<\/ol>\n<p>\nEl siguiente ejemplo, tomado del sitio de Kubernetes (he reemplazado <code>role<\/code> en <code>app<\/code>), muestra c\u00f3mo se utilizan los cuatro elementos:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default\nspec:\n  podSelector:    # &lt;&lt;&lt;\n    matchLabels:\n      app: db\n  policyTypes:    # &lt;&lt;&lt;\n  - Ingress\n  - Egress\n  ingress:        # &lt;&lt;&lt;\n  - from:\n    - ipBlock:\n        cidr: 172.17.0.0\/16\n        except:\n        - 172.17.1.0\/24\n    - namespaceSelector:\n        matchLabels:\n          project: myproject\n    - podSelector:\n        matchLabels:\n          role: frontend\n    ports:\n    - protocol: TCP\n      port: 6379\n  egress:         # &lt;&lt;&lt;\n  - to:\n    - ipBlock:\n        cidr: 10.0.0.0\/24\n    ports:\n    - protocol: TCP\n      port: 5978<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/f01e748410564756d6272095093e52e2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/997282073ee6b5c4d6b7af45cdc11295.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTenga en cuenta que no es obligatorio incluir los cuatro elementos. Solo es obligatorio <code>podSelector<\/code>, los dem\u00e1s par\u00e1metros se pueden utilizar opcionalmente.<\/p>\n<p>Si se omite <code>policyTypes<\/code>, la pol\u00edtica se interpretar\u00e1 de la siguiente manera:<\/p>\n<ul>\n<li> Por defecto, se asume que define el lado de ingress. Si la pol\u00edtica no contiene indicaciones expl\u00edcitas al respecto, el sistema asumir\u00e1 que todo el tr\u00e1fico est\u00e1 prohibido.<\/li>\n<li> El comportamiento en el lado de egress se determinar\u00e1 por la presencia o ausencia del par\u00e1metro egress correspondiente.<\/li>\n<\/ul>\n<p>\nPara evitar errores, recomiendo <b>siempre especificar expl\u00edcitamente <code>policyTypes<\/code><\/b>.<\/p>\n<p>De acuerdo con la l\u00f3gica anterior, en caso de que los par\u00e1metros <code>ingress<\/code> y\/o <code>egress<\/code> se omitan, la pol\u00edtica prohibir\u00e1 todo el tr\u00e1fico (ver \"Regla de limpieza\" a continuaci\u00f3n).<\/p>\n<h2>La pol\u00edtica por defecto es permitir<\/h2>\n<p>\nSi no se definen pol\u00edticas, Kubernetes permite de manera predeterminada todo el tr\u00e1fico. Todos los pods pueden intercambiar informaci\u00f3n libremente entre s\u00ed. Desde el punto de vista de la seguridad, esto puede parecer il\u00f3gico, pero recuerde que Kubernetes fue creado originalmente por desarrolladores para facilitar la interacci\u00f3n de aplicaciones. Las pol\u00edticas de red se a\u00f1adieron m\u00e1s tarde.<\/p>\n<h2>Los espacios de nombres<\/h2>\n<p>\nLos espacios de nombres (Namespaces) son un mecanismo de trabajo colaborativo de Kubernetes. Est\u00e1n destinados a aislar entornos l\u00f3gicos entre s\u00ed, permitiendo el intercambio de datos entre espacios de nombres de forma predeterminada.<\/p>\n<p>Como la mayor\u00eda de los componentes de Kubernetes, las pol\u00edticas de red habitan en un espacio de nombres espec\u00edfico. En el bloque <code>metadata<\/code> se puede especificar a qu\u00e9 espacio pertenece la pol\u00edtica:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: my-namespace  # &lt;&lt;&lt;\nspec:\n...<\/code><\/pre>\n<p>\nSi el espacio de nombres en los metadatos no se especifica expl\u00edcitamente, el sistema utilizar\u00e1 el namespace indicado en kubectl (por defecto, <code>namespace=default<\/code>):<\/p>\n<pre><code class=\"bash\">kubectl apply -n my-namespace -f namespace.yaml<\/code><\/pre>\n<p>\nRecomiendo <b>especificar expl\u00edcitamente el namespace<\/b>, a menos que est\u00e9 escribiendo una pol\u00edtica destinada a varios espacios de nombres.<\/p>\n<p><b>Principal<\/b> elemento <code>podSelector<\/code> la pol\u00edtica seleccionar\u00e1 pods del espacio de nombres al que pertenece la pol\u00edtica (est\u00e1 restringida a pods de otros espacios de nombres).<\/p>\n<p>De manera similar a podSelectors <b>en bloques ingress y egress<\/b> solo pueden seleccionar pod\u2019s de su propio espacio de nombres, a menos que los combine mediante <code>namespaceSelector<\/code> (esto se tratar\u00e1 en la secci\u00f3n 'Filtrar por espacios de nombres y pods').<\/p>\n<h2>Reglas de nomenclatura de pol\u00edticas<\/h2>\n<p>\nLos nombres de las pol\u00edticas son \u00fanicos dentro de un espacio de nombres. No puede haber dos pol\u00edticas con el mismo nombre en un mismo espacio, pero puede haber pol\u00edticas con nombres id\u00e9nticos en diferentes espacios. Esto es conveniente cuando desea aplicar la misma pol\u00edtica en m\u00faltiples espacios.<\/p>\n<p>Me gusta especialmente una de las formas de nombrar. Consiste en combinar el nombre del espacio de nombres con los pod\u2019s objetivo. Por ejemplo:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres  # &lt;&lt;&lt;&lt;\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/18318c320d6e37eeb01c51f251550639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Etiquetas<\/h2>\n<p>\nA objetos de Kubernetes, como pod\u2019s y espacios de nombres, se les pueden adjuntar etiquetas personalizadas. Las etiquetas (<i>labels<\/i> \u2014 etiquetas) son equivalentes a tags en la nube. Las pol\u00edticas de red de Kubernetes utilizan etiquetas para seleccionar <b>pods<\/b>, a los que se aplican:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db<\/code><\/pre>\n<p>\n\u2026 o <b>espacios de nombres<\/b>, a los que se aplican. En este ejemplo, se seleccionan todos los pods en espacios de nombres con las etiquetas correspondientes:<\/p>\n<pre><code class=\"plaintext\">namespaceSelector:\n  matchLabels:\n    project: myproject<\/code><\/pre>\n<p>\nUna advertencia: al usar <code>namespaceSelector<\/code> <b>aseg\u00farese de que los espacios de nombres seleccionados contengan la etiqueta necesaria<\/b>. Tenga en cuenta que los espacios de nombres incorporados, como <code>default<\/code> y <code>kube-system<\/code>, por defecto no contienen etiquetas.<\/p>\n<p>Para agregar una etiqueta a un espacio, puede hacerlo de la siguiente manera:<\/p>\n<pre><code class=\"bash\">kubectl label namespace default namespace=default<\/code><\/pre>\n<p>\nEn este caso, el namespace en la secci\u00f3n <code>metadata<\/code> debe referirse al nombre real del espacio y no a la etiqueta:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default   # &lt;&lt;&lt;&lt;\nspec:\n...<\/code><\/pre>\n<p><\/p>\n<h2>Fuente y destinatario<\/h2>\n<p>\nLas pol\u00edticas para cortafuegos consisten en reglas con or\u00edgenes y destinatarios. Las pol\u00edticas de red de Kubernetes se definen para un objetivo: un conjunto de pods a los que se aplican, y luego establecen reglas para el tr\u00e1fico entrante (ingress) y\/o saliente (egress). En nuestro ejemplo, el objetivo de la pol\u00edtica ser\u00e1n todos los pods en el espacio de nombres. <code>default<\/code> con una etiqueta con la clave <code>app<\/code> y el valor <code>db<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: db   # &lt;&lt;&lt;\n  policyTypes:\n  - Ingress\n  - Egress\n  ingress:\n  - from:\n    - ipBlock:\n        cidr: 172.17.0.0\/16\n        except:\n        - 172.17.1.0\/24\n    - namespaceSelector:\n        matchLabels:\n          project: myproject\n    - podSelector:\n        matchLabels:\n          role: frontend\n    ports:\n    - protocol: TCP\n      port: 6379\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 10.0.0.0\/24\n    ports:\n    - protocol: TCP\n      port: 5978<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/5fcb3f78e26ae1ed5635541ad69ef69f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/c753f559ecc3ba54f8b55e29851428c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSecci\u00f3n <code>ingress<\/code> en esta pol\u00edtica abre el tr\u00e1fico entrante hacia los pods objetivo. En otras palabras, el ingress act\u00faa como la fuente, y el objetivo es el destinatario correspondiente. De manera similar, el egress es el destinatario, y el objetivo es su fuente.<\/p>\n<p><img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/a0d865de57a7620849074424770832cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Esto equivale a dos reglas para el firewall: Ingress \u2192 Objetivo; Objetivo \u2192 Egress.<\/i><\/p>\n<h2>Egress y DNS (\u00a1importante!)<\/h2>\n<p>\nAl limitar el tr\u00e1fico saliente, <b>presta especial atenci\u00f3n a DNS<\/b> \u2014 Kubernetes utiliza este servicio para mapear servicios a direcciones IP. Por ejemplo, la siguiente pol\u00edtica no funcionar\u00e1, ya que no has permitido que la aplicaci\u00f3n <code>balance<\/code> acceda a DNS:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/5857a44cc5e06de708f0d3b5b0f49628.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe puede corregir permitiendo el acceso al servicio DNS:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  - to:               # &lt;&lt;&lt;\n    ports:            # &lt;&lt;&lt;\n    - protocol: UDP   # &lt;&lt;&lt;\n      port: 53        # &lt;&lt;&lt;\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/a396bb2ae94fca94c3b62aef2cb07552.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl \u00faltimo elemento <code>a<\/code> \u2014 est\u00e1 vac\u00edo, y por lo tanto elige indirectamente <b>todos los pods en todos los espacios de nombres.<\/b>, permitiendo <code>balance<\/code> enviar solicitudes DNS al servicio correspondiente de Kubernetes (que generalmente opera en el espacio <code>kube-system<\/code>).<\/p>\n<p>Este enfoque funciona, sin embargo, es <b>excesivamente permisivo e inseguro<\/b>, ya que permite dirigir consultas DNS fuera del cl\u00faster.<\/p>\n<p>Se puede mejorar en tres pasos secuenciales.<\/p>\n<p>1. Permitir consultas DNS solo <b>dentro<\/b> del cl\u00faster, agregando <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  - to:\n    - namespaceSelector: {} # &lt;&lt;&lt;\n    ports:\n    - protocol: UDP\n      port: 53\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/5920a043229676e0780d691d302c5ade.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Permitir consultas DNS solo en el espacio de nombres <code>kube-system<\/code>.<\/p>\n<p>Para ello, es necesario agregar una etiqueta en el espacio de nombres <code>kube-system<\/code>: <code>kubectl label namespace kube-system namespace=kube-system<\/code> \u2014 y definirla en la pol\u00edtica mediante <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  - to:\n    - namespaceSelector:         # &lt;&lt;&lt;\n        matchLabels:             # &lt;&lt;&lt;\n          namespace: kube-system # &lt;&lt;&lt;\n    ports:\n    - protocol: UDP\n      port: 53\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/2a1dd0975c58e6d277baffc7c3ac6e48.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Los paranoicos pueden ir a\u00fan m\u00e1s lejos y restringir las consultas DNS a un servicio DNS espec\u00edfico en <code>kube-system<\/code>. En la secci\u00f3n 'Filtrar por espacios de nombres y pods' se explicar\u00e1 c\u00f3mo lograr esto.<\/p>\n<p>Otra opci\u00f3n es permitir DNS a nivel de espacio de nombres. En este caso, no ser\u00e1 necesario abrirlo para cada servicio:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.dns\n  namespace: default\nspec:\n  podSelector: {} # &lt;&lt;&lt;\n  egress:\n  - to:\n    - namespaceSelector: {}\n    ports:\n    - protocol: UDP\n      port: 53\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\nVac\u00edo <code>podSelector<\/code> selecciona todos los pods en el espacio de nombres.<\/p>\n<p><img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/5d6b627b69da980477b3910fbf4de6c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>El primer ajuste y el orden de las reglas<\/h2>\n<p>\nEn los cortafuegos normales, la acci\u00f3n (\"Permitir\" o \"Denegar\") en relaci\u00f3n con un paquete se determina por la primera regla que cumple. <b>En Kubernetes, el orden de las pol\u00edticas no tiene relevancia.<\/b><\/p>\n<p>De manera predeterminada, cuando no se establecen pol\u00edticas, las comunicaciones entre los pods est\u00e1n permitidas y pueden intercambiar informaci\u00f3n libremente. Una vez que comienza a formular pol\u00edticas, cada pod afectado por al menos una de ellas se a\u00edsla de acuerdo con la disyunci\u00f3n (operador l\u00f3gico OR) de todas las pol\u00edticas que lo seleccionaron. Los pods no afectados por ninguna pol\u00edtica permanecen abiertos.<\/p>\n<p>Este comportamiento se puede modificar utilizando una regla de limpieza.<\/p>\n<h2>Regla de limpieza (\"Denegar\")<\/h2>\n<p>\nLas pol\u00edticas de cortafuegos generalmente proh\u00edben cualquier tr\u00e1fico no permitido expl\u00edcitamente.<\/p>\n<p><b>En Kubernetes no existe una acci\u00f3n de \"denegar\" (deny)<\/b>, sin embargo, se puede lograr un efecto similar con una pol\u00edtica regular (permitiendo), seleccionando un grupo vac\u00edo de pods fuentes (ingress):<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: deny-all\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/8b3ced50ec5a1de70940d53f467966fe.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsta pol\u00edtica selecciona todos los pods en el espacio de nombres y deja indefinido el ingress, prohibiendo todo el tr\u00e1fico entrante.<\/p>\n<p>De manera similar, se puede restringir todo el tr\u00e1fico saliente del espacio de nombres:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: deny-all-egress\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/be22e11efef0098f2665331c09d748f2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTenga en cuenta que <b>cualquier pol\u00edtica adicional que permita tr\u00e1fico a los pods en el espacio de nombres tendr\u00e1 prioridad sobre esta regla<\/b> (similar a a\u00f1adir una regla de permiso antes de una de denegaci\u00f3n en la configuraci\u00f3n del cortafuegos).<\/p>\n<h2>Permitir todo (Any-Any-Any-Allow)<\/h2>\n<p>\nPara crear una pol\u00edtica de 'Permitir todo', es necesario complementar la pol\u00edtica de denegaci\u00f3n anterior con un elemento vac\u00edo <code>ingress<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all\n  namespace: default\nspec:\n  podSelector: {}\n  ingress: # &lt;&lt;\n  - {}     # &lt;&lt;\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/7322351493211388fe772b8dc270108d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsto abre el acceso desde <b>todos los pods en todos los espacios de nombres (y todas las IP) a cualquier pod en el espacio de nombres <code>default<\/code><\/b>. Este comportamiento est\u00e1 habilitado por defecto, por lo que generalmente no es necesario definirlo adicionalmente. Sin embargo, a veces puede ser necesario deshabilitar temporalmente algunos permisos espec\u00edficos para diagnosticar un problema.<\/p>\n<p>La regla se puede restringir y permitir el acceso s\u00f3lo a <b>un conjunto espec\u00edfico de pods<\/b> (<code>app:balance<\/code>) en el espacio de nombres <code>default<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all-to-balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  ingress: \n  - {}\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/d8c9cb85003f489acec815d1c2b53497.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa siguiente pol\u00edtica permite todo el tr\u00e1fico entrante (ingress) y saliente (egress), incluido el acceso a cualquier IP fuera del cl\u00faster:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all\nspec:\n  podSelector: {}\n  ingress:\n  - {}\n  egress:\n  - {}\n  policyTypes:\n  - Ingress\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/2477f18d3d228f80bc5169d9ec3be2fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/3502b892713cdac8850e812b2eff3ea3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>La combinaci\u00f3n de m\u00faltiples pol\u00edticas<\/h2>\n<p>\nLas pol\u00edticas se combinan utilizando la l\u00f3gica OR en tres niveles; los permisos de cada pod se establecen de acuerdo con la disyunci\u00f3n de todas las pol\u00edticas que lo afectan:<\/p>\n<p>1. En los campos <code>from<\/code> y <code>a<\/code> se pueden definir tres tipos de elementos (todos se combinan utilizando O):<\/p>\n<ul>\n<li> <code>namespaceSelector<\/code> \u2014 selecciona el espacio de nombres completo;<\/li>\n<li> <code>podSelector<\/code> \u2014 selecciona pods;<\/li>\n<li> <code>ipBlock<\/code> \u2014 selecciona una subred.<\/li>\n<\/ul>\n<p>\nEn este caso, el n\u00famero de elementos (incluso id\u00e9nticos) en las secciones <code>from<\/code>\/<code>a<\/code> no est\u00e1 limitado. Todos se combinar\u00e1n l\u00f3gicamente con un O.<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n    - podSelector:\n        matchLabels:\n          app: admin\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/717e745720f39260a8508fb2b2bb6f65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Dentro de la pol\u00edtica, la secci\u00f3n <code>ingress<\/code> puede tener m\u00faltiples elementos <code>from<\/code> (se combinan con un OR l\u00f3gico). De manera similar, la secci\u00f3n <code>egress<\/code> puede incluir m\u00faltiples elementos <code>a<\/code> (tambi\u00e9n se combinan mediante disyunci\u00f3n):<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/b579e1f4b97acd92fb38cd6703aa1983.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Diferentes pol\u00edticas tambi\u00e9n se combinan con un OR l\u00f3gico<\/p>\n<p>Pero al combinarlas, hay una restricci\u00f3n que <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/sainsburys-engineering\/considerations-with-k8s-networkpolicy-cee7eacf5469\">especific\u00e9<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@chriscooney\">Chris Cooney<\/a><\/noindex>: Kubernetes puede combinar pol\u00edticas solo con diferentes <code>policyTypes<\/code> (<code>Ingress<\/code> o <code>Egress<\/code>). Las pol\u00edticas que definen ingress (o egress) sobrescribir\u00e1n las unas a las otras.<\/p>\n<h2>La relaci\u00f3n entre namespaces<\/h2>\n<p>\nPor defecto, la comunicaci\u00f3n entre namespaces est\u00e1 permitida. Esto se puede modificar mediante una pol\u00edtica restrictiva que limitar\u00e1 el tr\u00e1fico saliente y\/o entrante al namespace (ver \"Regla de limpieza\" arriba).<\/p>\n<p>Al bloquear el acceso en un namespace (ver \"Regla de limpieza\" arriba), puede hacer excepciones en la pol\u00edtica restrictiva permitiendo conexiones desde un namespace espec\u00edfico mediante <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: database.postgres\n  namespace: database\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - namespaceSelector: # &lt;&lt;&lt;\n        matchLabels:\n          namespace: default\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/5a3d2baed1ff9b813ef0651fe500ad8a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nComo resultado, todos los pods en el namespace <code>default<\/code> tendr\u00e1n acceso a los pods <code>postgres<\/code> en el namespace <code>database<\/code>. Pero, \u00bfqu\u00e9 pasa si desea abrir el acceso a <code>postgres<\/code> solo a pods espec\u00edficos en el espacio de nombres <code>default<\/code>?<\/p>\n<h2>Filtro por espacios de nombres y pods<\/h2>\n<p>\nKubernetes versi\u00f3n 1.11 y posterior permite combinar operadores <code>namespaceSelector<\/code> y <code>podSelector<\/code> usando un AND l\u00f3gico. Esto se ver\u00eda as\u00ed:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: database.postgres\n  namespace: database\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - namespaceSelector:\n        matchLabels:\n          namespace: default\n      podSelector: # &lt;&lt;&lt;\n        matchLabels:\n          app: admin\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/e933e449d9f9c10505e45930d1477b2c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00bfPor qu\u00e9 esto se interpreta como AND en lugar del com\u00fan OR?<\/p>\n<p>Tenga en cuenta que <code>podSelector<\/code> no comienza con un gui\u00f3n. En YAML, esto significa que <code>podSelector<\/code> y el que le precede <code>namespaceSelector<\/code> se refieren al mismo elemento de la lista. Por lo tanto, se combinan con un AND l\u00f3gico.<\/p>\n<p>La adici\u00f3n de un guion antes de <code>podSelector<\/code> resultar\u00e1 en la creaci\u00f3n de un nuevo elemento de la lista, que se combinar\u00e1 con el anterior <code>namespaceSelector<\/code> mediante un OR l\u00f3gico.<\/p>\n<p>Para seleccionar pods con una etiqueta espec\u00edfica <b>en todos los espacios de nombre<\/b>, escriba vac\u00edo <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: database.postgres\n  namespace: database\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - namespaceSelector: {}\n      podSelector:\n        matchLabels:\n          app: admin\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/e79e4a8067fa254f85fa8be105c3ad34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>M\u00faltiples etiquetas se combinan con AND<\/h2>\n<p>\nLas reglas de firewall con m\u00faltiples objetos (hosts, redes, grupos) se combinan utilizando un OR l\u00f3gico. La siguiente regla se activar\u00e1 si la fuente del paquete coincide con <code>Host_1<\/code> OR <code>Host_2<\/code>:<\/p>\n<pre><code class=\"plaintext\">| Fuente | Destino | Servicio | Acci\u00f3n |\n| ----------------------------------------|\n| Host_1 | Subnet_A    | HTTPS   | Permitir  |\n| Host_2 |             |         |        |\n| ----------------------------------------|<\/code><\/pre>\n<p>\nPor otro lado, en Kubernetes, varias etiquetas <code>podSelector<\/code> o <code>namespaceSelector<\/code> se combinan con un AND l\u00f3gico. Por ejemplo, la siguiente regla seleccionar\u00e1 pods que tengan ambas etiquetas, <code>role=db<\/code> Y <code>version=v2<\/code>:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db\n    version: v2<\/code><\/pre>\n<p>\nLa misma l\u00f3gica se aplica a todos los tipos de operadores: selectores de objetivos de pol\u00edticas, selectores de pods y selectores de espacios de nombres.<\/p>\n<h2>Subredes y direcciones IP (IPBlocks)<\/h2>\n<p>\nPara segmentar la red, los firewalls utilizan VLAN, direcciones IP y subredes.<\/p>\n<p>En Kubernetes, las direcciones IP se asignan autom\u00e1ticamente a los pods y pueden cambiar con frecuencia, por lo que se utilizan etiquetas para seleccionar pods y espacios de nombres en pol\u00edticas de red.<\/p>\n<p>Las subredes (<code>ipBlocks<\/code>) se utilizan al gestionar conexiones externas (North-South) de entrada (ingress) o de salida (egress). Por ejemplo, esta pol\u00edtica abre todos los pods del espacio de nombres <code>default<\/code> acceder al servicio DNS de Google:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-dns\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 8.8.8.8\/32\n    ports:\n    - protocol: UDP\n      port: 53<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/42e1194e28331e667a094f19c88e0934.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn selector de pods vac\u00edo en este ejemplo significa 'seleccionar todos los pods en el espacio de nombres'.<\/p>\n<p>Esta pol\u00edtica solo permite el acceso a 8.8.8.8; el acceso a cualquier otra IP est\u00e1 prohibido. Por lo tanto, en esencia, ha bloqueado el acceso al servicio DNS interno de Kubernetes. Si a\u00fan desea abrirlo, ind\u00edquelo expl\u00edcitamente.<\/p>\n<p>Normalmente <code>ipBlocks<\/code> y <code>podSelectors<\/code> son mutuamente excluyentes, ya que las direcciones IP internas de los pods no se utilizan en <code>ipBlocks<\/code>. Al especificar <b>direcciones IP internas de los pods<\/b>, en realidad, permitir\u00e1s conexiones desde\/hacia los pods con esas direcciones. En la pr\u00e1ctica, no sabr\u00e1s qu\u00e9 direcci\u00f3n IP usar, por lo que no se debe utilizar para seleccionar pods.<\/p>\n<p>Como contraejemplo, la siguiente pol\u00edtica incluye todas las IP y, por lo tanto, permite el acceso a todos los dem\u00e1s pods:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-any\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/d99dfdead1c96b071b1643cb5c572878.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe puede abrir el acceso solo a las IP externas, excluyendo las direcciones IP internas de los pods. Por ejemplo, si la subred de tu pod es 10.16.0.0\/14:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-any\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0\n        except:\n        - 10.16.0.0\/14<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/b157cfe0f1cd4677cf0defd9fdfa8a13.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Puertos y protocolos<\/h2>\n<p>\nPor lo general, los pods escuchan un puerto. Esto significa que puedes simplemente no especificar los n\u00fameros de puerto en las pol\u00edticas y dejar todo en su valor predeterminado. Sin embargo, se recomienda que las pol\u00edticas sean lo m\u00e1s restrictivas posible, por lo que en algunos casos a\u00fan se pueden especificar puertos:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n    - podSelector:\n        matchLabels:\n          app: admin\n    ports:             # &lt;&lt;&lt;&lt;\n      - port: 443      # &lt;&lt;&lt;&lt;\n        protocol: TCP  # &lt;&lt;&lt;&lt;\n      - port: 80       # &lt;&lt;&lt;&lt;\n        protocol: TCP  # &lt;&lt;&lt;&lt;\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/4c778cd46c54e2ae0f4527ffa9e1e740.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTenga en cuenta que el selector <code>ports<\/code> se aplica a todos los elementos en el bloque <code>a<\/code> o <code>from<\/code>, en el que se encuentra. Para especificar diferentes puertos para diferentes conjuntos de elementos, div\u00eddalo <code>ingress<\/code> o <code>egress<\/code> en varios subsecciones con <code>a<\/code> o <code>from<\/code> y en cada uno especifique sus puertos:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n    ports:             # &lt;&lt;&lt;&lt;\n     - port: 443       # &lt;&lt;&lt;&lt;\n       protocol: TCP   # &lt;&lt;&lt;&lt;\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n    ports:             # &lt;&lt;&lt;&lt;\n     - port: 80        # &lt;&lt;&lt;&lt;\n       protocol: TCP   # &lt;&lt;&lt;&lt;\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad\" src=\"\/wp-content\/uploads\/2019\/04\/b9ac1d8af491e992cac0be184005a278.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFuncionamiento de los puertos por defecto:<\/p>\n<ul>\n<li> Si omite completamente la definici\u00f3n de puertos (<code>ports<\/code>), esto significa todos los protocolos y todos los puertos;<\/li>\n<li> Si omite la definici\u00f3n del protocolo (<code>protocol<\/code>), esto significa TCP;<\/li>\n<li> Si omite la definici\u00f3n del puerto (<code>port<\/code>), esto significa todos los puertos.<\/li>\n<\/ul>\n<p>\nMejor pr\u00e1ctica: no conf\u00ede en los valores predeterminados, especifique lo que necesita expl\u00edcitamente.<\/p>\n<p>Tenga en cuenta que es necesario utilizar los puertos de los pods, no los de los servicios (m\u00e1s detalles sobre esto en el siguiente p\u00e1rrafo).<\/p>\n<h2>\u00bfLas pol\u00edticas est\u00e1n definidas para pods o servicios?<\/h2>\n<p>\nNormalmente, los pods en Kubernetes se comunican entre s\u00ed a trav\u00e9s de un servicio: un equilibrador de carga virtual que redirige el tr\u00e1fico a los pods que implementan el servicio. Se podr\u00eda pensar que las pol\u00edticas de red controlan el acceso a los servicios, pero no es as\u00ed. <b>Las pol\u00edticas de red de Kubernetes trabajan con los puertos de los pods, no con los servicios.<\/b><\/p>\n<p>Por ejemplo, si un servicio escucha en el puerto 80, pero redirige el tr\u00e1fico al puerto 8080 de sus pods, es necesario especificar exactamente el 8080 en la pol\u00edtica de red.<\/p>\n<p>Un mecanismo como este debe considerarse sub\u00f3ptimo: al cambiar la configuraci\u00f3n interna del servicio (los puertos de los cuales escuchan los pods), ser\u00e1 necesario actualizar las pol\u00edticas de red.<\/p>\n<p>Un nuevo enfoque arquitect\u00f3nico utilizando Service Mesh <i>(por ejemplo, consulte Istio a continuaci\u00f3n - nota del traductor)<\/i> permite abordar este problema.<\/p>\n<h2>\u00bfEs necesario especificar tanto Ingress como Egress?<\/h2>\n<p>\nLa respuesta corta es s\u00ed; para que el pod A pueda comunicarse con el pod B, es necesario permitirle establecer una conexi\u00f3n saliente (para esto es necesario configurar una pol\u00edtica de egress), y el pod B debe poder aceptar una conexi\u00f3n entrante (para ello, por lo tanto, se necesita una pol\u00edtica de ingress).<\/p>\n<p>Sin embargo, en la pr\u00e1ctica, se puede confiar en la pol\u00edtica predeterminada que permite conexiones en una o ambas direcciones.<\/p>\n<p>Si un pod-<b>fuente<\/b> es seleccionado por una o varias <b>egress<\/b>-pol\u00edticas, las restricciones impuestas se determinar\u00e1n por su disyunci\u00f3n. En este caso, se deber\u00e1 permitir expl\u00edcitamente la conexi\u00f3n al pod-<b>destinatario<\/b>. Si el pod no es seleccionado por ninguna pol\u00edtica, su tr\u00e1fico saliente (egress) est\u00e1 permitido por defecto.<\/p>\n<p>De manera similar, el destino del pod-<b>destinatario<\/b>, seleccionado por una o varias <b>ingress<\/b>-las pol\u00edticas se definir\u00e1n por su disyunci\u00f3n. En este caso, es necesario permitir expl\u00edcitamente que reciba tr\u00e1fico del pod fuente. Si un pod no es seleccionado por ninguna pol\u00edtica, todo el tr\u00e1fico entrante (ingress) para \u00e9l est\u00e1 permitido por defecto.<\/p>\n<p>V\u00e9ase la secci\u00f3n 'Stateful o Stateless' a continuaci\u00f3n.<\/p>\n<h2>Registros<\/h2>\n<p>\nLas pol\u00edticas de red de Kubernetes no pueden registrar tr\u00e1fico. Esto dificulta determinar si la pol\u00edtica est\u00e1 funcionando correctamente y complica enormemente el an\u00e1lisis en t\u00e9rminos de seguridad.<\/p>\n<h2>Control del tr\u00e1fico hacia servicios externos<\/h2>\n<p>\nLas pol\u00edticas de red de Kubernetes no permiten especificar un nombre de dominio completo (DNS) en las secciones de egress. Este hecho causa una gran incomodidad al intentar restringir el tr\u00e1fico a destinos externos que carecen de una direcci\u00f3n IP fija (como aws.com).<\/p>\n<h2>Verificaci\u00f3n de pol\u00edticas<\/h2>\n<p>\nLos firewalls le advertir\u00e1n o incluso se negar\u00e1n a aceptar una pol\u00edtica err\u00f3nea. Kubernetes tambi\u00e9n realiza cierta verificaci\u00f3n. Al establecer una pol\u00edtica de red a trav\u00e9s de kubectl, Kubernetes puede afirmar que es incorrecta y negarse a aceptarla. En otros casos, Kubernetes aceptar\u00e1 la pol\u00edtica y la complementar\u00e1 con los detalles faltantes. Se pueden ver con el siguiente comando:<\/p>\n<pre><code class=\"plaintext\">kubernetes get networkpolicy  -o yaml<\/code><\/pre>\n<p>\nTenga en cuenta que el sistema de verificaci\u00f3n de Kubernetes no es infalible y puede pasar por alto ciertos tipos de errores.<\/p>\n<h2>Ejecuci\u00f3n<\/h2>\n<p>\nKubernetes no implementa pol\u00edticas de red por s\u00ed mismo, sino que act\u00faa como una puerta de enlace API, delegando la ardua tarea de control a un sistema subyacente llamado Container Networking Interface (CNI). Establecer pol\u00edticas en un cl\u00faster de Kubernetes sin asignar el CNI correspondiente es similar a crear pol\u00edticas en un servidor de firewall sin instalarlas posteriormente en los firewalls. Debe asegurarse de contar con un CNI adecuado o, en el caso de las plataformas de Kubernetes alojadas en la nube, <i>(puede consultar la lista de proveedores, <noindex>aqu\u00ed<\/noindex> \u2014 nota del traductor)<\/i>, implementar pol\u00edticas de red que configuren el CNI por usted.<\/p>\n<p>Tenga en cuenta que Kubernetes no le advertir\u00e1 si establece una pol\u00edtica de red sin el CNI auxiliar correspondiente.<\/p>\n<h3>\u00bfStateful o Stateless?<\/h3>\n<p>\nTodos los CNI de Kubernetes con los que he tenido experiencia son stateful (por ejemplo, Calico utiliza Linux conntrack). Esto permite que un pod reciba respuestas a una conexi\u00f3n TCP que ha iniciado sin necesidad de volver a establecerla. Sin embargo, no conozco un est\u00e1ndar de Kubernetes que garantice el almacenamiento de estado (statefulness).<\/p>\n<h2>Gesti\u00f3n avanzada de pol\u00edticas de seguridad<\/h2>\n<p>\nAqu\u00ed hay algunas formas de aumentar la eficacia de la ejecuci\u00f3n de pol\u00edticas de seguridad en Kubernetes:<\/p>\n<ol>\n<li> El patr\u00f3n arquitect\u00f3nico Service Mesh utiliza contenedores sidecar para proporcionar telemetr\u00eda detallada y control del tr\u00e1fico a nivel de servicios. Un ejemplo es <noindex><a rel=\"nofollow\" href=\"https:\/\/istio.io\/\">Istio<\/a><\/noindex>.<\/li>\n<li> Algunos proveedores de CNI han ampliado sus herramientas para que vayan m\u00e1s all\u00e1 de las pol\u00edticas de red de Kubernetes.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.tufin.com\/products\/tufin-orca\">Tufin Orca<\/a><\/noindex> ofrece transparencia y automatizaci\u00f3n de las pol\u00edticas de red de Kubernetes.<\/li>\n<\/ol>\n<p>\nEl paquete Tufin Orca gestiona las pol\u00edticas de red de Kubernetes (y sirve como fuente de las capturas de pantalla mencionadas anteriormente).<\/p>\n<h2>Informaci\u00f3n adicional<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ahmetb\/kubernetes-network-policy-recipes\">Ejemplos de pol\u00edticas de red, preparadas por Ahmet Alp Balkan de GKE.<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/network-policies\/\">Documentaci\u00f3n del sitio oficial de Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/sookocheff.com\/post\/kubernetes\/understanding-kubernetes-networking-model\/\">Gu\u00eda de la modelo de red de Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Tufin\/test-network-policies\">Script para verificar pol\u00edticas de red<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Conclusi\u00f3n<\/h2>\n<p>\nLas pol\u00edticas de red de Kubernetes ofrecen un buen conjunto de herramientas para la segmentaci\u00f3n de cl\u00fasteres, sin embargo, son poco intuitivas y tienen muchas sutilezas. Creo que debido a esta complejidad, las pol\u00edticas de muchos cl\u00fasteres existentes contienen errores. Las posibles soluciones a este problema son la automatizaci\u00f3n de definiciones de pol\u00edticas o la aplicaci\u00f3n de otros medios de segmentaci\u00f3n.<\/p>\n<p>Espero que esta gu\u00eda ayude a aclarar algunas dudas y resolver problemas que pueda enfrentar.<\/p>\n<h2>P.D. del traductor<\/h2>\n<p>\nTambi\u00e9n puedes leer en nuestro blog:<\/p>\n<ul>\n<li> \u00abRegreso a los microservicios junto con Istio\u00bb: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438426\/\">parte 1 (introducci\u00f3n a las capacidades principales)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">parte 2 (ruteo, gesti\u00f3n del tr\u00e1fico)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443668\/\">parte 3 (seguridad)<\/a><\/noindex>;<\/li>\n<li> \u00abGu\u00eda ilustrada sobre la configuraci\u00f3n de redes en Kubernetes\u00bb: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/346304\/\">partes 1 y 2 (modelo de red, redes de superposici\u00f3n)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/433382\/\">parte 3 (servicios y procesamiento del tr\u00e1fico)<\/a><\/noindex>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440504\/\">Docker y Kubernetes en entornos con altas exigencias de seguridad<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/436300\/\">9 mejores pr\u00e1cticas para asegurar Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417905\/\">11 maneras de (no) convertirse en v\u00edctima de un ataque en Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443190\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0410\u0432\u0442\u043e\u0440 \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 Reuven Harrison \u2014 \u0438\u043c\u0435\u0435\u0442 \u0431\u043e\u043b\u0435\u0435 20 \u043b\u0435\u0442 \u043e\u043f\u044b\u0442\u0430 \u0432 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f, \u0430 \u043d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u043e\u043c \u0438 \u0441\u043e\u0443\u0447\u0440\u0435\u0434\u0438\u0442\u0435\u043b\u0435\u043c \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Tufin, \u0441\u043e\u0437\u0434\u0430\u044e\u0449\u0435\u0439 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0434\u043b\u044f \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0430\u043c\u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u044f \u0441\u0435\u0442\u0435\u0432\u044b\u0435 \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 Kubernetes \u043a\u0430\u043a \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043c\u043e\u0449\u043d\u043e\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e \u0434\u043b\u044f \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0441\u0435\u0442\u0438 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435, \u043e\u043d \u0432 \u0442\u043e \u0436\u0435 \u0432\u0440\u0435\u043c\u044f \u0441\u0447\u0438\u0442\u0430\u0435\u0442, \u0447\u0442\u043e \u043e\u043d\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24432,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32641","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0441\u0435\u0442\u0435\u0432\u044b\u0435 \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 Kubernetes \u0434\u043b\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u043f\u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:48:11+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:48:11+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Introducci\u00f3n a las pol\u00edticas de red de Kubernetes para especialistas en seguridad | ProHoster","description":"Ej.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0441\u0435\u0442\u0435\u0432\u044b\u0435 \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 Kubernetes \u0434\u043b\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u043f\u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:48:11+00:00","article:modified_time":"2019-10-31T18:48:11+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32641","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 11:53:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:55:23","updated":"2026-01-21 11:53:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/32641","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=32641"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/32641\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/24432"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=32641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=32641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=32641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}