istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Reorganize reference docs (#5595) 

* Reorganize reference docs

* aliases

* corrections

* fix broken links

* fix broken link

* another broken link

* another broken link
This commit is contained in:
Frank Budinsky 2019-11-11 17:46:27 -05:00 committed by GitHub
parent f9b731eb60
commit 823e85b69a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
25 changed files with 56 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
content/en/blog/2018/istio-authorization/index.md
View File

@ -18,7 +18,7 @@ provides micro-segmentation for services in an Istio mesh. It features:
* High performance, as it is enforced natively on Envoy.
* Role-based semantics, which makes it easy to use.
* High flexibility as it allows users to define conditions using
[combinations of attributes](/docs/reference/config/authorization/constraints-and-properties/).
[combinations of attributes](/docs/reference/config/security/constraints-and-properties/).
In this blog post, you'll learn about the main authorization features and how to use them in different situations.
@ -49,7 +49,7 @@ frontend service.
duplicate configurations in multiple places and later forget to update some of them when you need to make changes.
On the other hand, Istio's authorization system is not a traditional RBAC system. It also allows users to define **conditions** using
[combinations of attributes](/docs/reference/config/authorization/constraints-and-properties/). This gives Istio
[combinations of attributes](/docs/reference/config/security/constraints-and-properties/). This gives Istio
flexibility to express complex access control policies. In fact, **the "RBAC + conditions” model
that Istio authorization adopts, has all the benefits an RBAC system has, and supports the level of flexibility that
normally an ABAC system provides.** You'll see some [examples](#examples) below.

2
content/en/blog/2019/performance-best-practices/index.md
View File

@ -33,7 +33,7 @@ Say you run 2,000 Envoy-injected pods, each handling 1,000 requests per second.
It is also important to focus on data plane performance for **latency** reasons. This is because most application requests move through the Istio data plane, not the control plane. There are two exceptions:
1. **Telemetry reporting:** Each proxy sends raw telemetry data to {{<gloss>}}Mixer{{</gloss>}}, which Mixer processes into metrics, traces, and other telemetry. The raw telemetry data is similar to access logs, and therefore comes at a cost. Access log processing consumes CPU and keeps a worker thread from picking up the next unit of work. At higher throughput, it is more likely that the next unit of work is waiting in the queue to be picked up by the worker. This can lead to long-tail (99th percentile) latency for Envoy.
1. **Custom policy checks:** When using [custom Istio policy adapters](/docs/concepts/observability/), policy checks are on the request path. This means that request headers and metadata on the data path will be sent to the control plane (Mixer), resulting in higher request latency. **Note:** These policy checks are [disabled by default](/docs/reference/config/installation-options/#global-options), as the most common policy use case ([RBAC](/docs/reference/config/authorization/istio.rbac.v1alpha1)) is performed entirely by the Envoy proxies.
1. **Custom policy checks:** When using [custom Istio policy adapters](/docs/concepts/observability/), policy checks are on the request path. This means that request headers and metadata on the data path will be sent to the control plane (Mixer), resulting in higher request latency. **Note:** These policy checks are [disabled by default](/docs/reference/config/installation-options/#global-options), as the most common policy use case ([RBAC](/docs/reference/config/security/istio.rbac.v1alpha1)) is performed entirely by the Envoy proxies.
Both of these exceptions will go away in a future Istio release, when [Mixer V2](https://docs.google.com/document/d/1QKmtem5jU_2F3Lh5SqLp0IuPb80_70J7aJEYu4_gS-s) moves all policy and telemetry features directly into the proxies.

4
content/en/blog/2019/v1beta1-authorization-policy/index.md
View File

@ -9,7 +9,7 @@ target_release: 1.4
---
Istio 1.4 introduces the
[`v1beta1` authorization policy](/docs/reference/config/authorization/authorization-policy/),
[`v1beta1` authorization policy](/docs/reference/config/security/authorization-policy/),
which is a major update to the previous `v1alpha1` role-based access control
(RBAC) policy. The new policy provides these improvements:
@ -74,7 +74,7 @@ The new `v1beta1` authorization policy had several design goals:
## `AuthorizationPolicy`
An [`AuthorizationPolicy` custom resource](/docs/reference/config/authorization/authorization-policy/)
An [`AuthorizationPolicy` custom resource](/docs/reference/config/security/authorization-policy/)
enables access control on workloads. This section gives an overview of the
changes in the `v1beta1` authorization policy.

10
content/en/docs/concepts/security/index.md
View File

@ -518,7 +518,7 @@ peers:
The mutual TLS setting has an optional `mode` parameter that defines the
strictness of the peer transport authentication. These modes are documented
in the [Authentication Policy reference document](/docs/reference/config/istio.authentication.v1alpha1/#MutualTls-Mode).
in the [Authentication Policy reference document](/docs/reference/config/security/istio.authentication.v1alpha1/#MutualTls-Mode).
The default mutual TLS mode is `STRICT`. Therefore, `mode: STRICT` is equivalent to all of the following:
@ -602,7 +602,7 @@ Istio's authorization feature provides mesh-level, namespace-level, and workload
access control on workloads in an Istio Mesh. It provides:
- **Workload-to-workload and end-user-to-workload authorization**.
- **A Simple API**, it includes a single [`AuthorizationPolicy` CRD](/docs/reference/config/authorization/authorization-policy/), which is easy to use and maintain.
- **A Simple API**, it includes a single [`AuthorizationPolicy` CRD](/docs/reference/config/security/authorization-policy/), which is easy to use and maintain.
- **Flexible semantics**, operators can define custom conditions on Istio attributes.
- **High performance**, as Istio authorization is enforced natively on Envoy.
- **High compatibility**, supports HTTP, HTTPS and HTTP2 natively, as well as any plain TCP protocols.
@ -639,7 +639,7 @@ multiple authorization policies apply to the same workload, the effect is additi
### Authorization policy
To configure an Istio authorization policy, you create an
[`AuthorizationPolicy` resource](/docs/reference/config/authorization/authorization-policy/).
[`AuthorizationPolicy` resource](/docs/reference/config/security/authorization-policy/).
An authorization policy includes a selector and a list of rules. The selector
specifies the **target** that the policy applies to, while the rules specify **who**
@ -810,7 +810,7 @@ spec:
{{< /text >}}
The supported `key` values of a condition are listed in the
[conditions page](/docs/reference/config/authorization/conditions/).
[conditions page](/docs/reference/config/security/conditions/).
#### Authenticated and unauthenticated identity
@ -867,7 +867,7 @@ These fields include:
- The `request_principals` field in the source section of the authorization policy object
- The `hosts`, `methods` and `paths` fields in the operation section of the authorization policy object
The supported conditions are listed in the [conditions page](/docs/reference/config/authorization/conditions/).
The supported conditions are listed in the [conditions page](/docs/reference/config/security/conditions/).
If you use any HTTP only fields for a TCP workload, Istio will ignore HTTP only fields in the
authorization policy.

2
content/en/docs/reference/config/analysis/_index.md
View File

@ -1,7 +1,7 @@
---
title: Configuration Analysis Messages
description: Documents the individual error and warning messages produced during configurarion analysis.
weight: 40
weight: 70
layout: analysis-landing
---

5
content/en/docs/reference/config/authorization/_index.md
View File

@ -1,5 +0,0 @@
---
title: Authorization
description: Describes how to configure Istio's authorization features.
weight: 30
---

6
content/en/docs/reference/config/installation-options/index.md
View File

@ -1,7 +1,7 @@
---
title: Installation Options
description: Describes the options available when installing Istio using the included Helm chart.
weight: 30
title: Installation Options (Helm)
description: Describes the options available when installing Istio using Helm charts.
weight: 15
keywords: [kubernetes,helm]
force_inline_toc: true
---

3
content/en/docs/reference/config/istio.mesh.v1alpha1/index.html
View File

@ -1,11 +1,12 @@
---
WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE 'https://github.com/istio/api' REPO
source_repo: https://github.com/istio/api
title: Service Mesh
title: Global Mesh Options
description: Configuration affecting the service mesh as a whole.
location: https://istio.io/docs/reference/config/istio.mesh.v1alpha1.html
layout: protoc-gen-docs
generator: protoc-gen-docs
weight: 20
number_of_entries: 26
---
<p>Configuration affecting the service mesh as a whole.</p>

5
content/en/docs/reference/config/istio.operator.v1alpha12.pb/index.html
View File

@ -1,11 +1,12 @@
---
WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL SOURCE IN THE 'https://github.com/istio/operator' REPO
source_repo: https://github.com/istio/operator
title: Operator Installation
description: Configuration for Istio control plane installation through the Operator.
title: Installation Options (istioctl)
description: Configuration options for Istio control plane installation using istioctl.
location: https://istio.io/docs/reference/config/istio.operator.v1alpha12.pb.html
layout: protoc-gen-docs
generator: protoc-gen-docs
weight: 10
number_of_entries: 59
---
<p>IstioControlPlane is a schema for both defining and customizing Istio control plane installations.

2
content/en/docs/reference/config/networking/_index.md
View File

@ -1,7 +1,7 @@
---
title: Traffic Management
description: Describes how to configure HTTP/TCP routing features.
weight: 11
weight: 30
aliases:
- /docs/reference/config/istio.routing.v1alpha1/
- /docs/reference/config/networking/

8
content/en/docs/reference/config/networking/destination-rule/index.html
View File

@ -157,7 +157,7 @@ No
<td><code>http1MaxPendingRequests</code></td>
<td><code>int32</code></td>
<td>
<p>Maximum number of pending HTTP requests to a destination. Default 1024.</p>
<p>Maximum number of pending HTTP requests to a destination. Default 2^32-1.</p>
</td>
<td>
@ -168,7 +168,7 @@ No
<td><code>http2MaxRequests</code></td>
<td><code>int32</code></td>
<td>
<p>Maximum number of requests to a backend. Default 1024.</p>
<p>Maximum number of requests to a backend. Default 2^32-1.</p>
</td>
<td>
@ -193,7 +193,7 @@ No
<td><code>int32</code></td>
<td>
<p>Maximum number of retries that can be outstanding to all hosts in a
cluster at a given time. Defaults to 1024.</p>
cluster at a given time. Defaults to 2^32-1.</p>
</td>
<td>
@ -283,7 +283,7 @@ This opt-in option overrides the default.</p>
<td><code>maxConnections</code></td>
<td><code>int32</code></td>
<td>
<p>Maximum number of HTTP1 /TCP connections to a destination host. Default 1024.</p>
<p>Maximum number of HTTP1 /TCP connections to a destination host. Default 2^32-1.</p>
</td>
<td>

2
content/en/docs/reference/config/policy-and-telemetry/_index.md
View File

@ -1,7 +1,7 @@
---
title: Policies and Telemetry
description: Describes how to configure Istio's policy and telemetry features.
weight: 30
weight: 50
aliases:
- /docs/reference/config/mixer/index.html
---

5
content/en/docs/reference/config/security/_index.md Normal file
View File

@ -0,0 +1,5 @@
---
title: Security
description: Describes how to configure Istio's security features.
weight: 40
---

4
content/en/docs/reference/config/authorization/authorization-policy/index.html → content/en/docs/reference/config/security/authorization-policy/index.html
View File

@ -3,9 +3,11 @@ WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL
source_repo: https://github.com/istio/api
title: Authorization Policy
description: Configuration for access control on workloads.
location: https://istio.io/docs/reference/config/authorization/authorization-policy.html
location: https://istio.io/docs/reference/config/security/authorization-policy.html
layout: protoc-gen-docs
generator: protoc-gen-docs
weight: 20
aliases: [/docs/reference/config/authorization/authorization-policy.html]
number_of_entries: 8
---
<p>Istio Authorization Policy enables access control on workloads in the mesh.</p>

8
content/en/docs/reference/config/authorization/conditions/index.md → content/en/docs/reference/config/security/conditions/index.md
View File

@ -1,11 +1,13 @@
---
title: Conditions
title: Authorization Policy Conditions
description: Describes the supported conditions in authorization policies.
weight: 10
weight: 30
aliases:
- /docs/reference/config/security/conditions/
---
This page describes the supported keys and value formats you can use as conditions
in the `when` field of [authorization policy resources](/docs/reference/config/authorization/authorization-policy/).
in the `when` field of [authorization policy resources](/docs/reference/config/security/authorization-policy/).
{{< warning >}}
Unsupported keys and values are silently ignored.

6
content/en/docs/reference/config/authorization/constraints-and-properties/index.md → content/en/docs/reference/config/security/constraints-and-properties/index.md
View File

@ -1,7 +1,9 @@
---
title: Constraints and Properties (deprecated)
title: RBAC Constraints and Properties (deprecated)
description: Describes the supported constraints and properties.
weight: 10
weight: 50
aliases:
- /docs/reference/config/security/constraints-and-properties/
---
{{< warning >}}

5
content/en/docs/reference/config/istio.authentication.v1alpha1/index.html → content/en/docs/reference/config/security/istio.authentication.v1alpha1/index.html
View File

@ -3,10 +3,11 @@ WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL
source_repo: https://github.com/istio/api
title: Authentication Policy
description: Authentication policy for Istio services.
location: https://istio.io/docs/reference/config/istio.authentication.v1alpha1.html
location: https://istio.io/docs/reference/config/security/istio.authentication.v1alpha1.html
layout: protoc-gen-docs
generator: protoc-gen-docs
weight: 29
weight: 10
aliases: [/docs/reference/config/istio.authentication.v1alpha1.html]
number_of_entries: 11
---
<p>This package defines user-facing authentication policy.</p>

4
content/en/docs/reference/config/authorization/istio.rbac.v1alpha1/index.html → content/en/docs/reference/config/security/istio.rbac.v1alpha1/index.html
View File

@ -3,9 +3,11 @@ WARNING: THIS IS AN AUTO-GENERATED FILE, DO NOT EDIT. PLEASE MODIFY THE ORIGINAL
source_repo: https://github.com/istio/api
title: RBAC (deprecated)
description: Configuration for Role Based Access Control.
location: https://istio.io/docs/reference/config/authorization/istio.rbac.v1alpha1.html
location: https://istio.io/docs/reference/config/security/istio.rbac.v1alpha1.html
layout: protoc-gen-docs
generator: protoc-gen-docs
weight: 40
aliases: [/docs/reference/config/authorization/istio.rbac.v1alpha1.html]
number_of_entries: 9
---
<p>Note: The v1alpha1 RBAC policy is deprecated by the v1beta1 Authorization policy.

2
content/en/docs/tasks/security/authentication/authn-policy/index.md
View File

@ -106,7 +106,7 @@ EOF
{{< /text >}}
{{< tip >}}
The mesh authentication policy uses the [regular authentication policy API](/docs/reference/config/istio.authentication.v1alpha1/)
The mesh authentication policy uses the [regular authentication policy API](/docs/reference/config/security/istio.authentication.v1alpha1/)
it is defined in the cluster-scoped `MeshPolicy` CRD.
{{< /tip >}}

2
content/en/news/2019/announcing-1.2/change-notes/index.md
View File

@ -42,7 +42,7 @@ aliases:
## Policy
- **Fixed** [Mixer based](https://github.com/istio/istio/issues/13868)TCP Policy enforcement.
- **Graduated** [Authorization (RBAC)](/docs/reference/config/authorization/istio.rbac.v1alpha1/) from Alpha to Alpha API and Beta runtime.
- **Graduated** [Authorization (RBAC)](/docs/reference/config/security/istio.rbac.v1alpha1/) from Alpha to Alpha API and Beta runtime.
## Configuration management

2
content/en/news/2019/announcing-1.4/change-notes/index.md
View File

@ -15,7 +15,7 @@ weight: 10
## Security
- **Added** the [`v1beta1` authorization policy model](/docs/concepts/security#authorization) for enforcing access control. This will eventually replace the [`v1alpha1` RBAC policy](/docs/reference/config/authorization/istio.rbac.v1alpha1/).
- **Added** the [`v1beta1` authorization policy model](/docs/concepts/security#authorization) for enforcing access control. This will eventually replace the [`v1alpha1` RBAC policy](/docs/reference/config/security/istio.rbac.v1alpha1/).
- **Improved** Citadel to periodically check and rotate the expired root certificate when running in self-sign CA mode.
## Telemetry

4
content/zh/blog/2018/istio-authorization/index.md
View File

@ -18,7 +18,7 @@ provides micro-segmentation for services in an Istio mesh. It features:
* High performance, as it is enforced natively on Envoy.
* Role-based semantics, which makes it easy to use.
* High flexibility as it allows users to define conditions using
[combinations of attributes](/docs/reference/config/authorization/constraints-and-properties/).
[combinations of attributes](/docs/reference/config/security/constraints-and-properties/).
In this blog post, you'll learn about the main authorization features and how to use them in different situations.
@ -49,7 +49,7 @@ frontend service.
duplicate configurations in multiple places and later forget to update some of them when you need to make changes.
On the other hand, Istio's authorization system is not a traditional RBAC system. It also allows users to define **conditions** using
[combinations of attributes](/docs/reference/config/authorization/constraints-and-properties/). This gives Istio
[combinations of attributes](/docs/reference/config/security/constraints-and-properties/). This gives Istio
flexibility to express complex access control policies. In fact, **the "RBAC + conditions” model
that Istio authorization adopts, has all the benefits an RBAC system has, and supports the level of flexibility that
normally an ABAC system provides.** You'll see some [examples](#examples) below.

2
content/zh/blog/2019/performance-best-practices/index.md
View File

@ -33,7 +33,7 @@ Say you run 2,000 Envoy-injected pods, each handling 1,000 requests per second.
It is also important to focus on data plane performance for **latency** reasons. This is because most application requests move through the Istio data plane, not the control plane. There are two exceptions:
1. **Telemetry reporting:** Each proxy sends raw telemetry data to {{<gloss>}}Mixer{{</gloss>}}, which Mixer processes into metrics, traces, and other telemetry. The raw telemetry data is similar to access logs, and therefore comes at a cost. Access log processing consumes CPU and keeps a worker thread from picking up the next unit of work. At higher throughput, it is more likely that the next unit of work is waiting in the queue to be picked up by the worker. This can lead to long-tail (99th percentile) latency for Envoy.
1. **Custom policy checks:** When using [custom Istio policy adapters](/docs/concepts/observability/), policy checks are on the request path. This means that request headers and metadata on the data path will be sent to the control plane (Mixer), resulting in higher request latency. **Note:** These policy checks are [disabled by default](/docs/reference/config/installation-options/#global-options), as the most common policy use case ([RBAC](/docs/reference/config/authorization/istio.rbac.v1alpha1)) is performed entirely by the Envoy proxies.
1. **Custom policy checks:** When using [custom Istio policy adapters](/docs/concepts/observability/), policy checks are on the request path. This means that request headers and metadata on the data path will be sent to the control plane (Mixer), resulting in higher request latency. **Note:** These policy checks are [disabled by default](/docs/reference/config/installation-options/#global-options), as the most common policy use case ([RBAC](/docs/reference/config/security/istio.rbac.v1alpha1)) is performed entirely by the Envoy proxies.
Both of these exceptions will go away in a future Istio release, when [Mixer V2](https://docs.google.com/document/d/1QKmtem5jU_2F3Lh5SqLp0IuPb80_70J7aJEYu4_gS-s) moves all policy and telemetry features directly into the proxies.

2
content/zh/docs/tasks/security/authn-policy/index.md
View File

@ -105,7 +105,7 @@ EOF
{{< /text >}}
{{< tip >}}
The mesh authentication policy uses the [regular authentication policy API](/docs/reference/config/istio.authentication.v1alpha1/)
The mesh authentication policy uses the [regular authentication policy API](/docs/reference/config/security/istio.authentication.v1alpha1/)
it is defined in the cluster-scoped `MeshPolicy` CRD.
{{< /tip >}}

2
content/zh/news/2019/announcing-1.2/change-notes/index.md
View File

@ -42,7 +42,7 @@ aliases:
## Policy
- **Fixed** [Mixer based](https://github.com/istio/istio/issues/13868)TCP Policy enforcement.
- **Graduated** [Authorization (RBAC)](/docs/reference/config/authorization/istio.rbac.v1alpha1/) from Alpha to Alpha API and Beta runtime.
- **Graduated** [Authorization (RBAC)](/docs/reference/config/security/istio.rbac.v1alpha1/) from Alpha to Alpha API and Beta runtime.
## Configuration management