Istio- Istio is an open-source service mesh. It's also the default service mesh for many Kubernetes service providers like GCP, Microsoft, and IBM. It solves 3 major problems faced by large-scale microservices-
- Traffic management
- Security
- Observability
curl -L https://istio.io/downloadIstio | sh - cd istio-* export PATH=$PWD/bin:$PATH
2. As istiod takes around 2 GB of ram, for the safer side I will be assigning a node using a node selector. For that first generate the yaml.
istioctl manifest generate --set profile=default > istio.yaml
- using imperative command
- Another way is adding a label in the deployment manifest file itself.
6. The most scalable way of enabling istio sidecar is setting up a validation webhook so that every time a new service is deployed it automatically checks if istio is enabled or not.https://istio.io/latest/docs/tasks/security/cert-management/plugin-ca-cert/
For a production cluster setup, it is highly recommended to use a production-ready CA, such as Hashicorp Vault. It is a good practice to manage the root CA on an offline machine with strong security protection.https://medium.com/everything-full-stack/how-to-integrate-vault-as-external-root-ca-with-cert-manager-istio-csr-and-istio-7684baa369db
istio-proxy (that is, running as a sidecar with the workload) is responsible for creating workload certificates and initiating the CSR process with istiod. The default workload certificate validity is for 24 hours. This can be changed on the workload/client side with an environment variable SECRET_TTL.
Let's create 2 services a, and b, and deploy them in all namespaces. Let's send traffic from b to a from other namespaces. They are able to communicate with each of them like these - 
Now let's apply peer authentication mode. Secured has been applied with a strict peer authentication policy, and lax is applied with a permissive policy & as the name suggests lax doesn't have any authentication policy.
.This upload microservice is created using chatgpt. let's upload a file from another service.
For the demo, we will be using JWT claim-based authentication. for the prod environment, you can use external OIDC providers like Keycloak, google, okta, etc. https://venafi.com/blog/istio-oidc/
Let's apply authn and authz policy that this service only allows requests from signed with specific JWKS. Istio also constructs the requestPrincipal by combining the iss and sub of the JWT token.
In the below screenshot, you can see that requests are forbidden without a valid jwt token & allow for signed valid jwt. 
Controlling http Traffic using istio AUTHZ & Using this for incident response
From the above screenshot, you see it allows only get requests. You can use many selectors as you want depending on your use case where you want your traffic to flow from. https://istio.io/latest/docs/reference/config/security/authorization-policy/
Let's think of a critical production incident, a user is able to upload his profile pic and crash another user or stored xss or any malicious activity. To fix the issue it will require 2 days to fix. By the time how to contain the issue without affecting millions of live users? Now you know how just disable the vulnerable file upload service for 2 days or for the specific URI path field & users will be able to do everything except profile pic upload.
It's turning out to be a big blog, let's continue on the linkerd on part2-
