Skip to content

Commit 2f511e4

Browse files
authored
Merge branch 'main' into ja-fix-link
2 parents 82a201c + f030fbf commit 2f511e4

File tree

33 files changed

+1055
-683
lines changed

33 files changed

+1055
-683
lines changed

content/en/docs/contribute/review/reviewing-prs.md

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -85,7 +85,11 @@ class third,fourth white
8585
- Reading the PR description to understand the changes made, and read any linked issues
8686
- Reading any comments by other reviewers
8787
- Clicking the **Files changed** tab to see the files and lines changed
88-
- Previewing the changes in the Netlify preview build by scrolling to the PR's build check section at the bottom of the **Conversation** tab and clicking the **deploy/netlify** line's **Details** link.
88+
- Previewing the changes in the Netlify preview build by scrolling to the PR's build check section at the bottom of the **Conversation** tab.
89+
Here's a screenshot (this shows GitHub's desktop site; if you're reviewing
90+
on a tablet or smartphone device, the GitHub web UI is slightly different):
91+
{{< figure src="/images/docs/github_netlify_deploy_preview.png" alt="GitHub pull request details including link to Netlify preview" >}}
92+
To open the preview, click on the **Details** link of the **deploy/netlify** line in the list of checks.
8993

9094
4. Go to the **Files changed** tab to start your review.
9195
1. Click on the `+` symbol beside the line you want to comment on.
Lines changed: 179 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,179 @@
1+
---
2+
reviewers:
3+
- electrocucaracha
4+
- raelga
5+
title: Controlando el Acceso a la API de Kubernetes
6+
content_type: concept
7+
---
8+
9+
<!-- overview -->
10+
Esta página proporciona información sobre cómo controlar el acceso a la API de Kubernetes.
11+
12+
13+
<!-- body -->
14+
Los usuarios acceden a la [API de Kubernetes](/docs/concepts/overview/kubernetes-api/) usando `kubectl`,
15+
bibliotecas de cliente, o haciendo peticiones REST. Usuarios y
16+
[Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/) pueden ser
17+
autorizados para acceder a la API.
18+
Cuando una petición llega a la API, pasa por varias etapas, están ilustradas en el
19+
siguiente diagrama:
20+
21+
![Diagrama de pasos para una petición a la API de Kubernetes](/images/docs/admin/access-control-overview.svg)
22+
23+
## Seguridad en la capa de transporte
24+
25+
En un {{< glossary_tooltip term_id="cluster" text="cluster" >}} típico de Kubernetes, la API sirve peticiones en el puerto 443, protegida por TLS.
26+
El {{< glossary_tooltip term_id="kube-apiserver" text="API Server" >}} presenta un certificado. Este certificado puede ser firmando usando
27+
un certificado de autoridad privada (CA) o basado en una llave pública relacionada
28+
generalmente a un CA reconocido.
29+
30+
Si el cluster usa un certificado de autoridad privado, se necesita copiar este certificado
31+
CA configurado dentro de su `~/.kube/config` en el cliente, entonces se podrá
32+
confiar en la conexión y estar seguro que no será comprometida.
33+
34+
El cliente puede presentar un certificado TLS de cliente en esta etapa.
35+
36+
## Autenticación
37+
38+
Una vez que se estableció la conexión TLS, las peticiones HTTP avanzan a la etapa de autenticación.
39+
Esto se muestra en el paso 1 del diagrama.
40+
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
41+
uno o mas módulos de autenticación.
42+
Los Autenticadores están descritos con más detalle en
43+
[Authentication](/docs/reference/access-authn-authz/authentication/).
44+
45+
La entrada al paso de autenticación es la petición HTTP completa, aun así, esta tipicamente
46+
examina las cabeceras y/o el certificado del cliente.
47+
48+
Los modulos de autenticación incluyen certificado de cliente, contraseña, tokens planos,
49+
tokens de inicio y JSON Web Tokens (usados para los service accounts).
50+
51+
Múltiples módulos de autenticación puede ser especificados, en este caso cada uno es probado secuencialmente,
52+
hasta que uno de ellos tiene éxito.
53+
54+
Si la petición no puede ser autenticada, la misma es rechazada con un código HTTP 401.
55+
Si la autenticación tiene éxito, el usuario es validado con el `username` específico, y el nombre de usuario
56+
esta disponible para los pasos siguientes. Algunos autenticadores
57+
también proporcionan membresías de grupo al usuario, mientras que otros
58+
no lo hacen.
59+
60+
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.
61+
62+
## Autorización
63+
64+
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.
65+
66+
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.
67+
68+
Por ejemplo, si el usuario Bob tiene la siguiente política, entonces puede leer pods solamente en el namespace `projectCaribou`:
69+
70+
```json
71+
{
72+
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
73+
"kind": "Policy",
74+
"spec": {
75+
"user": "bob",
76+
"namespace": "projectCaribou",
77+
"resource": "pods",
78+
"readonly": true
79+
}
80+
}
81+
```
82+
Si Bob hace la siguiente petición, será autorizada dado que tiene permitido leer los objetos en el namespace `projectCaribou` :
83+
84+
```json
85+
{
86+
"apiVersion": "authorization.k8s.io/v1beta1",
87+
"kind": "SubjectAccessReview",
88+
"spec": {
89+
"resourceAttributes": {
90+
"namespace": "projectCaribou",
91+
"verb": "get",
92+
"group": "unicorn.example.org",
93+
"resource": "pods"
94+
}
95+
}
96+
}
97+
```
98+
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.
99+
100+
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.
101+
102+
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).
103+
104+
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/).
105+
106+
107+
## Control de Admisión
108+
109+
Los módulos de Control de Admisión son módulos de software que solo pueden modificar o rechazar peticiones.
110+
Adicionalmente a los atributos disponibles en los módulos de Autorización, los de
111+
Control de Admisión pueden acceder al contenido del objeto que esta siendo creado o modificado.
112+
113+
Los Controles de Admisión actúan en las peticiones que crean, modifican, borran o se conectan (proxy) a un objeto.
114+
Cuando múltiples módulos de control de admisión son configurados, son llamados en orden.
115+
116+
Esto se muestra en el paso 3 del diagrama.
117+
118+
A diferencia de los módulos de Autorización y Autenticación, si uno de los módulos de control de admisión
119+
rechaza la petición, entonces es inmediatamente rechazada.
120+
121+
Adicionalmente a rechazar objetos, los controles de admisión también permiten establecer
122+
valores predeterminados complejos.
123+
124+
Los módulos de Control de Admisión disponibles están descritos en [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/).
125+
126+
Cuando una petición pasa todos los controles de admisión, esta es validada usando la rutinas de validación
127+
para el objeto API correspondiente y luego es escrita en el objeto.
128+
129+
130+
## Puertos e IPs del API server
131+
132+
La discusión previa aplica a peticiones enviadas a un puerto seguro del servidor API
133+
(el caso típico). El servidor API puede en realidad servir en 2 puertos:
134+
135+
Por defecto, la API de Kubernetes entrega HTTP en 2 puertos:
136+
137+
1. puerto `localhost`:
138+
139+
- debe usarse para testeo e iniciar el sistema y para otros componentes del nodo maestro
140+
(scheduler, controller-manager) para hablar con la API
141+
- no se usa TLS
142+
- el puerto predeterminado es el `8080`
143+
- la IP por defecto es localhost, la puede cambiar con el flag `--insecure-bind-address`.
144+
- la petición no pasa por los mecanismos de autenticación ni autorización
145+
- peticiones controladas por los modulos de control de admisión.
146+
- protegidas por necesidad para tener acceso al host
147+
148+
2. “Puerto seguro”:
149+
150+
- usar siempre que sea posible
151+
- usa TLS. Se configura el certificado con el flag `--tls-cert-file` y la clave con `--tls-private-key-file`.
152+
- el puerto predeterminado es `6443`, se cambia con el flag `--secure-port`.
153+
- la IP por defecto es la primer interface que no es la localhost. se cambia con el flag `--bind-address`.
154+
- peticiones controladas por los módulos de autenticación y autorización.
155+
- peticiones controladas por los módulos de control de admisión.
156+
157+
## {{% heading "whatsnext" %}}
158+
159+
En los siguientes enlaces, encontrará mucha más documentación sobre autenticación, autorización y el control de acceso a la API:
160+
161+
- [Authenticating](/docs/reference/access-authn-authz/authentication/)
162+
- [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/)
163+
- [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/)
164+
- [Dynamic Admission Control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
165+
- [Authorization](/docs/reference/access-authn-authz/authorization/)
166+
- [Role Based Access Control](/docs/reference/access-authn-authz/rbac/)
167+
- [Attribute Based Access Control](/docs/reference/access-authn-authz/abac/)
168+
- [Node Authorization](/docs/reference/access-authn-authz/node/)
169+
- [Webhook Authorization](/docs/reference/access-authn-authz/webhook/)
170+
- [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/)
171+
- including [CSR approval](/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection)
172+
and [certificate signing](/docs/reference/access-authn-authz/certificate-signing-requests/#signing)
173+
- Service accounts
174+
- [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/)
175+
- [Administration](/docs/reference/access-authn-authz/service-accounts-admin/)
176+
177+
- Como los pods pueden usar
178+
[Secrets](/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials)
179+
para obtener credenciales para la API.

content/id/docs/concepts/cluster-administration/networking.md

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -195,10 +195,6 @@ Multus mendukung semua [plugin referensi](https://github.com/containernetworking
195195

196196
Platform Nuage menggunakan _overlay_ untuk menyediakan jaringan berbasis kebijakan yang mulus antara Kubernetes Pod-Pod dan lingkungan non-Kubernetes (VM dan server _bare metal_). Model abstraksi kebijakan Nuage dirancang dengan mempertimbangkan aplikasi dan membuatnya mudah untuk mendeklarasikan kebijakan berbutir halus untuk aplikasi. Mesin analisis _real-time_ platform memungkinkan pemantauan visibilitas dan keamanan untuk aplikasi Kubernetes.
197197

198-
### OpenVSwitch
199-
200-
[OpenVSwitch](https://www.openvswitch.org/) adalah cara yang agak lebih dewasa tetapi juga rumit untuk membangun jaringan _overlay_. Ini didukung oleh beberapa "Toko Besar" untuk jaringan.
201-
202198
### OVN (Open Virtual Networking)
203199

204200
OVN adalah solusi virtualisasi jaringan opensource yang dikembangkan oleh komunitas Open vSwitch. Ini memungkinkan seseorang membuat switch logis, router logis, ACL stateful, load-balancers dll untuk membangun berbagai topologi jaringan virtual. Proyek ini memiliki plugin dan dokumentasi Kubernetes spesifik di [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes).

content/id/docs/concepts/services-networking/service.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -387,7 +387,7 @@ _Value_ dan perilaku dari tipe `Service` dijelaskan sebagai berikut:
387387
* `ClusterIP`: Mengekspos `Service` ke _range_ alamat IP di dalam klaster. Apabila kamu memilih _value_ ini
388388
`Service` yang kamu miliki hanya dapat diakses secara internal. tipe ini adalah
389389
_default_ _value_ dari _ServiceType_.
390-
* [`NodePort`](#nodeport): Mengekspos `Service` pada setiap IP *node* pada _port_ statis
390+
* [`NodePort`](#type-nodeport): Mengekspos `Service` pada setiap IP *node* pada _port_ statis
391391
atau _port_ yang sama. Sebuah `Service` `ClusterIP`, yang mana `Service` `NodePort` akan di-_route_
392392
, dibuat secara otomatis. Kamu dapat mengakses `Service` dengan tipe ini,
393393
dari luar klaster melalui `<NodeIP>:<NodePort>`.
@@ -399,7 +399,7 @@ _Value_ dan perilaku dari tipe `Service` dijelaskan sebagai berikut:
399399
catatan `CNAME` beserta _value_-nya. Tidak ada metode _proxy_ apa pun yang diaktifkan. Mekanisme ini
400400
setidaknya membutuhkan `kube-dns` versi 1.7.
401401

402-
### Type NodePort {#nodeport}
402+
### Type NodePort {#type-nodeport}
403403

404404
Jika kamu menerapkan _value_ `NodePort` pada _field_ _type_, master Kubernetes akan mengalokasikan
405405
_port_ dari _range_ yang dispesifikasikan oleh penanda `--service-node-port-range` (secara _default_, 30000-32767)

content/ja/docs/concepts/cluster-administration/networking.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -243,7 +243,7 @@ Lars Kellogg-Stedman.
243243

244244
### Multus (a Multi Network plugin)
245245

246-
[Multus](https://github.com/Intel-Corp/multus-cni) is a Multi CNI plugin to support the Multi Networking feature in Kubernetes using CRD based network objects in Kubernetes.
246+
Multus is a Multi CNI plugin to support the Multi Networking feature in Kubernetes using CRD based network objects in Kubernetes.
247247

248248
Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes.
249249

content/ja/docs/concepts/extend-kubernetes/_index.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -30,7 +30,7 @@ Kubernetesは柔軟な設定が可能で、高い拡張性を持っています
3030

3131
ホスティングされたKubernetesサービスやマネージドなKubernetesでは、フラグと設定ファイルが常に変更できるとは限りません。変更可能な場合でも、通常はクラスターの管理者のみが変更できます。また、それらは将来のKubernetesバージョンで変更される可能性があり、設定変更にはプロセスの再起動が必要になるかもしれません。これらの理由により、この方法は他の選択肢が無いときにのみ利用するべきです。
3232

33-
[ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
33+
[ResourceQuota](/ja/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/ja/docs/concepts/services-networking/network-policies/)、そしてロールベースアクセス制御([RBAC](/ja/docs/reference/access-authn-authz/rbac/))といった *ビルトインポリシーAPI* は、ビルトインのKubernetes APIです。APIは通常、ホスティングされたKubernetesサービスやマネージドなKubernetesで利用されます。これらは宣言的で、Podのような他のKubernetesリソースと同じ慣例に従っています。そのため、新しいクラスターの設定は繰り返し再利用することができ、アプリケーションと同じように管理することが可能です。さらに、安定版(stable)を利用している場合、他のKubernetes APIのような[定義済みのサポートポリシー](/docs/reference/deprecation-policy/)を利用することができます。これらの理由により、この方法は、適切な用途の場合、 *設定ファイル* や *フラグ* よりも好まれます。
3434

3535
## 拡張
3636

@@ -115,7 +115,7 @@ Kubdernetesはいくつかのビルトイン認証方式をサポートしてい
115115

116116
[認証](/ja/docs/reference/access-authn-authz/authentication/)は、全てのリクエストのヘッダーまたは証明書情報を、リクエストを投げたクライアントのユーザー名にマッピングします。
117117

118-
Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。
118+
Kubernetesはいくつかのビルトイン認証方式と、それらが要件に合わない場合、[認証Webhook](/ja/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)を提供します。
119119

120120
### 認可
121121

content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -118,7 +118,7 @@ CRDオブジェクトの名前は[DNSサブドメイン名](/ja/docs/concepts/ov
118118

119119
通常、Kubernetes APIの各リソースは、RESTリクエストとオブジェクトの永続的なストレージを管理するためのコードが必要です。メインのKubernetes APIサーバーは *Pod**Service* のようなビルトインのリソースを処理し、またカスタムリソースも[CRD](#customresourcedefinition)を通じて同じように管理することができます。
120120

121-
[アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独自のスタンドアローンAPIサーバーを書き、デプロイすることで、カスタムリソースに特化した実装の提供を可能にします。メインのAPIサーバーが、処理したいカスタムリソースへのリクエストを委譲することで、他のクライアントからも利用できるようにします。
121+
[アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)は、独自のAPIサーバーを書き、デプロイすることで、カスタムリソースに特化した実装の提供を可能にします。メインのAPIサーバーが、処理したいカスタムリソースへのリクエストを独自のAPIサーバーに委譲することで、他のクライアントからも利用できるようにします。
122122

123123
## カスタムリソースの追加方法を選択する
124124

0 commit comments

Comments
 (0)