Security sometimes creates Fear, Uncertainty, and Doubt (FUD), and many times, it results in unnecessary controls that hamper productivity. Sadly, breaches do still occur. Major corporations have a chief information security officer, but often, the focus is on putting locks and controls in the wrong places and not knowing which backdoors are wide open. Security breaches can harm the reputation of a company and can cause huge financial damage. A recent example is a fine of $148 million that was imposed on a ride-sharing company, which failed to report the security breach to the Federal Trade Commission. The hackers, in this case, found AWS credentials in their GitHub repository and stole the data of millions of people from an AWS S3 bucket.

The security in Istio is enterprise-grade. You must have noticed the granular nature of security at the namespace level. You have also used a service account to implement authorizations as if security was built through coding at the service level. The good news is that security through Istio can be implemented without having to change any coding. This task is now in the domain of Operations staff when using a service mesh architecture. The backend service contains sensitive data and can be locked down to the frontend service, which has legitimate access needs, and block access to all other services. The short-lived certificates that are used in mutual TLS and their automatic renewal through Citadel provides us with a high-security layer. If access to the AWS S3 bucket is only limited to the microservice that has a legitimate need, security breaches can be avoided. 

In the next chapter, we will go through policy enforcement to implement quotes and rate limits, build white/blacklists, and perform routing using policy adapters though modifying request headers. It will be interesting to note that policy enforcement is also configuration-driven and can be done without the need to modify any application source code.