Enforcing TLS within your service mesh – Implementing Traffic Management, Security, and Observability with Istio-2

Therefore, we can define these interactions and only allow these connections explicitly. Therefore, the frontend microservice will not be able to connect with the mongodb database directly, even if it tries to.

Istio provides the AuthorizationPolicy resource to manage this. Let’s implement the preceding scenario using that.

Let’s start with the posts microservice:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: posts
namespace: blog-app
spec:
selector:
matchLabels:
app: posts
action: ALLOW
rules:
from:
source:
principals: [“cluster.local/ns/blog-app/sa/frontend”]

The AuthorizationPolicy has multiple sections. It starts with name and namespace , which are posts and blog-app, respectively. The spec section contains selector, where we specify that we need to apply this policy to all pods with the app: posts label. We use an ALLOW action for this. Note that Istio has an implicit deny-all policy for all pods that match the selector, and any ALLOW rules will be applied on top of that. Any traffic that does not match the ALLOW rules will be denied by default. We have rules to define what traffic to allow; here, we’re using thefrom >

source > principals and setting the frontend service account on this. So, in summary, this rule will apply to the posts microservice and only allow traffic from the frontend microservice.

Similarly, we will apply the same policy to the reviews microservice, as follows:
…
name: reviews
…
rules:
from:
source:
principals: [“cluster.local/ns/blog-app/sa/frontend”]

The users microservice also only needs to accept traffic from thefrontend microservice:
…
name: users
…
rules:
from:
source:
principals: [“cluster.local/ns/blog-app/sa/frontend”]

The ratings microservice should accept traffic only fromthe reviews microservice, so we will make a slight change to the principals, as follows:
…
name: ratings
…
rules:
from:
source:
principals: [“cluster.local/ns/blog-app/sa/reviews”]

Finally, the mongodb service needs a connection from all microservices apart from frontend, so we must specify multiple entries in the principal section:
…
name: mongodb
…
rules:
from:
source:
principals: [“cluster.local/ns/blog-app/sa/posts”, “cluster.local/ns/blog-app/sa/ reviews”, “cluster.local/ns/blog-app/sa/ratings”, “cluster.local/ns/blog-app/sa/users”]

Since we’ve used service accounts to understand where the requests are coming from, we must also create and assign service accounts to respective services. So, we will modify the blog-app.yaml file and add service accounts for each service, something like the following:
apiVersion: v1
kind: ServiceAccount
metadata:
name: mongodb

namespace: blog-app

apiVersion: apps/v1
kind: StatefulSet
metadata:
…
spec:
…
template:
…
spec:
serviceAccountName: mongodb
containers:
…

I’ve already replicated the same in the new blog-app.yaml file. Let’s commit the changes and push them to GitHub so that we can apply them to our cluster:
$ cp ~/modern-devops/ch15/security/authorization-policies.yaml \ ~/mdo-environments/manifests/blog-app/
$ cp ~/modern-devops/ch15/security/blog-app.yaml \
~/mdo-environments/manifests/blog-app/
$ git add –all
$ git commit -m “Added auth policies”
$ git push

Now, we must wait for the sync to complete and then verify the setup. First, we’ll get a shell to the frontend pod and try to use wget to connect with the backend microservices. We will try to connect with each microservice and see what we get. If we get HTTP 200 or 404, this means the backend is allowing connections, while if we get HTTP 403 or Error, this signifies the backend is blocking connections. Run the following commands to do so:
$ kubectl -n blog-app exec -it $(kubectl get pod -n blog-app | \ grep frontend | awk {‘print $1’}) — /bin/sh / # wget posts:5000

Connecting to posts:5000 (10.71.255.204:5000)
wget: server returned error: HTTP/1.1 404 Not Found / # wget reviews:5000
Connecting to reviews:5000 (10.71.244.177:5000) wget: server returned error: HTTP/1.1 404 Not Found / # wget ratings:5000
Connecting to ratings:5000 (10.71.242.178:5000) wget: server returned error: HTTP/1.1 403 Forbidden / # wget users:5000
Connecting to users:5000 (10.71.241.255:5000)
wget: server returned error: HTTP/1.1 404 Not Found / # wget mongodb:27017
Connecting to mongodb:27017 (10.68.0.18:27017)
wget: error getting response: Resource temporarily unavailable / # exit
command terminated with exit code 1