Please enable JavaScript.
Coggle requires JavaScript to display documents.
ISTIO - Coggle Diagram
ISTIO
SERVICE DISCOVERY
via Platform Adapters reads topology from:
- Kubernetes
- Mesos
- CloudFoundry
and converts this info for ENVOY language (platfrom agnostic) via API
Istio maintains an internal service registry containing the set of services, and their corresponding service endpoints, running in a service mesh. Istio uses the service registry to generate Envoy configuration.
Components
VIRTUAL SERVICE - L7
how requests are routed to a service within mesh
how you route traffic to a given destination
- match on headers, labels, URI etc
- route
- traffic splitting, etc
Defined in VirtualService
- Timeouts
- Retries
- Fault Injection: Delays (mimics overloaded svc) and Aborts (mimics crash)
DESTINATION RULE - service specific - what happens to the traffic when you reach destination? JUST A LOAD BALANCER
- rules applied for request after it reaches service (VirtualService routing is done).
- Service-specific Loadbalancing policy (Random / Weighted / Least)
- Session affinity
- Connection pool size
- Circuit breaker
- Subsets
- security and connection details like
- timeouts and maximum numbers of connections.
what happens to traffic for that destination. Destination rules are applied after virtual service routing rules are evaluated, so they apply to the traffic’s “real” destination.
Defined in DestinationRule
GATEWAYS
- single envoy controlling traffic which enters and leaves the mesh (istio-ingressgateway and istio-egressgateway)
- To specify routing and for the gateway to work as intended, you must also bind the gateway to a virtual service. You do this using the virtual service’s gateways field,
- This ingress gateway uses an external TCP load balancer in Google Cloud.
SERVICE ENTRIES
you add the service entry, the Envoy proxies can send traffic to the service as if it was a service in your mesh.If you want to control traffic to ext service, service entry is needs. Otherwise, access ext services will be possible but no control.
SIDECARS
You can use a sidecar configuration to:
- Fine-tune the set of ports and protocols that an Envoy proxy accepts.
- Limit the set of services that the Envoy proxy can reach.
SECURITY
Secure naming
In Istio, the secure naming information is managed by Pilot. In Kubernetes clusters, Pilot has the information of: 1) which pods are running each service 2) which service account each pod is running as. With these information, Pilot constructs the secure naming information (i.e., which identities are running each service). The secure naming information is encoded in the verify_subject_alt_name field in the CDS (Cluster Discovery Service) information and propagated to each Envoy sidecar.
To realize this segmentation, Istio’s Pilot watches for changes to the authorization policies and distributes these policies to the sidecar proxies that are co-located with the service instances. Each sidecar proxy runs an authorization engine that authorizes requests at runtime. When a request comes to the proxy, the authorization engine evaluates the request context against the current authorization policies, and returns the authorization result, “Allow” or “Deny”.
Istio’s secure naming information defines which service account or accounts can run a certain service. This is a mapping from the server identities, which are encoded in certificates, to the service names that are referred to by a discovery service or DNS. A mapping from identity A to service name B means “A is allowed and authorized to run service B”.
Server identities are encoded in certificates, but service names are retrieved through the discovery service or DNS. The secure naming information maps the server identities to the service names. A mapping of identity A to service name B means “A is authorized to run service B”. The control plane watches the apiserver, generates the secure naming mappings, and distributes them securely to the PEPs.
Authentication
-
SERVICES (PeerAuthentication via X509 certs)
**Peer authentication (mTLS)**
- permissive - can use mTLS or not
- strict - only mTLS is allowed
- disable - no mTLS at all
- unset - inherit from parent if set, otehrwise permissive
Cert is based on SPIFFA - ServiceAccout based
Scope (most narrow scope will take precedence)
- Mesh (in root ns - istio-system)
- Namespace
- Workload
- Port
-
Authorization (AuthorizationPolicy)
FROM - TO - WHEN
Authorization policy enforces access control to the inbound traffic in the server side Envoy proxy. Response can be ALLOW or DENY.Istio checks for matching policies in layers, in this order: CUSTOM -> DENY -> ALLOW
- Cert is based on identity - Service Account
- x509 cert (from SA) + SPIFFE spec = IDENTITY
- naming (spiffe://cluster1.local/ns/default/sa/my-sa)
- we can check some rules based on fileds in JWT tokens
- Selector: target
- Action: allow or deny
- Rules:
-- from: source of request
-- to: specifies operations of request
-- when: conditions to apply the rule
- When there's no policies - everything is ALLOWED
- If any policy exists, eveything is DENIED unless explicitly ALLOWED
- DENY policy evaluated first
OBSERVABILITY
Metrics
based on four “golden signals” of monitoring (latency, traffic, errors, and saturation).
- for or all service traffic in, out, and within an Istio service mesh - control plane
Monitoring levels:
- at Envoy proxy level
- at service level
-
-
JAEGER
- Trace
- each microsrevice represented by span