mirror of https://github.com/istio/istio.io.git
Consolidate the security concept pages into a single page. (#1721)
* Consolidate the security concept pages into a single page. - This updates the security concept material to be on a single page, which matches the change done last week for the rest of the concept material. This ends up being a less clicky more directed introduction for newcomers to the platform. - While I was there, I moved the redundant What is Istio page from our about section and stuck the content at the top of the What is Istio page in the Concepts section.
This commit is contained in:
Martin Taillefer
GitHub
parent
880ffebba2
commit
181605b27e
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Join Our Community
|
||||
description: Information on the various ways to participate and interact with the Istio community.
|
||||
weight: 2
|
||||
weight: 90
|
||||
keywords: [community]
|
||||
type: community
|
||||
aliases:
|
||||
|
|
|
|||
|
|
@ -70,13 +70,13 @@ Below is our list of existing features and their current phases. This informatio
|
|||
|-------------------|-------------------
|
||||
| [Deny Checker](/docs/reference/config/policy-and-telemetry/adapters/denier/) | Stable
|
||||
| [List Checker](/docs/reference/config/policy-and-telemetry/adapters/list/) | Stable
|
||||
| [Kubernetes: Service Credential Distribution](/docs/concepts/security/mutual-tls/) | Stable
|
||||
| [Kubernetes: Service Credential Distribution](/docs/concepts/security/#mutual-tls-authentication) | Stable
|
||||
| [Pluggable Key/Cert Support for Istio CA](/docs/tasks/security/plugin-ca-cert/) | Stable
|
||||
| [Service-to-service mutual TLS](/docs/concepts/security/mutual-tls/) | Stable
|
||||
| [Authentication policy](/docs/concepts/security/authn-policy/) | Alpha
|
||||
| [VM: Service Credential Distribution](/docs/concepts/security/mutual-tls/) | Beta
|
||||
| [Service-to-service mutual TLS](/docs/concepts/security/#mutual-tls-authentication) | Stable
|
||||
| [Authentication policy](/docs/concepts/security/#authentication-policy) | Alpha
|
||||
| [VM: Service Credential Distribution](/docs/concepts/security/#key-management) | Beta
|
||||
| [OPA Checker]({{< github_file >}}/mixer/adapter/opa/README.md) | Alpha
|
||||
| [RBAC Mixer Adapter](/docs/concepts/security/rbac/) | Alpha
|
||||
| [RBAC Mixer Adapter](/docs/concepts/security/#role-based-access-control-rbac) | Alpha
|
||||
|
||||
### Core
|
||||
|
||||
|
|
|
|||
|
|
@ -1,30 +0,0 @@
|
|||
---
|
||||
title: What is Istio?
|
||||
description: Context about what problems Istio is designed to solve.
|
||||
weight: 1
|
||||
---
|
||||
|
||||
Istio is an open platform that provides a uniform way to connect, manage,
|
||||
and secure microservices. Istio supports managing traffic flows between
|
||||
microservices, enforcing access policies, and aggregating telemetry data,
|
||||
all without requiring changes to the microservice code. Istio gives you:
|
||||
|
||||
- Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.
|
||||
|
||||
- Fine-grained control of traffic behavior with rich routing rules,
|
||||
retries, failovers, and fault injection.
|
||||
|
||||
- A pluggable policy layer and configuration API supporting access controls,
|
||||
rate limits and quotas.
|
||||
|
||||
- Automatic metrics, logs, and traces for all traffic within a cluster,
|
||||
including cluster ingress and egress.
|
||||
|
||||
- Secure service-to-service communication in a cluster with strong
|
||||
identity-based authentication and authorization.
|
||||
|
||||
Istio can be deployed on [Kubernetes](https://kubernetes.io),
|
||||
[Nomad](https://nomadproject.io) with [Consul](https://www.consul.io/). We
|
||||
plan to add support for additional platforms such as
|
||||
[Cloud Foundry](https://www.cloudfoundry.org/),
|
||||
and [Apache Mesos](https://mesos.apache.org/) in the near future.
|
||||
|
|
@ -27,7 +27,7 @@ therefore doesn't work on older versions. The alpha initializer mechanism is no
|
|||
providing a flexible fine-grained access control mechanism. [Learn more](https://docs.google.com/document/d/1U2XFmah7tYdmC5lWkk3D43VMAAQ0xkBatKmohf90ICA/edit#heading=h.fmlgl8m03gfy)
|
||||
|
||||
- **Istio RBAC**. Mixer now has a role-based access control adapter.
|
||||
[Learn more](/docs/concepts/security/rbac/)
|
||||
[Learn more](/docs/concepts/security/#role-based-access-control-rbac)
|
||||
|
||||
- **Fluentd**. Mixer now has an adapter for log collection through [fluentd](https://www.fluentd.org).
|
||||
[Learn more](/docs/tasks/telemetry/fluentd/)
|
||||
|
|
@ -43,7 +43,7 @@ of controls.
|
|||
- **PKCS8**. Add support for PKCS8 keys to Istio PKI.
|
||||
|
||||
- **Istio RBAC** Istio RBAC provides access control for services in Istio mesh.
|
||||
[Learn more](/docs/concepts/security/rbac/).
|
||||
[Learn more](/docs/concepts/security/#role-based-access-control-rbac).
|
||||
|
||||
## Other
|
||||
|
||||
|
|
|
|||
|
|
@ -18,9 +18,9 @@ In this blog post, I modify the [Istio Bookinfo Sample Application](/docs/exampl
|
|||
|
||||
To demonstrate the scenario of consuming an external web service, I start with a Kubernetes cluster with [Istio installed](/docs/setup/kubernetes/quick-start/#installation-steps). Then I deploy [Istio Bookinfo Sample Application](/docs/examples/bookinfo/). This application uses the _details_ microservice to fetch book details, such as the number of pages and the publisher. The original _details_ microservice provides the book details without consulting any external service.
|
||||
|
||||
The example commands in this blog post work with Istio 0.2+, with or without [Mutual TLS](/docs/concepts/security/mutual-tls/) enabled.
|
||||
The example commands in this blog post work with Istio 0.2+, with or without [mutual TLS](/docs/concepts/security/#mutual-tls-authentication) enabled.
|
||||
|
||||
The Bookinfo configuration files required for the scenario of this post appear starting from [Istio release version 0.5](https://github.com/istio/istio/releases/tag/0.5.0).
|
||||
The Bookinfo configuration files required for the scenario of this post appear starting from [Istio 0.5](https://github.com/istio/istio/releases/tag/0.5.0).
|
||||
The Bookinfo configuration files reside in the `samples/bookinfo/kube` directory of the Istio release archive.
|
||||
|
||||
Here is a copy of the end-to-end architecture of the application from the original [Bookinfo sample application](/docs/examples/bookinfo/).
|
||||
|
|
@ -169,7 +169,7 @@ env:
|
|||
|
||||
#### Relation to Istio mutual TLS
|
||||
|
||||
Note that the TLS origination in this case is unrelated to [the mutual TLS](/docs/concepts/security/mutual-tls/) applied by Istio. The TLS origination for the external services will work, whether the Istio mutual TLS is enabled or not. The **mutual** TLS secures service-to-service communication **inside** the service mesh and provides each service with a strong identity. In the case of the **external services**, we have **one-way** TLS, the same mechanism used to secure communication between a web browser and a web server. TLS is applied to the communication with external services to verify the identity of the external server and to encrypt the traffic.
|
||||
Note that the TLS origination in this case is unrelated to [the mutual TLS](/docs/concepts/security/#mutual-tls-authentication) applied by Istio. The TLS origination for the external services will work, whether the Istio mutual TLS is enabled or not. The **mutual** TLS secures service-to-service communication **inside** the service mesh and provides each service with a strong identity. In the case of the **external services**, we have **one-way** TLS, the same mechanism used to secure communication between a web browser and a web server. TLS is applied to the communication with external services to verify the identity of the external server and to encrypt the traffic.
|
||||
|
||||
### Malicious microservices threat
|
||||
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ Now I am ready to deploy a version of the Bookinfo application that will use my
|
|||
|
||||
To demonstrate the scenario of using an external database, I start with a Kubernetes cluster with [Istio installed](/docs/setup/kubernetes/quick-start/#installation-steps). Then I deploy the [Istio Bookinfo sample application](/docs/examples/bookinfo/). This application uses the _ratings_ microservice to fetch book ratings, a number between 1 and 5. The ratings are displayed as stars for each review. There are several versions of the _ratings_ microservice. Some use [MongoDB](https://www.mongodb.com), others use [MySQL](https://www.mysql.com) as their database.
|
||||
|
||||
The example commands in this blog post work with Istio 0.3+, with or without [Mutual TLS](/docs/concepts/security/mutual-tls/) enabled.
|
||||
The example commands in this blog post work with Istio 0.3+, with or without [mutual TLS](/docs/concepts/security/#mutual-tls-authentication) enabled.
|
||||
|
||||
As a reminder, here is the end-to-end architecture of the application from the [Bookinfo sample application](/docs/examples/bookinfo/).
|
||||
|
||||
|
|
@ -261,7 +261,7 @@ Also note that the IPs of an external service are not always static, for example
|
|||
Note that the scenario described in this post is different from the mesh expansion scenario, described in the
|
||||
[Integrating Virtual Machines](/docs/examples/integrating-vms/) example. In that scenario, a MySQL instance runs on an external
|
||||
(outside the cluster) machine (a bare metal or a VM), integrated with the Istio service mesh. The MySQL service becomes a first-class citizen of the mesh with all the beneficial features of Istio applicable. Among other things, the service becomes addressable by a local cluster domain name, for example by `mysqldb.vm.svc.cluster.local`, and the communication to it can be secured by
|
||||
[mutual TLS authentication](/docs/concepts/security/mutual-tls/). There is no need to create an egress rule to access this service; however, the
|
||||
[mutual TLS authentication](/docs/concepts/security/#mutual-tls-authentication). There is no need to create an egress rule to access this service; however, the
|
||||
service must be registered with Istio. To enable such integration, Istio components (_Envoy proxy_, _node-agent_, _istio-agent_) must be
|
||||
installed on the machine and the Istio control plane (_Pilot_, _Mixer_, _CA_) must be accessible from it. See the
|
||||
[Istio Mesh Expansion](/docs/setup/kubernetes/mesh-expansion/) instructions for more details.
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 81 KiB After Width: | Height: | Size: 81 KiB |
|
|
@ -1,6 +0,0 @@
|
|||
---
|
||||
title: Security
|
||||
description: Describes Istio's authorization and authentication functionality.
|
||||
weight: 30
|
||||
type: section-index
|
||||
---
|
||||
|
Before Width: | Height: | Size: 178 KiB After Width: | Height: | Size: 178 KiB |
|
|
@ -1,87 +0,0 @@
|
|||
---
|
||||
title: Authentication Policy
|
||||
description: Describes Istio's authentication policy
|
||||
weight: 10
|
||||
keywords: [security,authentication]
|
||||
aliases:
|
||||
- /docs/concepts/network-and-auth/auth.html
|
||||
---
|
||||
|
||||
Istio authentication policy enables operators to specify authentication requirements for a service (or services). Istio authentication policy is composed of two parts:
|
||||
|
||||
* Peer: verifies the party, the direct client, that makes the connection. The common authentication mechanism for this is [mutual TLS](/docs/concepts/security/mutual-tls/).
|
||||
|
||||
* Origin: verifies the party, the original client, that makes the request (e.g end-users, devices etc). JWT is the only supported mechanism for origin authentication at the moment.
|
||||
|
||||
Istio configures the server side to perform authentication, however, it does not enforce the policy on the client side. For mutual TLS authentication, users can use [destination rules](/docs/concepts/traffic-management/#destination-rules) to configure client side to follow the expected protocol. For other cases, the application is responsible to acquire and attach the credential (e.g JWT) to the request.
|
||||
|
||||
Identities from both authentication parts, if applicable, are output to the next layer (e.g authorization, Mixer). To simplify the authorization rules, the policy can also specify which identity (peer or origin) should be used as 'the principal'. By default, it is set to the peer's identity.
|
||||
|
||||
## Architecture
|
||||
|
||||
Authentication policies are saved in Istio config store (in 0.7, the storage implementation uses Kubernetes CRD), and distributed by control plane. Depending on the size of the mesh, config propagation may take a few seconds to a few minutes. During the transition, you can expect traffic lost or inconsistent authentication results.
|
||||
|
||||
{{< image width="80%" ratio="75%"
|
||||
link="./authn.svg"
|
||||
caption="Authentication Policy Architecture"
|
||||
>}}
|
||||
|
||||
Policy is scoped to namespaces, with (optional) target selector rules to narrow down the set of services (within the same namespace as the policy) on which the policy should be applied. This aligns with the ACL model based on Kubernetes RBAC. More specifically, only the admin of the namespace can set policies for services in that namespace.
|
||||
|
||||
Authentication is implemented by the Istio sidecars. For example, with an Envoy sidecar, it is a combination of SSL setting and HTTP filters. If authentication fails, requests will be rejected (either with SSL handshake error code, or http 401, depending on the type of authentication mechanism). If authentication succeeds, the following authenticated attributes will be generated:
|
||||
|
||||
* **source.principal**: peer principal. If peer authentication is not used, the attribute is not set.
|
||||
* **request.auth.principal**: depends on the policy principal binding, this could be peer principal (if USE_PEER) or origin principal (if USE_ORIGIN).
|
||||
* **request.auth.audiences**: reflect the audience (`aud`) claim within the origin JWT (JWT that is used for origin authentication)
|
||||
* **request.auth.presenter**: similarly, reflect the authorized presenter (`azp`) claim of the origin JWT.
|
||||
* **request.auth.claims**: all raw string claims from origin-JWT.
|
||||
|
||||
Origin principal (principal from origin authentication) is not explicitly output. In general, it can always be reconstructed by joining (`iss`) and subject (`sub`) claims with a "/" separator (for example, if `iss` and `sub` claims are "*googleapis.com*" and "*123456*" respectively, then origin principal is "*googleapis.com/123456*"). On the other hand, if principal binding is USE_ORIGIN, **request.auth.principal** carries the same value as origin principal.
|
||||
|
||||
## Anatomy of a policy
|
||||
|
||||
### Target selectors
|
||||
|
||||
Defines rules to find service(s) on which policy should be applied. If no rule is provided, the policy is matched to all services in the same namespace of the policy, so-called namespace-level policy (as opposed to service-level policies which have non-empty selector rules). Istio uses the service-level policy if available, otherwise it falls back to namespace-level policy. If neither is defined, it uses the default policy based on service mesh config and/or service annotation, which can only set mutual TLS setting (these are mechanisms before Istio 0.7 to configure mutual TLS for Istio service mesh). See [testing Istio mutual TLS](/docs/tasks/security/mutual-tls/).
|
||||
|
||||
> Starting with 0.8, authentication policy is the recommended way to enable/disable mutual TLS per service. The option to use service annotation will be removed in a future release.
|
||||
|
||||
Operators are responsible for avoiding conflicts, e.g create more than one service-level policy that matches to the same service(s) (or more than one namespace-level policy on the same namespace).
|
||||
|
||||
Example: rule to select product-page service (on any port), and reviews:9000.
|
||||
|
||||
{{< text yaml >}}
|
||||
targets:
|
||||
- name: product-page
|
||||
- name: reviews
|
||||
ports:
|
||||
- number: 9000
|
||||
{{< /text >}}
|
||||
|
||||
### Peer authentication
|
||||
|
||||
Defines authentication methods (and associated parameters) that are supported for peer authentication. It can list more than one method; only one of them needs to be satisfied for the authentication to pass. However, starting with the 0.7 release, only mutual TLS is supported. Omit this if peer authentication is not needed.
|
||||
|
||||
Example of peer authentication using mutual TLS:
|
||||
|
||||
{{< text yaml >}}
|
||||
peers:
|
||||
- mtls:
|
||||
{{< /text >}}
|
||||
|
||||
> Starting with Istio 0.7, the `mtls` settings doesn't require any parameters (hence `-mtls: {}`, `- mtls:` or `- mtls: null` declaration is sufficient). In future, it may carry arguments to provide different mutual TLS implementations.
|
||||
|
||||
### Origin authentication
|
||||
|
||||
Defines authentication methods (and associated parameters) that are supported for origin authentication. Only JWT is supported for this, however, the policy can list multiple JWTs by different issuers. Similar to peer authentication, only one of the listed methods needs to be satisfied for the authentication to pass.
|
||||
|
||||
{{< text yaml >}}
|
||||
origins:
|
||||
- jwt:
|
||||
issuer: "https://accounts.google.com"
|
||||
jwksUri: "https://www.googleapis.com/oauth2/v3/certs"
|
||||
{{< /text >}}
|
||||
|
||||
### Principal binding
|
||||
|
||||
Defines what is the principal from the authentication. By default, this will be the peer's principal (and if peer authentication is not applied, it will be left unset). Policy writers can choose to overwrite it with USE_ORIGIN. In future, we will also support *conditional-binding* (e.g USE_PEER when peer is X, otherwise USE_ORIGIN)
|
||||
|
Before Width: | Height: | Size: 169 KiB After Width: | Height: | Size: 169 KiB |
|
|
@ -0,0 +1,463 @@
|
|||
---
|
||||
title: Security
|
||||
description: Describes Istio's authorization and authentication functionality.
|
||||
weight: 30
|
||||
keywords: [security,authentication,authorization,rbac,access-control]
|
||||
aliases:
|
||||
- /docs/concepts/network-and-auth/auth.html
|
||||
- /docs/concepts/security/authn-policy/
|
||||
- /docs/concepts/security/mutual-tls/
|
||||
- /docs/concepts/security/rbac/
|
||||
---
|
||||
|
||||
Istio aims to enhance the security of microservices and their communication without requiring service code changes. It is responsible for:
|
||||
|
||||
* Providing each service with a strong identity that represents its role to enable interoperability across clusters and clouds
|
||||
|
||||
* Securing service to service communication and end-user to service communication
|
||||
|
||||
* Providing a key management system to automate key and certificate generation, distribution, rotation, and revocation
|
||||
|
||||
The diagram below shows Istio's security-related architecture, which includes three primary components: identity, key management, and communication
|
||||
security. This diagram describes how Istio is used to secure the service-to-service communication between service 'frontend' running
|
||||
as the service account 'frontend-team' and service 'backend' running as the service account 'backend-team'. Istio supports services running
|
||||
on both Kubernetes containers and VM/bare-metal machines.
|
||||
|
||||
{{< image width="80%" ratio="56.25%"
|
||||
link="./auth.svg"
|
||||
alt="Components making up the Istio security model."
|
||||
caption="Istio Security Architecture"
|
||||
>}}
|
||||
|
||||
As illustrated in the diagram, Istio leverages secret volume mount to deliver keys/certs from Citadel to Kubernetes containers. For services running on
|
||||
VM/bare-metal machines, we introduce a node agent, which is a process running on each VM/bare-metal machine. It generates the private key and CSR (certificate
|
||||
signing request) locally, sends CSR to Citadel for signing, and delivers the generated certificate together with the private key to Envoy.
|
||||
|
||||
## Mutual TLS Authentication
|
||||
|
||||
### Identity
|
||||
|
||||
Istio uses [Kubernetes service accounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) to identify who runs the service:
|
||||
|
||||
* A service account in Istio has the format "spiffe://\<_domain_\>/ns/\<_namespace_>/sa/\<_serviceaccount_\>".
|
||||
|
||||
* _domain_ is currently _cluster.local_. We will support customization of domain in the near future.
|
||||
* _namespace_ is the namespace of the Kubernetes service account.
|
||||
* _serviceaccount_ is the Kubernetes service account name.
|
||||
|
||||
* A service account is **the identity (or role) a workload runs as**, which represents that workload's privileges. For systems requiring strong security, the
|
||||
amount of privilege for a workload should not be identified by a random string (i.e., service name, label, etc), or by the binary that is deployed.
|
||||
|
||||
* For example, let's say we have a workload pulling data from a multi-tenant database. If Alice ran this workload, she will be able to pull
|
||||
a different set of data than if Bob ran this workload.
|
||||
|
||||
* Service accounts enable strong security policies by offering the flexibility to identify a machine, a user, a workload, or a group of workloads (different
|
||||
workloads can run as the same service account).
|
||||
|
||||
* The service account a workload runs as won't change during the lifetime of the workload.
|
||||
|
||||
* Service account uniqueness can be ensured with domain name constraint
|
||||
|
||||
### Communication security
|
||||
|
||||
Service-to-service communication is tunneled through the client side [Envoy](https://envoyproxy.github.io/envoy/) and the server side Envoy. End-to-end communication is secured by:
|
||||
|
||||
* Local TCP connections between the service and Envoy
|
||||
|
||||
* Mutual TLS connections between proxies
|
||||
|
||||
* Secure Naming: during the handshake process, the client side Envoy checks that the service account provided by the server side certificate is allowed to run the target service
|
||||
|
||||
### Key management
|
||||
|
||||
Istio supports services running on both Kubernetes pods and VM/bare-metal machines. We use different key provisioning mechanisms for each scenario.
|
||||
|
||||
For services running on Kubernetes pods, the per-cluster Citadel (acting as Certificate Authority) automates the key & certificate management process. It mainly performs four critical operations:
|
||||
|
||||
* Generate a [SPIFFE](https://spiffe.github.io/docs/svid) key and certificate pair for each service account
|
||||
|
||||
* Distribute a key and certificate pair to each pod according to the service account
|
||||
|
||||
* Rotate keys and certificates periodically
|
||||
|
||||
* Revoke a specific key and certificate pair when necessary
|
||||
|
||||
For services running on VM/bare-metal machines, the above four operations are performed by Citadel together with node agents.
|
||||
|
||||
### Workflow
|
||||
|
||||
The Istio security workflow consists of two phases, deployment and runtime. For the deployment phase, we discuss the two
|
||||
scenarios (i.e., in Kubernetes and VM/bare-metal machines) separately since they are different. Once the key and
|
||||
certificate are deployed, the runtime phase is the same for the two scenarios. We briefly cover the workflow in this
|
||||
section.
|
||||
|
||||
#### Deployment phase (Kubernetes Scenario)
|
||||
|
||||
1. Citadel watches the Kubernetes API Server, creates a [SPIFFE](https://spiffe.github.io/docs/svid) key and certificate
|
||||
pair for each of the existing and new service accounts, and sends them to the API Server.
|
||||
|
||||
1. When a pod is created, API Server mounts the key and certificate pair according to the service account using [Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/).
|
||||
|
||||
1. [Pilot](/docs/concepts/traffic-management/#pilot-and-envoy) generates the config with proper key and certificate and secure naming information,
|
||||
which defines what service account(s) can run a certain service, and passes it to Envoy.
|
||||
|
||||
#### Deployment phase (VM/bare-metal Machines Scenario)
|
||||
|
||||
1. Citadel creates a gRPC service to take CSR request.
|
||||
|
||||
1. Node agent creates the private key and CSR, sends the CSR to Citadel for signing.
|
||||
|
||||
1. Citadel validates the credentials carried in the CSR, and signs the CSR to generate the certificate.
|
||||
|
||||
1. Node agent puts the certificate received from Citadel and the private key to Envoy.
|
||||
|
||||
1. The above CSR process repeats periodically for rotation.
|
||||
|
||||
#### Runtime phase
|
||||
|
||||
1. The outbound traffic from a client service is rerouted to its local Envoy.
|
||||
|
||||
1. The client side Envoy starts a mutual TLS handshake with the server side Envoy. During the handshake, it also does a secure naming check to verify that the service account presented in the server certificate can run the server service.
|
||||
|
||||
1. The traffic is forwarded to the server side Envoy after a mutual TLS connection is established, which is then forwarded to the server service through local TCP connections.
|
||||
|
||||
### Best practices
|
||||
|
||||
In this section, we provide a few deployment guidelines and then discuss a real-world scenario.
|
||||
|
||||
#### Deployment guidelines
|
||||
|
||||
* If there are multiple service operators (a.k.a. [SREs](https://en.wikipedia.org/wiki/Site_reliability_engineering)) deploying different services in a cluster (typically in a medium- or large-size cluster), we recommend creating a separate [namespace](https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/) for each SRE team to isolate their access. For example, you could create a "team1-ns" namespace for team1, and "team2-ns" namespace for team2, such that both teams won't be able to access each other's services.
|
||||
|
||||
* If Citadel is compromised, all its managed keys and certificates in the cluster may be exposed. We *strongly* recommend running Citadel
|
||||
on a dedicated namespace (for example, istio-citadel-ns), which only cluster admins have access to.
|
||||
|
||||
#### Example
|
||||
|
||||
Let's consider a 3-tier application with three services: photo-frontend, photo-backend, and datastore. Photo-frontend and photo-backend services are managed by the photo SRE team while the datastore service is managed by the datastore SRE team. Photo-frontend can access photo-backend, and photo-backend can access datastore. However, photo-frontend cannot access datastore.
|
||||
|
||||
In this scenario, a cluster admin creates 3 namespaces: istio-citadel-ns, photo-ns, and datastore-ns. Admin has access to all namespaces, and each team only has
|
||||
access to its own namespace. The photo SRE team creates 2 service accounts to run photo-frontend and photo-backend respectively in namespace photo-ns. The
|
||||
datastore SRE team creates 1 service account to run the datastore service in namespace datastore-ns. Moreover, we need to enforce the service access control
|
||||
in [Istio Mixer](/docs/concepts/policies-and-telemetry/) such that photo-frontend cannot access datastore.
|
||||
|
||||
In this setup, Citadel is able to provide keys and certificates management for all namespaces, and isolate
|
||||
microservice deployments from each other.
|
||||
|
||||
## Authentication Policy
|
||||
|
||||
Istio authentication policy enables operators to specify authentication requirements for a service (or services). Istio authentication policy is composed of two parts:
|
||||
|
||||
* Peer: verifies the party, the direct client, that makes the connection. The common authentication mechanism for this is [mutual TLS](/docs/concepts/security/#mutual-tls-authentication).
|
||||
|
||||
* Origin: verifies the party, the original client, that makes the request (e.g end-users, devices etc). JWT is the only supported mechanism for origin authentication at the moment.
|
||||
|
||||
Istio configures the server side to perform authentication, however, it does not enforce the policy on the client side. For mutual TLS authentication, users can use [destination rules](/docs/concepts/traffic-management/#destination-rules) to configure client side to follow the expected protocol. For other cases, the application is responsible to acquire and attach the credential (e.g JWT) to the request.
|
||||
|
||||
Identities from both authentication parts, if applicable, are output to the next layer (e.g authorization, Mixer). To simplify the authorization rules, the policy can also specify which identity (peer or origin) should be used as 'the principal'. By default, it is set to the peer's identity.
|
||||
|
||||
Authentication policies are saved in Istio config store (in 0.7, the storage implementation uses Kubernetes CRD), and distributed by control plane. Depending on the size of the mesh, config propagation may take a few seconds to a few minutes. During the transition, you can expect traffic lost or inconsistent authentication results.
|
||||
|
||||
{{< image width="80%" ratio="75%"
|
||||
link="./authn.svg"
|
||||
caption="Authentication Policy Architecture"
|
||||
>}}
|
||||
|
||||
Policy is scoped to namespaces, with (optional) target selector rules to narrow down the set of services (within the same namespace as the policy) on which the policy should be applied. This aligns with the ACL model based on Kubernetes RBAC. More specifically, only the admin of the namespace can set policies for services in that namespace.
|
||||
|
||||
Authentication is implemented by the Istio sidecars. For example, with an Envoy sidecar, it is a combination of SSL setting and HTTP filters. If authentication fails, requests will be rejected (either with SSL handshake error code, or http 401, depending on the type of authentication mechanism). If authentication succeeds, the following authenticated attributes will be generated:
|
||||
|
||||
* **source.principal**: peer principal. If peer authentication is not used, the attribute is not set.
|
||||
* **request.auth.principal**: depends on the policy principal binding, this could be peer principal (if USE_PEER) or origin principal (if USE_ORIGIN).
|
||||
* **request.auth.audiences**: reflect the audience (`aud`) claim within the origin JWT (JWT that is used for origin authentication)
|
||||
* **request.auth.presenter**: similarly, reflect the authorized presenter (`azp`) claim of the origin JWT.
|
||||
* **request.auth.claims**: all raw string claims from origin-JWT.
|
||||
|
||||
Origin principal (principal from origin authentication) is not explicitly output. In general, it can always be reconstructed by joining (`iss`) and subject (`sub`) claims with a "/" separator (for example, if `iss` and `sub` claims are "*googleapis.com*" and "*123456*" respectively, then origin principal is "*googleapis.com/123456*"). On the other hand, if principal binding is USE_ORIGIN, **request.auth.principal** carries the same value as origin principal.
|
||||
|
||||
### Anatomy of a policy
|
||||
|
||||
#### Target selectors
|
||||
|
||||
Defines rules to find service(s) on which policy should be applied. If no rule is provided, the policy is matched to all services in the same namespace of the policy, so-called namespace-level policy (as opposed to service-level policies which have non-empty selector rules). Istio uses the service-level policy if available, otherwise it falls back to namespace-level policy. If neither is defined, it uses the default policy based on service mesh config and/or service annotation, which can only set mutual TLS setting (these are mechanisms before Istio 0.7 to configure mutual TLS for Istio service mesh). See [testing Istio mutual TLS](/docs/tasks/security/mutual-tls/).
|
||||
|
||||
> Starting with 0.8, authentication policy is the recommended way to enable/disable mutual TLS per service. The option to use service annotation will be removed in a future release.
|
||||
|
||||
Operators are responsible for avoiding conflicts, e.g create more than one service-level policy that matches to the same service(s) (or more than one namespace-level policy on the same namespace).
|
||||
|
||||
Example: rule to select product-page service (on any port), and reviews:9000.
|
||||
|
||||
{{< text yaml >}}
|
||||
targets:
|
||||
- name: product-page
|
||||
- name: reviews
|
||||
ports:
|
||||
- number: 9000
|
||||
{{< /text >}}
|
||||
|
||||
#### Peer authentication
|
||||
|
||||
Defines authentication methods (and associated parameters) that are supported for peer authentication. It can list more than one method; only one of them needs to be satisfied for the authentication to pass. However, starting with the 0.7 release, only mutual TLS is supported. Omit this if peer authentication is not needed.
|
||||
|
||||
Example of peer authentication using mutual TLS:
|
||||
|
||||
{{< text yaml >}}
|
||||
peers:
|
||||
- mtls:
|
||||
{{< /text >}}
|
||||
|
||||
> Starting with Istio 0.7, the `mtls` settings doesn't require any parameters (hence `-mtls: {}`, `- mtls:` or `- mtls: null` declaration is sufficient). In future, it may carry arguments to provide different mutual TLS implementations.
|
||||
|
||||
#### Origin authentication
|
||||
|
||||
Defines authentication methods (and associated parameters) that are supported for origin authentication. Only JWT is supported for this, however, the policy can list multiple JWTs by different issuers. Similar to peer authentication, only one of the listed methods needs to be satisfied for the authentication to pass.
|
||||
|
||||
{{< text yaml >}}
|
||||
origins:
|
||||
- jwt:
|
||||
issuer: "https://accounts.google.com"
|
||||
jwksUri: "https://www.googleapis.com/oauth2/v3/certs"
|
||||
{{< /text >}}
|
||||
|
||||
### Principal binding
|
||||
|
||||
Defines what is the principal from the authentication. By default, this will be the peer's principal (and if peer authentication is not applied, it will be left unset). Policy writers can choose to overwrite it with USE_ORIGIN. In future, we will also support *conditional-binding* (e.g USE_PEER when peer is X, otherwise USE_ORIGIN)
|
||||
|
||||
## Role-Based Access Control (RBAC)
|
||||
|
||||
Istio Role-Based Access Control (RBAC) provides namespace-level, service-level, method-level access control for services in the Istio Mesh.
|
||||
It features:
|
||||
|
||||
* Role-Based semantics, which is simple and easy to use.
|
||||
|
||||
* Service-to-service and endUser-to-Service authorization.
|
||||
|
||||
* Flexibility through custom properties support in roles and role-bindings.
|
||||
|
||||
The diagram below shows the Istio RBAC architecture. Operators specify Istio RBAC policies. The policies are saved in
|
||||
the Istio config store.
|
||||
|
||||
{{< image width="80%" ratio="56.25%"
|
||||
link="./IstioRBAC.svg"
|
||||
alt="Istio RBAC"
|
||||
caption="Istio RBAC Architecture"
|
||||
>}}
|
||||
|
||||
The Istio RBAC engine does two things:
|
||||
* **Fetch RBAC policy.** Istio RBAC engine watches for changes on RBAC policy. It fetches the updated RBAC policy if it sees any changes.
|
||||
* **Authorize Requests.** At runtime, when a request comes, the request context is passed to Istio RBAC engine. RBAC engine evaluates the
|
||||
request context against the RBAC policies, and returns the authorization result (ALLOW or DENY).
|
||||
|
||||
### Request context
|
||||
|
||||
In the current release, the Istio RBAC engine is implemented as a [Mixer adapter](/docs/concepts/policies-and-telemetry/#adapters).
|
||||
The request context is provided as an instance of the
|
||||
[authorization template](/docs/reference/config/policy-and-telemetry/templates/authorization/). The request context
|
||||
contains all the information about the request and the environment that an authorization module needs to know. In particular, it has two parts:
|
||||
|
||||
* **subject** contains a list of properties that identify the caller identity, including `"user"` name/ID, `"groups"` the subject belongs to,
|
||||
or any additional properties about the subject such as namespace, service name.
|
||||
* **action** specifies "how a service is accessed". It includes `"namespace"`, `"service"`, `"path"`, `"method"` that the action is being taken on,
|
||||
and any additional properties about the action.
|
||||
|
||||
Below we show an example "requestcontext".
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: authorization
|
||||
metadata:
|
||||
name: requestcontext
|
||||
namespace: istio-system
|
||||
spec:
|
||||
subject:
|
||||
user: source.user | ""
|
||||
groups: ""
|
||||
properties:
|
||||
service: source.service | ""
|
||||
namespace: source.namespace | ""
|
||||
action:
|
||||
namespace: destination.namespace | ""
|
||||
service: destination.service | ""
|
||||
method: request.method | ""
|
||||
path: request.path | ""
|
||||
properties:
|
||||
version: request.headers["version"] | ""
|
||||
{{< /text >}}
|
||||
|
||||
### Istio RBAC policy
|
||||
|
||||
Istio RBAC introduces `ServiceRole` and `ServiceRoleBinding`, both of which are defined as Kubernetes CustomResourceDefinition (CRD) objects.
|
||||
|
||||
* **`ServiceRole`** defines a role for access to services in the mesh.
|
||||
* **`ServiceRoleBinding`** grants a role to subjects (e.g., a user, a group, a service).
|
||||
|
||||
#### `ServiceRole`
|
||||
|
||||
A `ServiceRole` specification includes a list of rules. Each rule has the following standard fields:
|
||||
* **services**: A list of service names, which are matched against the `action.service` field of the "requestcontext".
|
||||
* **methods**: A list of method names which are matched against the `action.method` field of the "requestcontext". In the above "requestcontext",
|
||||
this is the HTTP or gRPC method. Note that gRPC methods are formatted in the form of "packageName.serviceName/methodName" (case sensitive).
|
||||
* **paths**: A list of HTTP paths which are matched against the `action.path` field of the "requestcontext". It is ignored in gRPC case.
|
||||
|
||||
A `ServiceRole` specification only applies to the **namespace** specified in `"metadata"` section. The "services" and "methods" are required
|
||||
fields in a rule. "paths" is optional. If not specified or set to "*", it applies to "any" instance.
|
||||
|
||||
Here is an example of a simple role "service-admin", which has full access to all services in "default" namespace.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: ServiceRole
|
||||
metadata:
|
||||
name: service-admin
|
||||
namespace: default
|
||||
spec:
|
||||
rules:
|
||||
- services: ["*"]
|
||||
methods: ["*"]
|
||||
{{< /text >}}
|
||||
|
||||
Here is another role "products-viewer", which has read ("GET" and "HEAD") access to service "products.default.svc.cluster.local"
|
||||
in "default" namespace.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: ServiceRole
|
||||
metadata:
|
||||
name: products-viewer
|
||||
namespace: default
|
||||
spec:
|
||||
rules:
|
||||
- services: ["products.default.svc.cluster.local"]
|
||||
methods: ["GET", "HEAD"]
|
||||
{{< /text >}}
|
||||
|
||||
In addition, we support **prefix matching** and **suffix matching** for all the fields in a rule. For example, you can define a "tester" role that
|
||||
has the following permissions in "default" namespace:
|
||||
* Full access to all services with prefix "test-" (e.g, "test-bookstore", "test-performance", "test-api.default.svc.cluster.local").
|
||||
* Read ("GET") access to all paths with "/reviews" suffix (e.g, "/books/reviews", "/events/booksale/reviews", "/reviews")
|
||||
in service "bookstore.default.svc.cluster.local".
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: ServiceRole
|
||||
metadata:
|
||||
name: tester
|
||||
namespace: default
|
||||
spec:
|
||||
rules:
|
||||
- services: ["test-*"]
|
||||
methods: ["*"]
|
||||
- services: ["bookstore.default.svc.cluster.local"]
|
||||
paths: ["*/reviews"]
|
||||
methods: ["GET"]
|
||||
{{< /text >}}
|
||||
|
||||
In `ServiceRole`, the combination of "namespace"+"services"+"paths"+"methods" defines "how a service (services) is allowed to be accessed".
|
||||
In some situations, you may need to specify additional constraints that a rule applies to. For example, a rule may only applies to a
|
||||
certain "version" of a service, or only applies to services that are labeled "foo". You can easily specify these constraints using
|
||||
custom fields.
|
||||
|
||||
For example, the following `ServiceRole` definition extends the previous "products-viewer" role by adding a constraint on service "version"
|
||||
being "v1" or "v2". Note that the "version" property is provided by `"action.properties.version"` in "requestcontext".
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: ServiceRole
|
||||
metadata:
|
||||
name: products-viewer-version
|
||||
namespace: default
|
||||
spec:
|
||||
rules:
|
||||
- services: ["products.default.svc.cluster.local"]
|
||||
methods: ["GET", "HEAD"]
|
||||
constraints:
|
||||
- key: "version"
|
||||
values: ["v1", "v2"]
|
||||
{{< /text >}}
|
||||
|
||||
#### `ServiceRoleBinding`
|
||||
|
||||
A `ServiceRoleBinding` specification includes two parts:
|
||||
* **roleRef** refers to a `ServiceRole` resource **in the same namespace**.
|
||||
* A list of **subjects** that are assigned the role.
|
||||
|
||||
A subject can either be a "user", or a "group", or is represented with a set of "properties". Each entry ("user" or "group" or an entry
|
||||
in "properties") must match one of fields ("user" or "groups" or an entry in "properties") in the "subject" part of the "requestcontext"
|
||||
instance.
|
||||
|
||||
Here is an example of `ServiceRoleBinding` resource "test-binding-products", which binds two subjects to ServiceRole "product-viewer":
|
||||
* user "alice@yahoo.com".
|
||||
* "reviews.abc.svc.cluster.local" service in "abc" namespace.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: ServiceRoleBinding
|
||||
metadata:
|
||||
name: test-binding-products
|
||||
namespace: default
|
||||
spec:
|
||||
subjects:
|
||||
- user: "alice@yahoo.com"
|
||||
- properties:
|
||||
service: "reviews.abc.svc.cluster.local"
|
||||
namespace: "abc"
|
||||
roleRef:
|
||||
kind: ServiceRole
|
||||
name: "products-viewer"
|
||||
{{< /text >}}
|
||||
|
||||
In the case that you want to make a service(s) publicly accessible, you can use set the subject to `user: "*"`. This will assign a `ServiceRole`
|
||||
to all users/services.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: ServiceRoleBinding
|
||||
metadata:
|
||||
name: binding-products-allusers
|
||||
namespace: default
|
||||
spec:
|
||||
subjects:
|
||||
- user: "*"
|
||||
roleRef:
|
||||
kind: ServiceRole
|
||||
name: "products-viewer"
|
||||
{{< /text >}}
|
||||
|
||||
### Enabling RBAC
|
||||
|
||||
Istio RBAC can be enabled by adding the following Mixer adapter rule. The rule has two parts. The first part defines a RBAC handler.
|
||||
It has two parameters, `"config_store_url"` and `"cache_duration"`.
|
||||
* The `"config_store_url"` parameter specifies where RBAC engine fetches RBAC policies. The default value for `"config_store_url"` is
|
||||
`"k8s://"`, which means Kubernetes API server. Alternatively, if you are testing RBAC policy locally, you may set it to a local directory
|
||||
such as `"fs:///tmp/testdata/configroot"`.
|
||||
* The `"cache_duration"` parameter specifies the duration for which the authorization results may be cached on Mixer client (i.e., Istio proxy).
|
||||
The default value for `"cache_duration"` is 1 minute.
|
||||
|
||||
The second part defines a rule, which specifies that the RBAC handler should be invoked with the "requestcontext" instance [defined
|
||||
earlier in the document](#request-context).
|
||||
|
||||
In the following example, Istio RBAC is enabled for "default" namespace. And the cache duration is set to 30 seconds.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: rbac
|
||||
metadata:
|
||||
name: handler
|
||||
namespace: istio-system
|
||||
spec:
|
||||
config_store_url: "k8s://"
|
||||
cache_duration: "30s"
|
||||
---
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: rule
|
||||
metadata:
|
||||
name: rbaccheck
|
||||
namespace: istio-system
|
||||
spec:
|
||||
match: destination.namespace == "default"
|
||||
actions:
|
||||
# handler and instance names default to the rule's namespace.
|
||||
- handler: handler.rbac
|
||||
instances:
|
||||
- requestcontext.authorization
|
||||
{{< /text >}}
|
||||
|
|
@ -1,162 +0,0 @@
|
|||
---
|
||||
title: Mutual TLS Authentication
|
||||
description: Describes Istio's mutual TLS authentication architecture which provides a strong service identity and secure communication channels between services.
|
||||
keywords: [security,mutual-tls]
|
||||
weight: 10
|
||||
---
|
||||
|
||||
Istio aims to enhance the security of microservices and their communication without requiring service code changes. It is responsible for:
|
||||
|
||||
* Providing each service with a strong identity that represents its role to enable interoperability across clusters and clouds
|
||||
|
||||
* Securing service to service communication and end-user to service communication
|
||||
|
||||
* Providing a key management system to automate key and certificate generation, distribution, rotation, and revocation
|
||||
|
||||
## Architecture
|
||||
|
||||
The diagram below shows Istio's security-related architecture, which includes three primary components: identity, key management, and communication
|
||||
security. This diagram describes how Istio is used to secure the service-to-service communication between service 'frontend' running
|
||||
as the service account 'frontend-team' and service 'backend' running as the service account 'backend-team'. Istio supports services running
|
||||
on both Kubernetes containers and VM/bare-metal machines.
|
||||
|
||||
{{< image width="80%" ratio="56.25%"
|
||||
link="./auth.svg"
|
||||
alt="Components making up the Istio auth model."
|
||||
caption="Istio Security Architecture"
|
||||
>}}
|
||||
|
||||
As illustrated in the diagram, Istio leverages secret volume mount to deliver keys/certs from Citadel to Kubernetes containers. For services running on
|
||||
VM/bare-metal machines, we introduce a node agent, which is a process running on each VM/bare-metal machine. It generates the private key and CSR (certificate
|
||||
signing request) locally, sends CSR to Citadel for signing, and delivers the generated certificate together with the private key to Envoy.
|
||||
|
||||
## Components
|
||||
|
||||
### Identity
|
||||
|
||||
Istio uses [Kubernetes service accounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) to identify who runs the service:
|
||||
|
||||
* A service account in Istio has the format "spiffe://\<_domain_\>/ns/\<_namespace_>/sa/\<_serviceaccount_\>".
|
||||
|
||||
* _domain_ is currently _cluster.local_. We will support customization of domain in the near future.
|
||||
* _namespace_ is the namespace of the Kubernetes service account.
|
||||
* _serviceaccount_ is the Kubernetes service account name.
|
||||
|
||||
* A service account is **the identity (or role) a workload runs as**, which represents that workload's privileges. For systems requiring strong security, the
|
||||
amount of privilege for a workload should not be identified by a random string (i.e., service name, label, etc), or by the binary that is deployed.
|
||||
|
||||
* For example, let's say we have a workload pulling data from a multi-tenant database. If Alice ran this workload, she will be able to pull
|
||||
a different set of data than if Bob ran this workload.
|
||||
|
||||
* Service accounts enable strong security policies by offering the flexibility to identify a machine, a user, a workload, or a group of workloads (different
|
||||
workloads can run as the same service account).
|
||||
|
||||
* The service account a workload runs as won't change during the lifetime of the workload.
|
||||
|
||||
* Service account uniqueness can be ensured with domain name constraint
|
||||
|
||||
### Communication security
|
||||
|
||||
Service-to-service communication is tunneled through the client side [Envoy](https://envoyproxy.github.io/envoy/) and the server side Envoy. End-to-end communication is secured by:
|
||||
|
||||
* Local TCP connections between the service and Envoy
|
||||
|
||||
* Mutual TLS connections between proxies
|
||||
|
||||
* Secure Naming: during the handshake process, the client side Envoy checks that the service account provided by the server side certificate is allowed to run the target service
|
||||
|
||||
### Key management
|
||||
|
||||
Istio 0.2 supports services running on both Kubernetes pods and VM/bare-metal machines. We use different key provisioning mechanisms for each scenario.
|
||||
|
||||
For services running on Kubernetes pods, the per-cluster Citadel (acting as Certificate Authority) automates the key & certificate management process. It mainly performs four critical operations:
|
||||
|
||||
* Generate a [SPIFFE](https://spiffe.github.io/docs/svid) key and certificate pair for each service account
|
||||
|
||||
* Distribute a key and certificate pair to each pod according to the service account
|
||||
|
||||
* Rotate keys and certificates periodically
|
||||
|
||||
* Revoke a specific key and certificate pair when necessary
|
||||
|
||||
For services running on VM/bare-metal machines, the above four operations are performed by Citadel together with node agents.
|
||||
|
||||
## Workflow
|
||||
|
||||
The Istio Security workflow consists of two phases, deployment and runtime. For the deployment phase, we discuss the two
|
||||
scenarios (i.e., in Kubernetes and VM/bare-metal machines) separately since they are different. Once the key and
|
||||
certificate are deployed, the runtime phase is the same for the two scenarios. We briefly cover the workflow in this
|
||||
section.
|
||||
|
||||
### Deployment phase (Kubernetes Scenario)
|
||||
|
||||
1. Citadel watches the Kubernetes API Server, creates a [SPIFFE](https://spiffe.github.io/docs/svid) key and certificate
|
||||
pair for each of the existing and new service accounts, and sends them to the API Server.
|
||||
|
||||
1. When a pod is created, API Server mounts the key and certificate pair according to the service account using [Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/).
|
||||
|
||||
1. [Pilot](/docs/concepts/traffic-management/#pilot-and-envoy) generates the config with proper key and certificate and secure naming information,
|
||||
which defines what service account(s) can run a certain service, and passes it to Envoy.
|
||||
|
||||
### Deployment phase (VM/bare-metal Machines Scenario)
|
||||
|
||||
1. Citadel creates a gRPC service to take CSR request.
|
||||
|
||||
1. Node agent creates the private key and CSR, sends the CSR to Citadel for signing.
|
||||
|
||||
1. Citadel validates the credentials carried in the CSR, and signs the CSR to generate the certificate.
|
||||
|
||||
1. Node agent puts the certificate received from Citadel and the private key to Envoy.
|
||||
|
||||
1. The above CSR process repeats periodically for rotation.
|
||||
|
||||
### Runtime phase
|
||||
|
||||
1. The outbound traffic from a client service is rerouted to its local Envoy.
|
||||
|
||||
1. The client side Envoy starts a mutual TLS handshake with the server side Envoy. During the handshake, it also does a secure naming check to verify that the service account presented in the server certificate can run the server service.
|
||||
|
||||
1. The traffic is forwarded to the server side Envoy after a mutual TLS connection is established, which is then forwarded to the server service through local TCP connections.
|
||||
|
||||
## Best practices
|
||||
|
||||
In this section, we provide a few deployment guidelines and then discuss a real-world scenario.
|
||||
|
||||
### Deployment guidelines
|
||||
|
||||
* If there are multiple service operators (a.k.a. [SREs](https://en.wikipedia.org/wiki/Site_reliability_engineering)) deploying different services in a cluster (typically in a medium- or large-size cluster), we recommend creating a separate [namespace](https://kubernetes.io/docs/tasks/administer-cluster/namespaces-walkthrough/) for each SRE team to isolate their access. For example, you could create a "team1-ns" namespace for team1, and "team2-ns" namespace for team2, such that both teams won't be able to access each other's services.
|
||||
|
||||
* If Citadel is compromised, all its managed keys and certificates in the cluster may be exposed. We *strongly* recommend running Citadel
|
||||
on a dedicated namespace (for example, istio-citadel-ns), which only cluster admins have access to.
|
||||
|
||||
### Example
|
||||
|
||||
Let's consider a 3-tier application with three services: photo-frontend, photo-backend, and datastore. Photo-frontend and photo-backend services are managed by the photo SRE team while the datastore service is managed by the datastore SRE team. Photo-frontend can access photo-backend, and photo-backend can access datastore. However, photo-frontend cannot access datastore.
|
||||
|
||||
In this scenario, a cluster admin creates 3 namespaces: istio-citadel-ns, photo-ns, and datastore-ns. Admin has access to all namespaces, and each team only has
|
||||
access to its own namespace. The photo SRE team creates 2 service accounts to run photo-frontend and photo-backend respectively in namespace photo-ns. The
|
||||
datastore SRE team creates 1 service account to run the datastore service in namespace datastore-ns. Moreover, we need to enforce the service access control
|
||||
in [Istio Mixer](/docs/concepts/policies-and-telemetry/) such that photo-frontend cannot access datastore.
|
||||
|
||||
In this setup, Citadel is able to provide keys and certificates management for all namespaces, and isolate
|
||||
microservice deployments from each other.
|
||||
|
||||
## Future work
|
||||
|
||||
* Inter-cluster service-to-service authentication
|
||||
|
||||
* Powerful authorization mechanisms: ABAC, RBAC, etc
|
||||
|
||||
* Per-service auth enablement support
|
||||
|
||||
* Secure Istio components (Mixer, Pilot)
|
||||
|
||||
* End-user to service authentication using JWT/OAuth2/OpenID_Connect.
|
||||
|
||||
* Support GCP service account
|
||||
|
||||
* Unix domain socket for local communication between service and Envoy
|
||||
|
||||
* Middle proxy support
|
||||
|
||||
* Pluggable key management component
|
||||
|
|
@ -1,247 +0,0 @@
|
|||
---
|
||||
title: Istio Role-Based Access Control (RBAC)
|
||||
description: Describes Istio RBAC which provides access control for services in Istio Mesh.
|
||||
weight: 20
|
||||
keywords: [security,rbac,authorization,access-control]
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Istio Role-Based Access Control (RBAC) provides namespace-level, service-level, method-level access control for services in the Istio Mesh.
|
||||
It features:
|
||||
|
||||
* Role-Based semantics, which is simple and easy to use.
|
||||
|
||||
* Service-to-service and endUser-to-Service authorization.
|
||||
|
||||
* Flexibility through custom properties support in roles and role-bindings.
|
||||
|
||||
## Architecture
|
||||
|
||||
The diagram below shows the Istio RBAC architecture. Operators specify Istio RBAC policies. The policies are saved in
|
||||
the Istio config store.
|
||||
|
||||
{{< image width="80%" ratio="56.25%"
|
||||
link="./IstioRBAC.svg"
|
||||
alt="Istio RBAC"
|
||||
caption="Istio RBAC Architecture"
|
||||
>}}
|
||||
|
||||
The Istio RBAC engine does two things:
|
||||
* **Fetch RBAC policy.** Istio RBAC engine watches for changes on RBAC policy. It fetches the updated RBAC policy if it sees any changes.
|
||||
* **Authorize Requests.** At runtime, when a request comes, the request context is passed to Istio RBAC engine. RBAC engine evaluates the
|
||||
request context against the RBAC policies, and returns the authorization result (ALLOW or DENY).
|
||||
|
||||
### Request context
|
||||
|
||||
In the current release, the Istio RBAC engine is implemented as a [Mixer adapter](/docs/concepts/policies-and-telemetry/#adapters).
|
||||
The request context is provided as an instance of the
|
||||
[authorization template](/docs/reference/config/policy-and-telemetry/templates/authorization/). The request context
|
||||
contains all the information about the request and the environment that an authorization module needs to know. In particular, it has two parts:
|
||||
|
||||
* **subject** contains a list of properties that identify the caller identity, including `"user"` name/ID, `"groups"` the subject belongs to,
|
||||
or any additional properties about the subject such as namespace, service name.
|
||||
* **action** specifies "how a service is accessed". It includes `"namespace"`, `"service"`, `"path"`, `"method"` that the action is being taken on,
|
||||
and any additional properties about the action.
|
||||
|
||||
Below we show an example "requestcontext".
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: authorization
|
||||
metadata:
|
||||
name: requestcontext
|
||||
namespace: istio-system
|
||||
spec:
|
||||
subject:
|
||||
user: source.user | ""
|
||||
groups: ""
|
||||
properties:
|
||||
service: source.service | ""
|
||||
namespace: source.namespace | ""
|
||||
action:
|
||||
namespace: destination.namespace | ""
|
||||
service: destination.service | ""
|
||||
method: request.method | ""
|
||||
path: request.path | ""
|
||||
properties:
|
||||
version: request.headers["version"] | ""
|
||||
{{< /text >}}
|
||||
|
||||
## Istio RBAC policy
|
||||
|
||||
Istio RBAC introduces `ServiceRole` and `ServiceRoleBinding`, both of which are defined as Kubernetes CustomResourceDefinition (CRD) objects.
|
||||
|
||||
* **`ServiceRole`** defines a role for access to services in the mesh.
|
||||
* **`ServiceRoleBinding`** grants a role to subjects (e.g., a user, a group, a service).
|
||||
|
||||
### `ServiceRole`
|
||||
|
||||
A `ServiceRole` specification includes a list of rules. Each rule has the following standard fields:
|
||||
* **services**: A list of service names, which are matched against the `action.service` field of the "requestcontext".
|
||||
* **methods**: A list of method names which are matched against the `action.method` field of the "requestcontext". In the above "requestcontext",
|
||||
this is the HTTP or gRPC method. Note that gRPC methods are formatted in the form of "packageName.serviceName/methodName" (case sensitive).
|
||||
* **paths**: A list of HTTP paths which are matched against the `action.path` field of the "requestcontext". It is ignored in gRPC case.
|
||||
|
||||
A `ServiceRole` specification only applies to the **namespace** specified in `"metadata"` section. The "services" and "methods" are required
|
||||
fields in a rule. "paths" is optional. If not specified or set to "*", it applies to "any" instance.
|
||||
|
||||
Here is an example of a simple role "service-admin", which has full access to all services in "default" namespace.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: ServiceRole
|
||||
metadata:
|
||||
name: service-admin
|
||||
namespace: default
|
||||
spec:
|
||||
rules:
|
||||
- services: ["*"]
|
||||
methods: ["*"]
|
||||
{{< /text >}}
|
||||
|
||||
Here is another role "products-viewer", which has read ("GET" and "HEAD") access to service "products.default.svc.cluster.local"
|
||||
in "default" namespace.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: ServiceRole
|
||||
metadata:
|
||||
name: products-viewer
|
||||
namespace: default
|
||||
spec:
|
||||
rules:
|
||||
- services: ["products.default.svc.cluster.local"]
|
||||
methods: ["GET", "HEAD"]
|
||||
{{< /text >}}
|
||||
|
||||
In addition, we support **prefix matching** and **suffix matching** for all the fields in a rule. For example, you can define a "tester" role that
|
||||
has the following permissions in "default" namespace:
|
||||
* Full access to all services with prefix "test-" (e.g, "test-bookstore", "test-performance", "test-api.default.svc.cluster.local").
|
||||
* Read ("GET") access to all paths with "/reviews" suffix (e.g, "/books/reviews", "/events/booksale/reviews", "/reviews")
|
||||
in service "bookstore.default.svc.cluster.local".
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: ServiceRole
|
||||
metadata:
|
||||
name: tester
|
||||
namespace: default
|
||||
spec:
|
||||
rules:
|
||||
- services: ["test-*"]
|
||||
methods: ["*"]
|
||||
- services: ["bookstore.default.svc.cluster.local"]
|
||||
paths: ["*/reviews"]
|
||||
methods: ["GET"]
|
||||
{{< /text >}}
|
||||
|
||||
In `ServiceRole`, the combination of "namespace"+"services"+"paths"+"methods" defines "how a service (services) is allowed to be accessed".
|
||||
In some situations, you may need to specify additional constraints that a rule applies to. For example, a rule may only applies to a
|
||||
certain "version" of a service, or only applies to services that are labeled "foo". You can easily specify these constraints using
|
||||
custom fields.
|
||||
|
||||
For example, the following `ServiceRole` definition extends the previous "products-viewer" role by adding a constraint on service "version"
|
||||
being "v1" or "v2". Note that the "version" property is provided by `"action.properties.version"` in "requestcontext".
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: ServiceRole
|
||||
metadata:
|
||||
name: products-viewer-version
|
||||
namespace: default
|
||||
spec:
|
||||
rules:
|
||||
- services: ["products.default.svc.cluster.local"]
|
||||
methods: ["GET", "HEAD"]
|
||||
constraints:
|
||||
- key: "version"
|
||||
values: ["v1", "v2"]
|
||||
{{< /text >}}
|
||||
|
||||
### `ServiceRoleBinding`
|
||||
|
||||
A `ServiceRoleBinding` specification includes two parts:
|
||||
* **roleRef** refers to a `ServiceRole` resource **in the same namespace**.
|
||||
* A list of **subjects** that are assigned the role.
|
||||
|
||||
A subject can either be a "user", or a "group", or is represented with a set of "properties". Each entry ("user" or "group" or an entry
|
||||
in "properties") must match one of fields ("user" or "groups" or an entry in "properties") in the "subject" part of the "requestcontext"
|
||||
instance.
|
||||
|
||||
Here is an example of `ServiceRoleBinding` resource "test-binding-products", which binds two subjects to ServiceRole "product-viewer":
|
||||
* user "alice@yahoo.com".
|
||||
* "reviews.abc.svc.cluster.local" service in "abc" namespace.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: ServiceRoleBinding
|
||||
metadata:
|
||||
name: test-binding-products
|
||||
namespace: default
|
||||
spec:
|
||||
subjects:
|
||||
- user: "alice@yahoo.com"
|
||||
- properties:
|
||||
service: "reviews.abc.svc.cluster.local"
|
||||
namespace: "abc"
|
||||
roleRef:
|
||||
kind: ServiceRole
|
||||
name: "products-viewer"
|
||||
{{< /text >}}
|
||||
|
||||
In the case that you want to make a service(s) publicly accessible, you can use set the subject to `user: "*"`. This will assign a `ServiceRole`
|
||||
to all users/services.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: ServiceRoleBinding
|
||||
metadata:
|
||||
name: binding-products-allusers
|
||||
namespace: default
|
||||
spec:
|
||||
subjects:
|
||||
- user: "*"
|
||||
roleRef:
|
||||
kind: ServiceRole
|
||||
name: "products-viewer"
|
||||
{{< /text >}}
|
||||
|
||||
## Enabling Istio RBAC
|
||||
|
||||
Istio RBAC can be enabled by adding the following Mixer adapter rule. The rule has two parts. The first part defines a RBAC handler.
|
||||
It has two parameters, `"config_store_url"` and `"cache_duration"`.
|
||||
* The `"config_store_url"` parameter specifies where RBAC engine fetches RBAC policies. The default value for `"config_store_url"` is
|
||||
`"k8s://"`, which means Kubernetes API server. Alternatively, if you are testing RBAC policy locally, you may set it to a local directory
|
||||
such as `"fs:///tmp/testdata/configroot"`.
|
||||
* The `"cache_duration"` parameter specifies the duration for which the authorization results may be cached on Mixer client (i.e., Istio proxy).
|
||||
The default value for `"cache_duration"` is 1 minute.
|
||||
|
||||
The second part defines a rule, which specifies that the RBAC handler should be invoked with the "requestcontext" instance [defined
|
||||
earlier in the document](#request-context).
|
||||
|
||||
In the following example, Istio RBAC is enabled for "default" namespace. And the cache duration is set to 30 seconds.
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: rbac
|
||||
metadata:
|
||||
name: handler
|
||||
namespace: istio-system
|
||||
spec:
|
||||
config_store_url: "k8s://"
|
||||
cache_duration: "30s"
|
||||
---
|
||||
apiVersion: "config.istio.io/v1alpha2"
|
||||
kind: rule
|
||||
metadata:
|
||||
name: rbaccheck
|
||||
namespace: istio-system
|
||||
spec:
|
||||
match: destination.namespace == "default"
|
||||
actions:
|
||||
# handler and instance names default to the rule's namespace.
|
||||
- handler: handler.rbac
|
||||
instances:
|
||||
- requestcontext.authorization
|
||||
{{< /text >}}
|
||||
|
|
@ -5,11 +5,34 @@ weight: 15
|
|||
aliases:
|
||||
- /docs/concepts/what-is-istio/overview
|
||||
- /docs/concepts/what-is-istio/goals
|
||||
- /about/intro
|
||||
---
|
||||
|
||||
This document introduces Istio: an open platform to connect, manage, and secure microservices. Istio provides an easy way to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without requiring any changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, configured and managed using Istio's control plane functionality.
|
||||
This document introduces Istio: an open platform to connect, manage, and secure microservices.
|
||||
Istio provides an easy way to create a network of deployed services with load balancing, service-to-service authentication,
|
||||
monitoring, and more, without requiring any changes in service code. You add Istio support to services by deploying a
|
||||
special sidecar proxy throughout your environment that intercepts all network communication between microservices, configured
|
||||
and managed using Istio's control plane functionality.
|
||||
|
||||
Istio currently supports service deployment on Kubernetes, as well as services registered with Consul or Eureka and services running on individual VMs.
|
||||
- Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.
|
||||
|
||||
- Fine-grained control of traffic behavior with rich routing rules,
|
||||
retries, failovers, and fault injection.
|
||||
|
||||
- A pluggable policy layer and configuration API supporting access controls,
|
||||
rate limits and quotas.
|
||||
|
||||
- Automatic metrics, logs, and traces for all traffic within a cluster,
|
||||
including cluster ingress and egress.
|
||||
|
||||
- Secure service-to-service communication in a cluster with strong
|
||||
identity-based authentication and authorization.
|
||||
|
||||
Istio can be deployed on [Kubernetes](https://kubernetes.io),
|
||||
[Nomad](https://nomadproject.io) with [Consul](https://www.consul.io/). We
|
||||
plan to add support for additional platforms such as
|
||||
[Cloud Foundry](https://www.cloudfoundry.org/),
|
||||
and [Apache Mesos](https://mesos.apache.org/) in the near future.
|
||||
|
||||
## Why use Istio?
|
||||
|
||||
|
|
@ -98,7 +121,7 @@ interface for traffic management.
|
|||
[Citadel](/docs/concepts/security/) provides strong service-to-service and end-user authentication, with built-in identity and
|
||||
credential management. It can be used to upgrade unencrypted traffic in the service mesh, and provides operators the ability to enforce
|
||||
policy based on service identity rather than network controls. Starting from release 0.5, Istio supports
|
||||
[role-based access control](/docs/concepts/security/rbac/) to control who can access your services.
|
||||
[role-based access control](/docs/concepts/security/#role-based-access-control-rbac) to control who can access your services.
|
||||
|
||||
## Design Goals
|
||||
|
||||
|
|
|
|||
|
|
@ -257,7 +257,7 @@ For example, run the following command on a macOS or Linux system:
|
|||
|
||||
Install Istio's core components. Choose one of the four _**mutually exclusive**_ options below for quick installation. However, we recommend you to install with the [Helm Chart](/docs/setup/kubernetes/helm-install/) for production installations of Istio to leverage all the options to configure and customize Istio to your needs.
|
||||
|
||||
* Install Istio without enabling [mutual TLS authentication](/docs/concepts/security/mutual-tls/) between sidecars. Choose this option for clusters with existing applications, applications where services with an Istio sidecar need to be able to communicate with other non-Istio Kubernetes services, and applications that use [liveness and readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/), headless services, or StatefulSets.
|
||||
* Install Istio without enabling [mutual TLS authentication](/docs/concepts/security/#mutual-tls-authentication) between sidecars. Choose this option for clusters with existing applications, applications where services with an Istio sidecar need to be able to communicate with other non-Istio Kubernetes services, and applications that use [liveness and readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/), headless services, or StatefulSets.
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f install/kubernetes/istio.yaml
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ sidecars injected in the future.
|
|||
|
||||
## Migrating per-service mutual TLS enablement via annotations to authentication policy
|
||||
|
||||
If you use service annotations to override global mutual TLS enablement for a service, you need to replace it with [authentication policy](/docs/concepts/security/authn-policy/) and [destination rules](/docs/concepts/traffic-management/#destination-rules).
|
||||
If you use service annotations to override global mutual TLS enablement for a service, you need to replace it with [authentication policy](/docs/concepts/security/#authentication-policy) and [destination rules](/docs/concepts/traffic-management/#destination-rules).
|
||||
|
||||
For example, if you install Istio with mutual TLS enabled, and disable it for service `foo` using a service annotation like below:
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Through this task, you will learn how to:
|
|||
|
||||
## Before you begin
|
||||
|
||||
* Understand Istio [authentication policy](/docs/concepts/security/authn-policy/) and related [mutual TLS authentication](/docs/concepts/security/mutual-tls/) concepts.
|
||||
* Understand Istio [authentication policy](/docs/concepts/security/#authentication-policy) and related [mutual TLS authentication](/docs/concepts/security/#mutual-tls-authentication) concepts.
|
||||
|
||||
* Have a Kubernetes cluster with Istio installed, without global mutual TLS enabled (e.g use `install/kubernetes/istio.yaml` as described in [installation steps](/docs/setup/kubernetes/quick-start/#installation-steps), or set `global.mtls.enabled` to false using [Helm](/docs/setup/kubernetes/helm-install/)).
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ this feature is not needed if the production setup is not using the
|
|||
|
||||
Using [Helm](/docs/setup/kubernetes/helm-install/) with `global.mtls.enabled` to `true`.
|
||||
|
||||
> Starting with Istio 0.7, you can use [authentication policy](/docs/concepts/security/authn-policy/) to configure mutual TLS for all/selected services in a namespace (repeated for all namespaces to get global setting). See [authentication policy task](/docs/tasks/security/authn-policy/)
|
||||
> Starting with Istio 0.7, you can use [authentication policy](/docs/concepts/security/#authentication-policy) to configure mutual TLS for all/selected services in a namespace (repeated for all namespaces to get global setting). See [authentication policy task](/docs/tasks/security/authn-policy/)
|
||||
|
||||
## Deploying Citadel with health checking
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ weight: 80
|
|||
keywords: [security,mutual-tls,https]
|
||||
---
|
||||
|
||||
This task shows how Istio Mutual TLS works with HTTPS services. It includes:
|
||||
This task shows how mutual TLS works with HTTPS services. It includes:
|
||||
|
||||
* Deploying an HTTPS service without Istio sidecar
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ This task assumes you have a Kubernetes cluster:
|
|||
|
||||
Use [Helm](/docs/setup/kubernetes/helm-install/) with `global.mtls.enabled` to `true`.
|
||||
|
||||
> Starting with Istio 0.7, you can use [authentication policy](/docs/concepts/security/authn-policy/) to configure mutual TLS for all/selected services in a namespace
|
||||
> Starting with Istio 0.7, you can use [authentication policy](/docs/concepts/security/#authentication-policy) to configure mutual TLS for all/selected services in a namespace
|
||||
(repeated for all namespaces to get global setting). See the [authentication policy task](/docs/tasks/security/authn-policy/)
|
||||
|
||||
* For demo, deploy [httpbin]({{< github_tree >}}/samples/httpbin) and [sleep]({{< github_tree >}}/samples/sleep) with Envoy sidecar. For simplicity, the demo is setup in the `default` namespace. If you wish to use a different namespace, please add `-n yournamespace` appropriately to the example commands in the next section.
|
||||
|
|
@ -106,7 +106,7 @@ $ kubectl exec $(kubectl get pod -l app=httpbin -o jsonpath={.items..metadata.na
|
|||
URI:spiffe://cluster.local/ns/default/sa/default
|
||||
{{< /text >}}
|
||||
|
||||
Please check [secure naming](/docs/concepts/security/mutual-tls/#workflow) for more information about _service identity_ in Istio.
|
||||
Please check [secure naming](/docs/concepts/security/#workflow) for more information about _service identity_ in Istio.
|
||||
|
||||
## Testing the authentication setup
|
||||
|
||||
|
|
@ -140,7 +140,7 @@ Assuming mutual TLS authentication is properly turned on, it should not affect c
|
|||
200
|
||||
{{< /text >}}
|
||||
|
||||
> Istio uses [Kubernetes service accounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) as service identity, which offers stronger security than service name (refer [here](/docs/concepts/security/mutual-tls/#identity) for more information). Thus the certificates used in Istio do not have service names, which is the information that `curl` needs to verify server identity. As a result, we use `curl` option `-k` to prevent the `curl` client from aborting when failing to find and verify the server name (i.e., httpbin.ns.svc.cluster.local) in the certificate provided by the server.
|
||||
> Istio uses [Kubernetes service accounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) as service identity, which offers stronger security than service name (refer [here](/docs/concepts/security/#identity) for more information). Thus the certificates used in Istio do not have service names, which is the information that `curl` needs to verify server identity. As a result, we use `curl` option `-k` to prevent the `curl` client from aborting when failing to find and verify the server name (i.e., httpbin.ns.svc.cluster.local) in the certificate provided by the server.
|
||||
|
||||
1. Request from pod without sidecar. For this demo, let's install another `sleep` service without sidecar. To avoid name conflicts, we put it in different namespace.
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ operator-specified root certificate. This task demonstrates an example to plug c
|
|||
|
||||
Using [Helm](/docs/setup/kubernetes/helm-install/) with `global.mtls.enabled` to `true`.
|
||||
|
||||
> From Istio 0.7, you can use [authentication policy](/docs/concepts/security/authn-policy/) to configure mutual TLS for all/selected services in a namespace (repeated for all namespaces to get global setting). See [authentication policy task](/docs/tasks/security/authn-policy/)
|
||||
> Starting with Istio 0.7, you can use [authentication policy](/docs/concepts/security/#authentication-policy) to configure mutual TLS for all/selected services in a namespace (repeated for all namespaces to get global setting). See [authentication policy task](/docs/tasks/security/authn-policy/)
|
||||
|
||||
## Plugging in the existing certificate and key
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ keywords: [security,access-control,rbac]
|
|||
---
|
||||
|
||||
This task shows how to set up role-based access control (RBAC) for services in Istio mesh. You can read more about Istio
|
||||
RBAC from [Istio RBAC concept page](/docs/concepts/security/rbac/).
|
||||
RBAC from [Istio RBAC concept page](/docs/concepts/security/#role-based-access-control-rbac).
|
||||
|
||||
## Before you begin
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ using the service accounts provided by Istio authentication.
|
|||
When Istio mutual TLS authentication is enabled, the server authenticates the client according to its certificate, and obtains the client's
|
||||
service account from the certificate. The service account is in the `source.user` attribute.
|
||||
For the format of the service account in Istio, please refer to the
|
||||
[Istio auth identity](/docs/concepts/security/mutual-tls/#identity).
|
||||
[Istio auth identity](/docs/concepts/security/#identity).
|
||||
|
||||
## Before you begin
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,8 @@ There are three options for liveness and readiness probes in Kubernetes: 1) comm
|
|||
|
||||
## Before you begin
|
||||
|
||||
* Understand [Kubernetes liveness and readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/), Istio [authentication policy](/docs/concepts/security/authn-policy/) and [mutual TLS authentication](/docs/concepts/security/mutual-tls/) concepts.
|
||||
* Understand [Kubernetes liveness and readiness probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/), Istio
|
||||
[authentication policy](/docs/concepts/security/#authentication-policy) and [mutual TLS authentication](/docs/concepts/security/#mutual-tls-authentication) concepts.
|
||||
|
||||
* Have a Kubernetes cluster with Istio installed, without global mutual TLS enabled (e.g use istio.yaml as described in [installation steps](/docs/setup/kubernetes/quick-start/#installation-steps), or set `global.mtls.enabled` to false using [Helm](/docs/setup/kubernetes/helm-install/)).
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: Can I enable Istio Auth with some services while disable others in the sa
|
|||
weight: 30
|
||||
---
|
||||
|
||||
Starting with Istio 0.8, you can use [authentication policy](/docs/concepts/security/authn-policy/) to enable (or disable) mutual TLS per service. For example, the policy below will disable mutual TLS on port 9080 for service `details`
|
||||
Starting with Istio 0.8, you can use [authentication policy](/docs/concepts/security/#authentication-policy) to enable (or disable) mutual TLS per service. For example, the policy below will disable mutual TLS on port 9080 for service `details`
|
||||
|
||||
{{< text bash >}}
|
||||
$ cat <<EOF | istioctl create -f -
|
||||
|
|
|
|||
|
|
@ -3,4 +3,5 @@ title: Does Istio Auth support authorization?
|
|||
weight: 110
|
||||
---
|
||||
|
||||
Yes. Starting from Istio 0.5 release, we provide Role Based Access Control for services in Istio mesh. [Learn more](/docs/concepts/security/rbac/).
|
||||
Yes. Starting from Istio 0.5 release, we provide Role Based Access Control for services in Istio mesh.
|
||||
[Learn more](/docs/concepts/security/#role-based-access-control-rbac).
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: How can I enable/disable mutual TLS encryption after I installed Istio?
|
|||
weight: 10
|
||||
---
|
||||
|
||||
Starting with Istio 0.8, [authentication policy](/docs/concepts/security/authn-policy/) can be used to change mutual TLS setting at run time, without needing to reinstall Istio.
|
||||
Starting with Istio 0.8, [authentication policy](/docs/concepts/security/#authentication-policy) can be used to change mutual TLS setting at run time, without needing to reinstall Istio.
|
||||
|
||||
Before 0.8, the most straightforward way to enable/disable mutual TLS is by entirely
|
||||
uninstalling and re-installing Istio.
|
||||
|
|
|
|||
|
|
@ -2,6 +2,6 @@
|
|||
title: Can Istio mutual TLS enabled services communicate with services without Istio?
|
||||
weight: 20
|
||||
---
|
||||
Starting with Istio 0.8, a service with Istio mutual TLS enabled can talk to a service without Istio. Mutual TLS is enabled via [authentication policy](/docs/concepts/security/authn-policy/) and this only specifies the service behavior as a server, not client, which means a mutual TLS enabled service will still send http traffic (not mutual TLS) to others unless you explicitly specify it with [destination rule](/docs/reference/config/istio.networking.v1alpha3/#DestinationRule).
|
||||
Starting with Istio 0.8, a service with Istio mutual TLS enabled can talk to a service without Istio. Mutual TLS is enabled via [authentication policy](/docs/concepts/security/#authentication-policy) and this only specifies the service behavior as a server, not client, which means a mutual TLS enabled service will still send http traffic (not mutual TLS) to others unless you explicitly specify it with [destination rule](/docs/reference/config/istio.networking.v1alpha3/#DestinationRule).
|
||||
|
||||
However, unless a service without Istio can present a valid certificate, which is less likely to happen, a service without Istio cannot talk to a service with Istio mutual TLS enabled and this is the expected behavior of 'mutual TLS'.
|
||||
|
|
|
|||
|
|
@ -3,4 +3,4 @@ title: Mutual TLS Authentication
|
|||
---
|
||||
|
||||
Mutual TLS provides strong service-to-service authentication with built-in identity and credential management.
|
||||
[Learn more about mutual TLS authentication](/docs/concepts/security/mutual-tls/).
|
||||
[Learn more about mutual TLS authentication](/docs/concepts/security/#mutual-tls-authentication).
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ Istio 希望在不变更服务代码的情况下增强微服务自身及其通
|
|||
下图展示 Istio 安全相关的架构，其中包括三个主要组件：认证、密钥管理和通信安全。服务 `frontend` 使用的 Service account 是 frontend-team；而 `backend` 服务的 Service account 是 backend-team，Istio 在这两个服务之间的通信过程中进行了加密。不论服务是运行在 Kubernetes 的容器之中，还是运行在虚拟机/裸机上，都能获得 Istio 的支持。
|
||||
|
||||
{{< image width="80%" ratio="56.25%"
|
||||
link="/docs/concepts/security/mutual-tls/auth.svg"
|
||||
link="/docs/concepts/security/auth.svg"
|
||||
alt="构成 Istio 认证模型的组件"
|
||||
caption="Istio 安全架构"
|
||||
>}}
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ Envoy 被部署为 **sidecar**，和对应服务在同一个 Kubernetes pod 中
|
|||
|
||||
### Citadel
|
||||
|
||||
[Citadel](/docs/concepts/security/) 通过内置身份和凭证管理可以提供强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。从 0.5 版本开始，Istio 支持[基于角色的访问控制](/docs/concepts/security/rbac/)，以控制谁可以访问您的服务。
|
||||
[Citadel](/docs/concepts/security/) 通过内置身份和凭证管理可以提供强大的服务间和最终用户身份验证。可用于升级服务网格中未加密的流量，并为运维人员提供基于服务标识而不是网络控制的强制执行策略的能力。从 0.5 版本开始，Istio 支持[基于角色的访问控制](/docs/concepts/security/#role-based-access-control-rbac)，以控制谁可以访问您的服务。
|
||||
|
||||
## 下一步
|
||||
|
||||
|
|
|
|||
|
|
@ -252,7 +252,7 @@ $ kubectl describe pod --namespace kube-system $(kubectl get pods --namespace ku
|
|||
|
||||
安装 Istio 的核心部分。从以下四种_**非手动**_部署方式中选择一种方式安装。然而，我们推荐您在生产环境时使用 [Helm Chart](/docs/setup/kubernetes/helm-install/) 来安装 Istio，这样可以按需定制配置选项。
|
||||
|
||||
* 安装 Istio 而不启用 sidecar 之间的[双向TLS验证](/docs/concepts/security/mutual-tls/)。对于现有应用程序的集群，使用 Istio sidecar 的服务需要能够与其他非 Istio Kubernetes 服务以及使用[存活和就绪探针](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)、headless 服务或 StatefulSets 的应用程序通信的应用程序选择此选项。
|
||||
* 安装 Istio 而不启用 sidecar 之间的[双向TLS验证](/docs/concepts/security/#mutual-tls-authentication)。对于现有应用程序的集群，使用 Istio sidecar 的服务需要能够与其他非 Istio Kubernetes 服务以及使用[存活和就绪探针](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/)、headless 服务或 StatefulSets 的应用程序通信的应用程序选择此选项。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f install/kubernetes/istio.yaml
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ keywords: [security,mutual-tls]
|
|||
|
||||
使用 [Helm](/docs/setup/kubernetes/helm-install/) 进行安装，设置 `global.mtls.enabled` 为 `true`.
|
||||
|
||||
> 从 Istio 0.7 开始，可以使用[认证策略](/docs/concepts/security/authn-policy/)来给命名空间中全部/部分服务配置双向 TLS 功能。（在所有命名空间中重复此操作，就相当于全局配置了）。这部分内容可参考[认证策略任务](/docs/tasks/security/authn-policy/)
|
||||
> 从 Istio 0.7 开始，可以使用[认证策略](/docs/concepts/security/#authentication-policy)来给命名空间中全部/部分服务配置双向 TLS 功能。（在所有命名空间中重复此操作，就相当于全局配置了）。这部分内容可参考[认证策略任务](/docs/tasks/security/authn-policy/)
|
||||
|
||||
* 接下来进行演示应用的部署，首先是注入 Envoy sidecar 的 [httpbin](https://github.com/istio/istio/blob/{{<branch_name>}}/samples/httpbin) 以及 [sleep](https://github.com/istio/istio/tree/master/samples/sleep)。为简单起见，我们将演示应用安装到 `default` 命名空间。如果想要部署到其他命名空间，可以在下一节的示例命令中加入 `-n yournamespace`。
|
||||
|
||||
|
|
@ -108,7 +108,7 @@ $ kubectl exec $(kubectl get pod -l app=httpbin -o jsonpath={.items..metadata.na
|
|||
URI:spiffe://cluster.local/ns/default/sa/default
|
||||
{{< /text >}}
|
||||
|
||||
请参阅 [secure naming](/docs/concepts/security/mutual-tls/#workflow) 一节，可以了解更多**服务认证**方面的内容。
|
||||
请参阅 [secure naming](/docs/concepts/security/#workflow) 一节，可以了解更多**服务认证**方面的内容。
|
||||
|
||||
## 测试认证配置
|
||||
|
||||
|
|
@ -142,7 +142,7 @@ $ kubectl exec $(kubectl get pod -l app=httpbin -o jsonpath={.items..metadata.na
|
|||
200
|
||||
{{< /text >}}
|
||||
|
||||
> Istio 使用 [Kubernetes service accounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) 作为服务的认证基础，Service account 提供了比服务名称更强的安全性（参考 [Identity](/docs/concepts/security/mutual-tls/#identity) 获取更多信息）。Istio 中使用的证书不包含服务名，而 `curl` 需要用这个信息来检查服务认证。因此就需要给 `curl` 命令加上 `-k` 参数，在对服务器所出示的证书校验的时候，停止对服务器名称（例如 httpbin.ns.svc.cluster.local ）的验证。
|
||||
> Istio 使用 [Kubernetes service accounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) 作为服务的认证基础，Service account 提供了比服务名称更强的安全性（参考 [Identity](/docs/concepts/security/#identity) 获取更多信息）。Istio 中使用的证书不包含服务名，而 `curl` 需要用这个信息来检查服务认证。因此就需要给 `curl` 命令加上 `-k` 参数，在对服务器所出示的证书校验的时候，停止对服务器名称（例如 httpbin.ns.svc.cluster.local ）的验证。
|
||||
|
||||
1. 来自没有 Sidecar 的 Pod。可以重新部署另外一个 `sleep` 应用
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ keywords: [security,certificates]
|
|||
|
||||
使用 [Helm](/docs/setup/kubernetes/helm-install/) 并设置 `global.mtls.enabled` 为 `true`.
|
||||
|
||||
> 从 Istio 0.7 开始，可以使用[认证策略](/docs/concepts/security/authn-policy/)来给命名空间中全部/部分服务配置双向 TLS 功能。（在所有命名空间中重复此操作，就相当于全局配置了）。这部分内容可参考[认证策略任务](/docs/tasks/security/authn-policy/)
|
||||
> 从 Istio 0.7 开始，可以使用[认证策略](/docs/concepts/security/#authentication-policy)来给命名空间中全部/部分服务配置双向 TLS 功能。（在所有命名空间中重复此操作，就相当于全局配置了）。这部分内容可参考[认证策略任务](/docs/tasks/security/authn-policy/)
|
||||
|
||||
## 插入现有密钥和证书
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue