From 5c18ac1880b3beea1e379c645e8ddac302159da7 Mon Sep 17 00:00:00 2001 From: gamba47 Date: Fri, 17 Dec 2021 23:23:20 -0300 Subject: [PATCH 01/27] commit inicial con archivo base --- .../concepts/security/controlling-access.md | 184 ++++++++++++++++++ 1 file changed, 184 insertions(+) create mode 100644 content/es/docs/concepts/security/controlling-access.md diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md new file mode 100644 index 0000000000..1a0c93d8cf --- /dev/null +++ b/content/es/docs/concepts/security/controlling-access.md @@ -0,0 +1,184 @@ +--- +reviewers: +- erictune +- lavalamp +title: Controlling Access to the Kubernetes API +content_type: concept +--- + + +This page provides an overview of controlling access to the Kubernetes API. + + + +Users access the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) using `kubectl`, +client libraries, or by making REST requests. Both human users and +[Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) can be +authorized for API access. +When a request reaches the API, it goes through several stages, illustrated in the +following diagram: + +![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg) + +## Transport security + +In a typical Kubernetes cluster, the API serves on port 443, protected by TLS. +The API server presents a certificate. This certificate may be signed using +a private certificate authority (CA), or based on a public key infrastructure linked +to a generally recognized CA. + +If your cluster uses a private certificate authority, you need a copy of that CA +certificate configured into your `~/.kube/config` on the client, so that you can +trust the connection and be confident it was not intercepted. + +Your client can present a TLS client certificate at this stage. + +## Authentication + +Once TLS is established, the HTTP request moves to the Authentication step. +This is shown as step **1** in the diagram. +The cluster creation script or cluster admin configures the API server to run +one or more Authenticator modules. +Authenticators are described in more detail in +[Authentication](/docs/reference/access-authn-authz/authentication/). + +The input to the authentication step is the entire HTTP request; however, it typically +examines the headers and/or client certificate. + +Authentication modules include client certificates, password, and plain tokens, +bootstrap tokens, and JSON Web Tokens (used for service accounts). + +Multiple authentication modules can be specified, in which case each one is tried in sequence, +until one of them succeeds. + +If the request cannot be authenticated, it is rejected with HTTP status code 401. +Otherwise, the user is authenticated as a specific `username`, and the user name +is available to subsequent steps to use in their decisions. Some authenticators +also provide the group memberships of the user, while other authenticators +do not. + +While Kubernetes uses usernames for access control decisions and in request logging, +it does not have a `User` object nor does it store usernames or other information about +users in its API. + +## Authorization + +After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram. + +A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action. + +For example, if Bob has the policy below, then he can read pods only in the namespace `projectCaribou`: + +```json +{ + "apiVersion": "abac.authorization.kubernetes.io/v1beta1", + "kind": "Policy", + "spec": { + "user": "bob", + "namespace": "projectCaribou", + "resource": "pods", + "readonly": true + } +} +``` +If Bob makes the following request, the request is authorized because he is allowed to read objects in the `projectCaribou` namespace: + +```json +{ + "apiVersion": "authorization.k8s.io/v1beta1", + "kind": "SubjectAccessReview", + "spec": { + "resourceAttributes": { + "namespace": "projectCaribou", + "verb": "get", + "group": "unicorn.example.org", + "resource": "pods" + } + } +} +``` +If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied. + +Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems. It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API. + +Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode. When an administrator creates a cluster, they configure the authorization modules that should be used in the API server. If more than one authorization modules are configured, Kubernetes checks each module, and if any module authorizes the request, then the request can proceed. If all of the modules deny the request, then the request is denied (HTTP status code 403). + +To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules, see [Authorization](/docs/reference/access-authn-authz/authorization/). + + +## Admission control + +Admission Control modules are software modules that can modify or reject requests. +In addition to the attributes available to Authorization modules, Admission +Control modules can access the contents of the object that is being created or modified. + +Admission controllers act on requests that create, modify, delete, or connect to (proxy) an object. +Admission controllers do not act on requests that merely read objects. +When multiple admission controllers are configured, they are called in order. + +This is shown as step **3** in the diagram. + +Unlike Authentication and Authorization modules, if any admission controller module +rejects, then the request is immediately rejected. + +In addition to rejecting objects, admission controllers can also set complex defaults for +fields. + +The available Admission Control modules are described in [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). + +Once a request passes all admission controllers, it is validated using the validation routines +for the corresponding API object, and then written to the object store (shown as step **4**). + + +## API server ports and IPs + +The previous discussion applies to requests sent to the secure port of the API server +(the typical case). The API server can actually serve on 2 ports: + +By default, the Kubernetes API server serves HTTP on 2 ports: + + 1. `localhost` port: + + - is intended for testing and bootstrap, and for other components of the master node + (scheduler, controller-manager) to talk to the API + - no TLS + - default is port 8080 + - default IP is localhost, change with `--insecure-bind-address` flag. + - request **bypasses** authentication and authorization modules. + - request handled by admission control module(s). + - protected by need to have host access + + 2. “Secure port”: + + - use whenever possible + - uses TLS. Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag. + - default is port 6443, change with `--secure-port` flag. + - default IP is first non-localhost network interface, change with `--bind-address` flag. + - request handled by authentication and authorization modules. + - request handled by admission control module(s). + - authentication and authorization modules run. + +## {{% heading "whatsnext" %}} + +Read more documentation on authentication, authorization and API access control: + +- [Authenticating](/docs/reference/access-authn-authz/authentication/) + - [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) +- [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) + - [Dynamic Admission Control](/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [Authorization](/docs/reference/access-authn-authz/authorization/) + - [Role Based Access Control](/docs/reference/access-authn-authz/rbac/) + - [Attribute Based Access Control](/docs/reference/access-authn-authz/abac/) + - [Node Authorization](/docs/reference/access-authn-authz/node/) + - [Webhook Authorization](/docs/reference/access-authn-authz/webhook/) +- [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) + - including [CSR approval](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) + and [certificate signing](/docs/reference/access-authn-authz/certificate-signing-requests/#signing) +- Service accounts + - [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/) + - [Administration](/docs/reference/access-authn-authz/service-accounts-admin/) + +You can learn about: +- how Pods can use + [Secrets](/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials) + to obtain API credentials. From dcf7fa9bb089d3c089df2e49e0ce67d10bb649e8 Mon Sep 17 00:00:00 2001 From: gamba47 Date: Fri, 17 Dec 2021 23:23:58 -0300 Subject: [PATCH 02/27] terminando primer revision de documento --- .../concepts/security/controlling-access.md | 170 +++++++++--------- 1 file changed, 86 insertions(+), 84 deletions(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 1a0c93d8cf..01f4239eb4 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -1,73 +1,76 @@ --- reviewers: -- erictune -- lavalamp -title: Controlling Access to the Kubernetes API +- electrocucaracha +- raelga +title: Controlando el Acceso a la API de Kubernetes content_type: concept --- -This page provides an overview of controlling access to the Kubernetes API. +Esta pagina proporciona información sobre el como controlar el acceso a la API de Kubernetes. -Users access the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) using `kubectl`, -client libraries, or by making REST requests. Both human users and -[Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) can be -authorized for API access. -When a request reaches the API, it goes through several stages, illustrated in the -following diagram: +Los usuarios acceden a la [API de Kubernetes](/docs/concepts/overview/kubernetes-api/) usando `kubectl`, +client libraries, o haciendo peticiones REST. Humanos y los +[Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) pueden ser +autorizados para acceder a la API. +Cuando una peticion llega a la API, pasa por varias etapas, estan ilustradas en el +siguiente diagrama: -![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg) +![Diagrama de pasos para una petición a la API de Kubernetes](/images/docs/admin/access-control-overview.svg) ## Transport security -In a typical Kubernetes cluster, the API serves on port 443, protected by TLS. -The API server presents a certificate. This certificate may be signed using -a private certificate authority (CA), or based on a public key infrastructure linked -to a generally recognized CA. +En un cluster típico de Kubernetes, la API sirve peticiones en el puerto 443, protegida por TLS. +El server API presenta un certificado. Este certificado puede ser firmando usando +un certificado de autoridad privada (CA) o basado en una llave publica relacionada +generalmente a un CA reconocido. -If your cluster uses a private certificate authority, you need a copy of that CA -certificate configured into your `~/.kube/config` on the client, so that you can -trust the connection and be confident it was not intercepted. +Si el cluster usa un certificado de autoridad privado, se necesita copiar este certificado +CA configurado dentro de su `~/.kube/config` en el cliente, entonces usted podrá +confiar en la conección y estar seguro que no será hackeada. -Your client can present a TLS client certificate at this stage. +Su cliente puede presentar un certificado TLS de cliente en esta etapa. -## Authentication +## Autenticación -Once TLS is established, the HTTP request moves to the Authentication step. -This is shown as step **1** in the diagram. -The cluster creation script or cluster admin configures the API server to run -one or more Authenticator modules. -Authenticators are described in more detail in +Una vez que se estableció el TLS, las peticiones HTTP avanzan a la etapa de autenticación. +Esto se muestra en el paso 1 del diagrama. +El script de creación del cluster o el administrador del cluster configurada el servidor API para ejecutar +uno o mas módulos de autenticación. +Los Autenticadores estan descriptos con más detalle en [Authentication](/docs/reference/access-authn-authz/authentication/). -The input to the authentication step is the entire HTTP request; however, it typically +```The input to the authentication step is the entire HTTP request; however, it typically examines the headers and/or client certificate. +``` +El ingreso al paso de autenticación es la petición HTTP completa, aun así, esta tipicamente +examina las cabeceras y/o el certificado del cliente. -Authentication modules include client certificates, password, and plain tokens, -bootstrap tokens, and JSON Web Tokens (used for service accounts). +Los modulos de autenticación incluyen certificado de cliente, contraseña, tokens planos, +tokens de inicio y JSON Web Tokens (usados para los service accounts). -Multiple authentication modules can be specified, in which case each one is tried in sequence, -until one of them succeeds. +Multiples modulos de autenticación puede ser especificados, en este caso cada uno es probado secuencialmente, +hasta que uno de ellos tiene éxito. -If the request cannot be authenticated, it is rejected with HTTP status code 401. -Otherwise, the user is authenticated as a specific `username`, and the user name -is available to subsequent steps to use in their decisions. Some authenticators -also provide the group memberships of the user, while other authenticators -do not. +Si la petición no puede ser autenticada, la misma es rechazada con un codigo de estado HTTP 401. +En otro caso, el usuario es validado con el `username` específico, y el nombre de usuario +esta disponible para los pasos siguientes. Algunos autenticadores +tambien proporcionan membresías de grupo al usuario, mientras que otros +no lo hacen. While Kubernetes uses usernames for access control decisions and in request logging, -it does not have a `User` object nor does it store usernames or other information about -users in its API. +este n otiene un objeto `User` ni tampoco guarda nombres de usaurio o otra información acerca +de ellos en su API. -## Authorization +## Autorización -After the request is authenticated as coming from a specific user, the request must be authorized. This is shown as step **2** in the diagram. +Despues de autenticar la petición como proveniente de un usuario específico, la petición debe ser autorizada. Esto se muestra en el paso 2 del diagrama. -A request must include the username of the requester, the requested action, and the object affected by the action. The request is authorized if an existing policy declares that the user has permissions to complete the requested action. +Una petición debe incluir el nombre de usuario solicitante, la acción solicitada y el objeto afectado por la acción. La petición es autorizada si hay una politica existente que declare que el usuario tiene permisos para la realizar la acción. -For example, if Bob has the policy below, then he can read pods only in the namespace `projectCaribou`: +Por ejemplo, si Bob tiene la siguiente politica, entonces el puede leer pods solamente en el namespace `projectCaribou`: ```json { @@ -81,7 +84,7 @@ For example, if Bob has the policy below, then he can read pods only in the name } } ``` -If Bob makes the following request, the request is authorized because he is allowed to read objects in the `projectCaribou` namespace: +Si Bob hace la siguiente petición, será aturizada porque él tiene permitido leer los objetos en el namespace `projectCaribou` : ```json { @@ -97,70 +100,69 @@ If Bob makes the following request, the request is authorized because he is allo } } ``` -If Bob makes a request to write (`create` or `update`) to the objects in the `projectCaribou` namespace, his authorization is denied. If Bob makes a request to read (`get`) objects in a different namespace such as `projectFish`, then his authorization is denied. +Si Bob en su petición intenta escribir (`create` o `update`) en los objetos del namespace `projectCaribou`. Si Bob hace una petición para leer (`get`) objetocs en otro namespace como `projectFish`, entonces la autorización será denegada. -Kubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems. It is important to use REST formatting because these control systems might interact with other APIs besides the Kubernetes API. +Las autorizaciones en Kubernetes requieren que se usen atributos REST comunes para interactuar con el existente sistema de control de toda la organización o del proveedor cloud. Es importante usar formatos REST porque esos sistemas de control pueden interactuar con otras APIs además de la API de Kubernetes. -Kubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode. When an administrator creates a cluster, they configure the authorization modules that should be used in the API server. If more than one authorization modules are configured, Kubernetes checks each module, and if any module authorizes the request, then the request can proceed. If all of the modules deny the request, then the request is denied (HTTP status code 403). +Kubernetes soporta multiples modulos de autorización, como el modo ABAC, el modo RBAC y el modo Webhook. Cuando un administrador crea un cluster, se realiza la configuración de los modulos de autorización que deben ser usados con la API del server. Si mas de uno modulo de autorización es configurado, Kubernetes verificada cada uon y si alguno de ellos autoriza la petición entonces la misma se ejecuta. Si todos los modules deniegan la petición, entonces la misma es denegada (Con un error HTTP con código 403). -To learn more about Kubernetes authorization, including details about creating policies using the supported authorization modules, see [Authorization](/docs/reference/access-authn-authz/authorization/). +Para leer más acerca de las autorizaciones en Kubernetes, incluyendo detalles acerca de crear politicas usando los modulos de autorización soportados, vea [Authorization](/docs/reference/access-authn-authz/authorization/). -## Admission control +## Control de Admisión -Admission Control modules are software modules that can modify or reject requests. -In addition to the attributes available to Authorization modules, Admission -Control modules can access the contents of the object that is being created or modified. +Los modulos de Control de Admisión son modulos de software que solo pueen modificar o rechazar peticiones. +Adicionalmente a los atributos disponibles en los modulos de Autorización, los modulos de +Control de Admisión pueden acceder al contenido del objeto que esta siendo creado o modificado. -Admission controllers act on requests that create, modify, delete, or connect to (proxy) an object. -Admission controllers do not act on requests that merely read objects. -When multiple admission controllers are configured, they are called in order. +Los Controles de Admisión actúan en las peticiones que crean, modifican, borran ó se conectan (proxy) a un objeto. +cuando multiples modulos de control de admisión son configurados, son llamados en orden. -This is shown as step **3** in the diagram. +Esto se muestra en el paso 3 del diagrama. -Unlike Authentication and Authorization modules, if any admission controller module -rejects, then the request is immediately rejected. +A diferencia de los modulos de Autorización y Autenticación, si uno de los modulos de control de admisión +rechaza la petición, entonces es inmediatamente rechazada. -In addition to rejecting objects, admission controllers can also set complex defaults for -fields. +Adicionalmente a rechazar objetos, los controles de admisión pueden tambien permite establecer +valores predeterminados complejos. -The available Admission Control modules are described in [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). +Los modulos de Control de Admisión disponibles están descriptos en [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). -Once a request passes all admission controllers, it is validated using the validation routines -for the corresponding API object, and then written to the object store (shown as step **4**). +Cuando una petición pasa todos los controles de admisión, esta es validada usando la rutinas de validación +para el objeto API correspondiente y luego es escrita en el objeto. -## API server ports and IPs +## Puertos e IPs del API server -The previous discussion applies to requests sent to the secure port of the API server -(the typical case). The API server can actually serve on 2 ports: +La discusión previa aplica a peticiones enviadas a un puerto seguro del servidor API +(el caso típico). El servidor API puede en realidad servir en 2 puertos: -By default, the Kubernetes API server serves HTTP on 2 ports: +Por defecto, la API de Kubernetes entrega HTTP en 2 puertos: - 1. `localhost` port: + 1. puerto `localhost`: - - is intended for testing and bootstrap, and for other components of the master node - (scheduler, controller-manager) to talk to the API - - no TLS - - default is port 8080 - - default IP is localhost, change with `--insecure-bind-address` flag. + - debe usarse para testeo e iniciar el sistema y para otros componentes del nodo maestro + (scheduler, controller-manager) para hablar con la API + - no se usa TLS + - el puerto predeterminado es el 8080 + - la IP por defecto es localhost, la puede cambiar con el flag `--insecure-bind-address`. - request **bypasses** authentication and authorization modules. - - request handled by admission control module(s). - - protected by need to have host access + - peticiones controladas por los modulos de control de admisión. + - protejidas por necesidad para tener acceso al host - 2. “Secure port”: + 2. “Puerto seguro”: - - use whenever possible - - uses TLS. Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag. - - default is port 6443, change with `--secure-port` flag. - - default IP is first non-localhost network interface, change with `--bind-address` flag. - - request handled by authentication and authorization modules. - - request handled by admission control module(s). + - usar siempre que sea posible + - usa TLS. Se configura el certificado con el flag `--tls-cert-file` y la llave con `--tls-private-key-file`. + - el puerto predeterminado es 6443, se cambia con el flag `--secure-port`. + - la IP por defecto es la primer interface que no es la localhost. se cambia con el flag `--bind-address`. + - peticiones controladas por los modulos de autenticación y autorización. + - peticiones controladas por los modulos de control de admisión. - authentication and authorization modules run. ## {{% heading "whatsnext" %}} -Read more documentation on authentication, authorization and API access control: +Lea mas documentación sobre autenticación, autorización y el contro de acceso a la API: - [Authenticating](/docs/reference/access-authn-authz/authentication/) - [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) @@ -178,7 +180,7 @@ Read more documentation on authentication, authorization and API access control: - [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/) - [Administration](/docs/reference/access-authn-authz/service-accounts-admin/) -You can learn about: -- how Pods can use +Tambien puede aprender sobre: +- como los pods pueden usar [Secrets](/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials) - to obtain API credentials. + para obtener credenciales para la API. From b911ddeb5b25ba5d69cc944b0b4a718326d99770 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:36:00 -0300 Subject: [PATCH 03/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 01f4239eb4..978087fb7e 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -7,7 +7,7 @@ content_type: concept --- -Esta pagina proporciona información sobre el como controlar el acceso a la API de Kubernetes. +Esta página proporciona información sobre cómo controlar el acceso a la API de Kubernetes. From e4358a121f19b6d3d138ed95fdbdda95a81412b9 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:36:18 -0300 Subject: [PATCH 04/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 978087fb7e..95a36028c9 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -12,7 +12,7 @@ Esta página proporciona información sobre cómo controlar el acceso a la API d Los usuarios acceden a la [API de Kubernetes](/docs/concepts/overview/kubernetes-api/) usando `kubectl`, -client libraries, o haciendo peticiones REST. Humanos y los +bibliotecas de cliente, o haciendo peticiones REST. Usuarios y [Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) pueden ser autorizados para acceder a la API. Cuando una peticion llega a la API, pasa por varias etapas, estan ilustradas en el From fc7b76afcb5113fbfe470adc60b5168f0b963e44 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:36:32 -0300 Subject: [PATCH 05/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 95a36028c9..68d22b7c7a 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -15,7 +15,7 @@ Los usuarios acceden a la [API de Kubernetes](/docs/concepts/overview/kubernetes bibliotecas de cliente, o haciendo peticiones REST. Usuarios y [Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) pueden ser autorizados para acceder a la API. -Cuando una peticion llega a la API, pasa por varias etapas, estan ilustradas en el +Cuando una petición llega a la API, pasa por varias etapas, están ilustradas en el siguiente diagrama: ![Diagrama de pasos para una petición a la API de Kubernetes](/images/docs/admin/access-control-overview.svg) From 46b06953e509736740456e8e190f9763771fbb57 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:36:45 -0300 Subject: [PATCH 06/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 68d22b7c7a..6426e4cd31 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -23,7 +23,7 @@ siguiente diagrama: ## Transport security En un cluster típico de Kubernetes, la API sirve peticiones en el puerto 443, protegida por TLS. -El server API presenta un certificado. Este certificado puede ser firmando usando +El {{< glossary_tooltip term_id="kube-apiserver" text="API Server" >}} presenta un certificado. Este certificado puede ser firmando usando un certificado de autoridad privada (CA) o basado en una llave publica relacionada generalmente a un CA reconocido. From 900b959b5244863d6b33614a279af06c6fe36d29 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:36:56 -0300 Subject: [PATCH 07/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 6426e4cd31..ea3bc2333a 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -24,7 +24,7 @@ siguiente diagrama: En un cluster típico de Kubernetes, la API sirve peticiones en el puerto 443, protegida por TLS. El {{< glossary_tooltip term_id="kube-apiserver" text="API Server" >}} presenta un certificado. Este certificado puede ser firmando usando -un certificado de autoridad privada (CA) o basado en una llave publica relacionada +un certificado de autoridad privada (CA) o basado en una llave pública relacionada generalmente a un CA reconocido. Si el cluster usa un certificado de autoridad privado, se necesita copiar este certificado From f9541ec21dbc2fb1fa655e71336e33d3e37e235a Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:37:28 -0300 Subject: [PATCH 08/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index ea3bc2333a..2ec9b9e290 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -22,7 +22,7 @@ siguiente diagrama: ## Transport security -En un cluster típico de Kubernetes, la API sirve peticiones en el puerto 443, protegida por TLS. +En un {{< glossary_tooltip term_id="cluster" text="cluster" >}} típico de Kubernetes, la API sirve peticiones en el puerto 443, protegida por TLS. El {{< glossary_tooltip term_id="kube-apiserver" text="API Server" >}} presenta un certificado. Este certificado puede ser firmando usando un certificado de autoridad privada (CA) o basado en una llave pública relacionada generalmente a un CA reconocido. From 1e4927b59cd47131d5ad5d0f467da03f35115030 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:37:38 -0300 Subject: [PATCH 09/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 2ec9b9e290..40c2615704 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -144,7 +144,7 @@ Por defecto, la API de Kubernetes entrega HTTP en 2 puertos: - debe usarse para testeo e iniciar el sistema y para otros componentes del nodo maestro (scheduler, controller-manager) para hablar con la API - no se usa TLS - - el puerto predeterminado es el 8080 + - el puerto predeterminado es el `8080` - la IP por defecto es localhost, la puede cambiar con el flag `--insecure-bind-address`. - request **bypasses** authentication and authorization modules. - peticiones controladas por los modulos de control de admisión. From c2593677fa22fc3d12e3a4444080a17305eb424e Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:38:26 -0300 Subject: [PATCH 10/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 40c2615704..7c9537bbdb 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -28,7 +28,7 @@ un certificado de autoridad privada (CA) o basado en una llave pública relacion generalmente a un CA reconocido. Si el cluster usa un certificado de autoridad privado, se necesita copiar este certificado -CA configurado dentro de su `~/.kube/config` en el cliente, entonces usted podrá +CA configurado dentro de su `~/.kube/config` en el cliente, entonces se podrá confiar en la conección y estar seguro que no será hackeada. Su cliente puede presentar un certificado TLS de cliente en esta etapa. From fed463149e9b422d9671f2e457dba11cbdc1b5d1 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:38:34 -0300 Subject: [PATCH 11/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 7c9537bbdb..9fa36b096e 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -156,7 +156,7 @@ Por defecto, la API de Kubernetes entrega HTTP en 2 puertos: - usa TLS. Se configura el certificado con el flag `--tls-cert-file` y la llave con `--tls-private-key-file`. - el puerto predeterminado es 6443, se cambia con el flag `--secure-port`. - la IP por defecto es la primer interface que no es la localhost. se cambia con el flag `--bind-address`. - - peticiones controladas por los modulos de autenticación y autorización. + - peticiones controladas por los módulos de autenticación y autorización. - peticiones controladas por los modulos de control de admisión. - authentication and authorization modules run. From c3abe90f0cbeb0755fb9c2cd12d5a8e160b242ef Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:38:39 -0300 Subject: [PATCH 12/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 9fa36b096e..d4116a2d5b 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -157,7 +157,7 @@ Por defecto, la API de Kubernetes entrega HTTP en 2 puertos: - el puerto predeterminado es 6443, se cambia con el flag `--secure-port`. - la IP por defecto es la primer interface que no es la localhost. se cambia con el flag `--bind-address`. - peticiones controladas por los módulos de autenticación y autorización. - - peticiones controladas por los modulos de control de admisión. + - peticiones controladas por los módulos de control de admisión. - authentication and authorization modules run. ## {{% heading "whatsnext" %}} From d319828a173202c23d483c4f7be1f3b830f8307e Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:38:56 -0300 Subject: [PATCH 13/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 1 - 1 file changed, 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index d4116a2d5b..fd8b97bda4 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -158,7 +158,6 @@ Por defecto, la API de Kubernetes entrega HTTP en 2 puertos: - la IP por defecto es la primer interface que no es la localhost. se cambia con el flag `--bind-address`. - peticiones controladas por los módulos de autenticación y autorización. - peticiones controladas por los módulos de control de admisión. - - authentication and authorization modules run. ## {{% heading "whatsnext" %}} From 6f1f2d600a4fa3494c91118078c2b8fdb4b70a7b Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:39:19 -0300 Subject: [PATCH 14/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index fd8b97bda4..212e90c70d 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -29,7 +29,7 @@ generalmente a un CA reconocido. Si el cluster usa un certificado de autoridad privado, se necesita copiar este certificado CA configurado dentro de su `~/.kube/config` en el cliente, entonces se podrá -confiar en la conección y estar seguro que no será hackeada. +confiar en la conexión y estar seguro que no será comprometida. Su cliente puede presentar un certificado TLS de cliente en esta etapa. From 99bb07287997cd71c50467f159852f7f4d232d3f Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:39:48 -0300 Subject: [PATCH 15/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 212e90c70d..26d57d2854 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -31,7 +31,7 @@ Si el cluster usa un certificado de autoridad privado, se necesita copiar este c CA configurado dentro de su `~/.kube/config` en el cliente, entonces se podrá confiar en la conexión y estar seguro que no será comprometida. -Su cliente puede presentar un certificado TLS de cliente en esta etapa. +El cliente puede presentar un certificado TLS de cliente en esta etapa. ## Autenticación From 0a621a0f41d6ac963f1fea535baa088d8012017f Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:40:31 -0300 Subject: [PATCH 16/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 26d57d2854..994681f224 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -20,7 +20,7 @@ siguiente diagrama: ![Diagrama de pasos para una petición a la API de Kubernetes](/images/docs/admin/access-control-overview.svg) -## Transport security +## Seguridad en la capa de transporte En un {{< glossary_tooltip term_id="cluster" text="cluster" >}} típico de Kubernetes, la API sirve peticiones en el puerto 443, protegida por TLS. El {{< glossary_tooltip term_id="kube-apiserver" text="API Server" >}} presenta un certificado. Este certificado puede ser firmando usando From efc15f6fe4b8eb091514adda2e8334b286bdad36 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:40:53 -0300 Subject: [PATCH 17/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 994681f224..0d1649a105 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -35,7 +35,7 @@ El cliente puede presentar un certificado TLS de cliente en esta etapa. ## Autenticación -Una vez que se estableció el TLS, las peticiones HTTP avanzan a la etapa de autenticación. +Una vez que se estableció la conexión TLS, las peticiones HTTP avanzan a la etapa de autenticación. Esto se muestra en el paso 1 del diagrama. El script de creación del cluster o el administrador del cluster configurada el servidor API para ejecutar uno o mas módulos de autenticación. From 3305c6ab76f46bc483c0ae49e6ed16be9f79dc16 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:41:26 -0300 Subject: [PATCH 18/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 0d1649a105..5f8ea4dcb7 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -37,7 +37,7 @@ El cliente puede presentar un certificado TLS de cliente en esta etapa. Una vez que se estableció la conexión TLS, las peticiones HTTP avanzan a la etapa de autenticación. Esto se muestra en el paso 1 del diagrama. -El script de creación del cluster o el administrador del cluster configurada el servidor API para ejecutar +El script de creación del cluster o el administrador del cluster puede configurar el {{< glossary_tooltip term_id="kube-apiserver" text="API Server" >}} para ejecutar uno o mas módulos de autenticación. Los Autenticadores estan descriptos con más detalle en [Authentication](/docs/reference/access-authn-authz/authentication/). From a4923189e53187524ef7f1502a4814c8b91ddf0a Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:43:03 -0300 Subject: [PATCH 19/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 5f8ea4dcb7..16c2467c04 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -39,7 +39,7 @@ Una vez que se estableció la conexión TLS, las peticiones HTTP avanzan a la et Esto se muestra en el paso 1 del diagrama. El script de creación del cluster o el administrador del cluster puede configurar el {{< glossary_tooltip term_id="kube-apiserver" text="API Server" >}} para ejecutar uno o mas módulos de autenticación. -Los Autenticadores estan descriptos con más detalle en +Los Autenticadores están descritos con más detalle en [Authentication](/docs/reference/access-authn-authz/authentication/). ```The input to the authentication step is the entire HTTP request; however, it typically From 701dd37d61f343db200d2e3a2a9633ed1db94394 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:45:23 -0300 Subject: [PATCH 20/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 16c2467c04..d5dfcd36ad 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -45,7 +45,7 @@ Los Autenticadores están descritos con más detalle en ```The input to the authentication step is the entire HTTP request; however, it typically examines the headers and/or client certificate. ``` -El ingreso al paso de autenticación es la petición HTTP completa, aun así, esta tipicamente +La entrada al paso de autenticación es la petición HTTP completa, aun así, esta tipicamente examina las cabeceras y/o el certificado del cliente. Los modulos de autenticación incluyen certificado de cliente, contraseña, tokens planos, From d1517c5dd9c7c772d2c81ae07163447e8f18bea2 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:45:38 -0300 Subject: [PATCH 21/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index d5dfcd36ad..6d63553a60 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -51,7 +51,7 @@ examina las cabeceras y/o el certificado del cliente. Los modulos de autenticación incluyen certificado de cliente, contraseña, tokens planos, tokens de inicio y JSON Web Tokens (usados para los service accounts). -Multiples modulos de autenticación puede ser especificados, en este caso cada uno es probado secuencialmente, +Múltiples módulos de autenticación puede ser especificados, en este caso cada uno es probado secuencialmente, hasta que uno de ellos tiene éxito. Si la petición no puede ser autenticada, la misma es rechazada con un codigo de estado HTTP 401. From 732887cef62fa41704f6a2aecd16b4fee12e39cd Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:45:51 -0300 Subject: [PATCH 22/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 6d63553a60..3f66bec3da 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -54,7 +54,7 @@ tokens de inicio y JSON Web Tokens (usados para los service accounts). Múltiples módulos de autenticación puede ser especificados, en este caso cada uno es probado secuencialmente, hasta que uno de ellos tiene éxito. -Si la petición no puede ser autenticada, la misma es rechazada con un codigo de estado HTTP 401. +Si la petición no puede ser autenticada, la misma es rechazada con un código HTTP 401. En otro caso, el usuario es validado con el `username` específico, y el nombre de usuario esta disponible para los pasos siguientes. Algunos autenticadores tambien proporcionan membresías de grupo al usuario, mientras que otros From 73de7ea1e32395317e019bb423ad626518360fe1 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:46:24 -0300 Subject: [PATCH 23/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 3f66bec3da..3ac9042a1f 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -60,9 +60,7 @@ esta disponible para los pasos siguientes. Algunos autenticadores tambien proporcionan membresías de grupo al usuario, mientras que otros no lo hacen. -While Kubernetes uses usernames for access control decisions and in request logging, -este n otiene un objeto `User` ni tampoco guarda nombres de usaurio o otra información acerca -de ellos en su API. +Aunque Kubernetes utiliza los nombres de usuario para tomar decisiones durante el control de acceso y para registrar las peticiones de entrada, no tiene un objeto `User` ni tampoco almacena información sobre los usuarios en la API. ## Autorización From a5b79e7fd1af08cff37271c30765c58ab12e8fc6 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:46:43 -0300 Subject: [PATCH 24/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 3ac9042a1f..966a88b81b 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -82,7 +82,7 @@ Por ejemplo, si Bob tiene la siguiente politica, entonces el puede leer pods sol } } ``` -Si Bob hace la siguiente petición, será aturizada porque él tiene permitido leer los objetos en el namespace `projectCaribou` : +Si Bob hace la siguiente petición, será autorizada dado que tiene permitido leer los objetos en el namespace `projectCaribou` : ```json { From 04187d06d6ee36a27e32e4f7f06751994df25c58 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:47:06 -0300 Subject: [PATCH 25/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index 966a88b81b..ea6aef2d19 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -55,7 +55,7 @@ Múltiples módulos de autenticación puede ser especificados, en este caso cada hasta que uno de ellos tiene éxito. Si la petición no puede ser autenticada, la misma es rechazada con un código HTTP 401. -En otro caso, el usuario es validado con el `username` específico, y el nombre de usuario +Si la autenticación tiene éxito, el usuario es validado con el `username` específico, y el nombre de usuario esta disponible para los pasos siguientes. Algunos autenticadores tambien proporcionan membresías de grupo al usuario, mientras que otros no lo hacen. From 1e82410a0a80ee51c97ad83344de8359332105c1 Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:47:19 -0300 Subject: [PATCH 26/27] Update content/es/docs/concepts/security/controlling-access.md Co-authored-by: Rael Garcia --- content/es/docs/concepts/security/controlling-access.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index ea6aef2d19..f273cd9a1d 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -57,7 +57,7 @@ hasta que uno de ellos tiene éxito. Si la petición no puede ser autenticada, la misma es rechazada con un código HTTP 401. Si la autenticación tiene éxito, el usuario es validado con el `username` específico, y el nombre de usuario esta disponible para los pasos siguientes. Algunos autenticadores -tambien proporcionan membresías de grupo al usuario, mientras que otros +también proporcionan membresías de grupo al usuario, mientras que otros no lo hacen. Aunque Kubernetes utiliza los nombres de usuario para tomar decisiones durante el control de acceso y para registrar las peticiones de entrada, no tiene un objeto `User` ni tampoco almacena información sobre los usuarios en la API. From 9a577a0ed6fd2643872db62eb513502d4775072e Mon Sep 17 00:00:00 2001 From: Emilano Vazquez Date: Wed, 29 Dec 2021 12:52:22 -0300 Subject: [PATCH 27/27] Apply suggestions from code review Co-authored-by: Rael Garcia --- .../concepts/security/controlling-access.md | 42 +++++++++---------- 1 file changed, 19 insertions(+), 23 deletions(-) diff --git a/content/es/docs/concepts/security/controlling-access.md b/content/es/docs/concepts/security/controlling-access.md index f273cd9a1d..8d33ac49b4 100644 --- a/content/es/docs/concepts/security/controlling-access.md +++ b/content/es/docs/concepts/security/controlling-access.md @@ -42,9 +42,6 @@ uno o mas módulos de autenticación. Los Autenticadores están descritos con más detalle en [Authentication](/docs/reference/access-authn-authz/authentication/). -```The input to the authentication step is the entire HTTP request; however, it typically -examines the headers and/or client certificate. -``` La entrada al paso de autenticación es la petición HTTP completa, aun así, esta tipicamente examina las cabeceras y/o el certificado del cliente. @@ -64,11 +61,11 @@ Aunque Kubernetes utiliza los nombres de usuario para tomar decisiones durante e ## Autorización -Despues de autenticar la petición como proveniente de un usuario específico, la petición debe ser autorizada. Esto se muestra en el paso 2 del diagrama. +Después de autenticar la petición como proveniente de un usuario específico, la petición debe ser autorizada. Esto se muestra en el paso 2 del diagrama. -Una petición debe incluir el nombre de usuario solicitante, la acción solicitada y el objeto afectado por la acción. La petición es autorizada si hay una politica existente que declare que el usuario tiene permisos para la realizar la acción. +Una petición debe incluir el nombre de usuario solicitante, la acción solicitada y el objeto afectado por la acción. La petición es autorizada si hay una política existente que declare que el usuario tiene permisos para la realizar la acción. -Por ejemplo, si Bob tiene la siguiente politica, entonces el puede leer pods solamente en el namespace `projectCaribou`: +Por ejemplo, si el usuario Bob tiene la siguiente política, entonces puede leer pods solamente en el namespace `projectCaribou`: ```json { @@ -98,33 +95,33 @@ Si Bob hace la siguiente petición, será autorizada dado que tiene permitido le } } ``` -Si Bob en su petición intenta escribir (`create` o `update`) en los objetos del namespace `projectCaribou`. Si Bob hace una petición para leer (`get`) objetocs en otro namespace como `projectFish`, entonces la autorización será denegada. +En cambio, si Bob en su petición intenta escribir (`create` o `update`) en los objetos del namespace `projectCaribou`, la petición será denegada. Del mismo modo, si Bob hace una petición para leer (`get`) objetos en otro namespace como `projectFish`, la autorización también será denegada. Las autorizaciones en Kubernetes requieren que se usen atributos REST comunes para interactuar con el existente sistema de control de toda la organización o del proveedor cloud. Es importante usar formatos REST porque esos sistemas de control pueden interactuar con otras APIs además de la API de Kubernetes. -Kubernetes soporta multiples modulos de autorización, como el modo ABAC, el modo RBAC y el modo Webhook. Cuando un administrador crea un cluster, se realiza la configuración de los modulos de autorización que deben ser usados con la API del server. Si mas de uno modulo de autorización es configurado, Kubernetes verificada cada uon y si alguno de ellos autoriza la petición entonces la misma se ejecuta. Si todos los modules deniegan la petición, entonces la misma es denegada (Con un error HTTP con código 403). +Kubernetes soporta múltiples módulos de autorización, como el modo ABAC, el modo RBAC y el modo Webhook. Cuando un administrador crea un cluster, se realiza la configuración de los módulos de autorización que deben ser usados con la API del server. Si más de uno módulo de autorización es configurado, Kubernetes verificada cada uno y si alguno de ellos autoriza la petición entonces la misma se ejecuta. Si todos los modules deniegan la petición, entonces la misma es denegada (Con un error HTTP con código 403). -Para leer más acerca de las autorizaciones en Kubernetes, incluyendo detalles acerca de crear politicas usando los modulos de autorización soportados, vea [Authorization](/docs/reference/access-authn-authz/authorization/). +Para leer más acerca de las autorizaciones en Kubernetes, incluyendo detalles sobre cómo crear politicas usando los módulos de autorización soportados, vea [Authorization](/docs/reference/access-authn-authz/authorization/). ## Control de Admisión -Los modulos de Control de Admisión son modulos de software que solo pueen modificar o rechazar peticiones. -Adicionalmente a los atributos disponibles en los modulos de Autorización, los modulos de +Los módulos de Control de Admisión son módulos de software que solo pueden modificar o rechazar peticiones. +Adicionalmente a los atributos disponibles en los módulos de Autorización, los de Control de Admisión pueden acceder al contenido del objeto que esta siendo creado o modificado. -Los Controles de Admisión actúan en las peticiones que crean, modifican, borran ó se conectan (proxy) a un objeto. -cuando multiples modulos de control de admisión son configurados, son llamados en orden. +Los Controles de Admisión actúan en las peticiones que crean, modifican, borran o se conectan (proxy) a un objeto. +Cuando múltiples módulos de control de admisión son configurados, son llamados en orden. Esto se muestra en el paso 3 del diagrama. -A diferencia de los modulos de Autorización y Autenticación, si uno de los modulos de control de admisión +A diferencia de los módulos de Autorización y Autenticación, si uno de los módulos de control de admisión rechaza la petición, entonces es inmediatamente rechazada. -Adicionalmente a rechazar objetos, los controles de admisión pueden tambien permite establecer +Adicionalmente a rechazar objetos, los controles de admisión también permiten establecer valores predeterminados complejos. -Los modulos de Control de Admisión disponibles están descriptos en [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). +Los módulos de Control de Admisión disponibles están descritos en [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). Cuando una petición pasa todos los controles de admisión, esta es validada usando la rutinas de validación para el objeto API correspondiente y luego es escrita en el objeto. @@ -144,22 +141,22 @@ Por defecto, la API de Kubernetes entrega HTTP en 2 puertos: - no se usa TLS - el puerto predeterminado es el `8080` - la IP por defecto es localhost, la puede cambiar con el flag `--insecure-bind-address`. - - request **bypasses** authentication and authorization modules. + - la petición no pasa por los mecanismos de autenticación ni autorización - peticiones controladas por los modulos de control de admisión. - - protejidas por necesidad para tener acceso al host + - protegidas por necesidad para tener acceso al host 2. “Puerto seguro”: - usar siempre que sea posible - - usa TLS. Se configura el certificado con el flag `--tls-cert-file` y la llave con `--tls-private-key-file`. - - el puerto predeterminado es 6443, se cambia con el flag `--secure-port`. + - usa TLS. Se configura el certificado con el flag `--tls-cert-file` y la clave con `--tls-private-key-file`. + - el puerto predeterminado es `6443`, se cambia con el flag `--secure-port`. - la IP por defecto es la primer interface que no es la localhost. se cambia con el flag `--bind-address`. - peticiones controladas por los módulos de autenticación y autorización. - peticiones controladas por los módulos de control de admisión. ## {{% heading "whatsnext" %}} -Lea mas documentación sobre autenticación, autorización y el contro de acceso a la API: +En los siguientes enlaces, encontrará mucha más documentación sobre autenticación, autorización y el control de acceso a la API: - [Authenticating](/docs/reference/access-authn-authz/authentication/) - [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) @@ -177,7 +174,6 @@ Lea mas documentación sobre autenticación, autorización y el contro de acceso - [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/) - [Administration](/docs/reference/access-authn-authz/service-accounts-admin/) -Tambien puede aprender sobre: -- como los pods pueden usar +- Como los pods pueden usar [Secrets](/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials) para obtener credenciales para la API.