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

Add suggested additions to security dock (#9068) 

* Add suggested additions to security dock

* Update content/en/docs/ops/best-practices/security/index.md

Co-authored-by: Ram Vennam <rvennam@us.ibm.com>

Co-authored-by: Ram Vennam <rvennam@us.ibm.com>
This commit is contained in:
John Howard 2021-02-25 17:33:20 -08:00 committed by GitHub
parent 187e256b05
commit 09b2059f7b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 32 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
content/en/docs/ops/best-practices/security/index.md
View File

@ -130,6 +130,7 @@ servers:
It may be desired to enforce stricter physical isolation for sensitive services. For example, you may want to run a
[dedicated gateway instance](/docs/setup/install/istioctl/#configure-gateways) for a sensitive `payments.example.com`, while utilizing a single
shared gateway instance for less sensitive domains like `blog.example.com` and `store.example.com`.
This can offer a stronger defense-in-depth and help meet certain regulatory compliance guidelines.
## Protocol detection
@ -162,16 +163,47 @@ Distroless images are currently an alpha feature.
In order to ensure your cluster has the latest security patches for known vulnerabilities, it is important to stay on the latest patch release of Istio and ensure that you are on a [supported release](/about/supported-releases) that is still receiving security patches.
## Detect invalid configurations
While Istio provides validation of resources when they are created, these checks cannot catch all issues preventing configuration being distributed in the mesh.
This could result in applying a policy that is unexpectedly ignored, leading to unexpected results.
* Run `istioctl analyze` before or after applying configuration to ensure it is valid.
* Monitor the control plane for rejected configurations. These are exposed by the `pilot_total_xds_rejects` metric, in addition to logs.
* Test your configuration to ensure it gives the expected results.
For a security policy, it is useful to run positive and negative tests to ensure you do not accidentally restrict too much or too few traffic.
## Avoid alpha and experimental features
All Istio features and APIs are assigned a [feature status](/about/feature-stages/), defining its stability, deprecation policy, and security policy.
Because alpha and experimental features do not have as strong security guarantees, it is recommended to avoid them whenever possible.
Security issues found in these features may not be fixed immediately or otherwise not follow our standard [security vulnerability](/about/security-vulnerabilities/) process.
To determine the feature status of features in use in your cluster, consult the [Istio features](/about/feature-stages/#istio-features) list.
<!-- In the future, we should document the `istioctl` command to check this when available. -->
## Lock down ports
Istio configures a [variety of ports](/docs/ops/deployment/requirements/#ports-used-by-istio) that may be locked down to improve security.
### Control Plane
Istiod exposes a few unauthenticated plaintext ports for convenience by default. If desired, these can be closed:
* Port `8080` exposes the debug interface, which offers read access to a variety of details about the clusters state.
This can be disabled by set the environment variable `ENABLE_DEBUG_ON_HTTP=false` on Istiod. Warning: many `istioctl` commands
depend on this interface and will not function if it is disabled.
* Port `15010` exposes the XDS service over plaintext. This can be disabled by adding the `--grpcAddr=""` flag to the Istiod Deployment.
Note: highly sensitive services, such as the certificate signing and distribution services, are never served over plaintext.
### Data Plane
The proxy exposes a variety of ports. Exposed externally are port `15090` (telemetry) and port `15021` (health check).
Ports `15020` and `15000` provide debugging endpoints. These are exposed over `localhost` only.
As a result, the applications running in the same pod as the proxy have access; there is no trust boundary between the sidecar and application.
## Configure third party service account tokens
To authenticate with the Istio control plane, the Istio proxy will use a Service Account token. Kubernetes supports two forms of these tokens: