 Hello, welcome to the video on network policy objects in this video. We'll talk about what network policy objects are and how to use them with an example. Let's first understand what network policy objects are. Network policy objects will allow you to restrict the traffic flowing into your application. If you are a service receiving traffic, you can put restrictions in terms of the traffic only from other parts which match so and so labels or these other namespaces that match so and so labels. If you are a part or a service that is getting traffic, you can decide where you want to get the traffic from. So it's like a virtual firewall that you can define within OpenShift. To understand this, let's work through an example as it is easier to see the power of it when you look at it from the practical sense. I am using a bunch of microservices that have deployed on my OpenShift cluster. If you have followed my previous video series on building and running microservices on OpenShift, this is the same exact example, but for others I'll give a quick review of how it works. When you access the application, it hits a microservice that will serve the UI and this microservice is written in PHP and it throws the HTML back. This application will allow you to register as a user and once the user is registered, you can login as that user and all other registered users will be your friends and you can access their tweets. A very simple example. The part that serves the UI is a PHP application. Then once you get the UI, in order to register yourself, you'll fill in some details on the screen and then you'll press and submit at that point of time the user gets registered and there is a backend registration service that exposes a RESTful API which this UI will call and that is written in Node.js. The registered user is saved into MongoDB which runs as another part. So basically this PHP front-end service is a part. The Node.js is a part. MongoDB is a part where the data is persisted. Once the registration is successful, it also sends an email and for email it uses an infrastructure service, an email service and this email service is written in Python. That is another part and it sends an email using Gmail and once the email is sent, it also persists the email logs into a MySQL database that is behind. So email microservice has its own database. Once you log in, you can look at the tweets. So when you view the tweets, you will be accessing the Twitter service. This is written in Java. It runs on Tomcat and this guy goes and pulls the tweets for a particular user and it pulls back and shows it on the screen. That's the application. The reason it is written as separate microservices is just to show an example of multiple microservices all running together. These are all polyglot microservices. Each one written in a different language. Some of these microservices have their own local small databases. Another thing to note is that I have divided these microservice to deploy in three different OpenShift projects. The front-end microservice is deployed in a project MS client. The back-end microservices, the user registration and the Twitter microservice, these are deployed in a project with name MSServices and the email service, hoping that this is written by some other team and it will be used by different applications, the email microservice is running in the project MSInfra. So you can see here that there is a MSClient project where the front-end app is running. There is one instance running here and there's a URL. Here is a services project where there is user registration back-end service and the Twitter service running here and the user registration back-end service also writes data to this MongoDB and this third project MSInfra that is running email service that would write data to MySQL database. Now let's start using this application. Let's say I register a user here. I'm doing my Twitter account details here and then I'll click on the register now. Registration is successful. Now I log in as a user one successfully logged in. It shows me the friend's list. Now I can get tweets for other users who are my friends and it shows me the list of tweets. So the application seems to be working pretty well, but the front-end developer has put in a hack in this code and I'll show you what that is, run hack.php. I see a list of all the emails sent and when you look at the code, there is a hack.php file. This is connecting to the MySQL database that is behind the microservice and it is getting a list of all the emails from the database directly. So while the front-end developer is not supposed to access that database and just make API calls, just because he has been able to access it, he has output in a hack code here. So how do we avoid this situation, right? This is where network policy is coming to play. So we are going to put in a network policy that defends this MySQL database from receiving any requests from anything other than the email microservice. You will define a policy and we give a name to the policy here. I'm calling it allow3306. You can call it anything you want. You would say that for this part and I have applied this label called app equal to MySQL to this part. I would only allow ingress only the parts that have this label as app equal to email service, which is this part will be allowed to make calls to this part and all other calls will be rejected. That's how the call from this hack PHP will be rejected. Let's apply that and see what happens. Here is the network policy that I just explained. Now I'm creating this network policy in the MSInfra project where the email service and the MySQL database are running. So once I create this policy, now let's go back and check if this hack code grows through. It's waiting and it says time out. So the network connection is now prevented. So with this approach, we have stopped illegal connections coming to this MySQL database. Only the connections coming from the email micro service are allowed. So far so good. But how do we make our entire application secure? In order to make the whole application secure, we'll start with default deny policy on each project. So now we have three projects. We'll first apply default deny on the three projects. What it will do is it will make all connections impossible. It won't allow calls coming into any parts, whether they are within a project or the calls are coming from outside the project. All ingress traffic to any parts is rejected. Then we'll work on opening up the connections to each individual part. So clearly we'll create the network policy objects that allow connections to each of the parts or services. And you'll say that, hey, these connections coming from so-and-so specific location are allowed. So once we set up these connections, now the default prevention will prevent all illegal connections and only allowed connections that we are making a choice for are set up as rules to allow. Let's use the application and see. You can see that the application is working. So now we'll apply default deny rules. So I'm applying MS client project, services project, and infra project. Now if I try to access the application, it says application is not available. So the default deny policy has restricted all connections coming into this application. Now we will set up individual policies that allow specific traffic to specific parts. This policy allows any connections to the front-end service. This is the PHP service, and it allows any connections made to port 8080. Now that the policy is applied to allow 8080 traffic coming and hitting the front-end part of the application, now the front-end should be back up, but this front-end will not be able to make any calls to any other services, so none of the other things would work. This policy will allow connections to the user registration back-end service. I'm applying this policy to MS services project. This policy is to allow connections to the Twitter API, and this policy is to allow your user registration service to make calls to the MongoDB database. The policies that we have applied so far are between the pods within a project. So we have, for example, the user registration service being able to make a call to MongoDB, but they are not crossing the namespaces or not crossing the projects. The next one we are going to address is across the projects. So your email service is in a different namespace called msinfra, but it has to get calls from the other namespace, which is the MS services projects. If you look at this example here, we are allowing the email service to be called from a project that has so-and-so label. Let's look at the list of projects with labels. So the project MS services has the label as project user registration services, and this is the exact label we are using in that network policy to allow connections to MS services. So we have connections to MS Infra project from another project that has so-and-so label as shown here. We'll now create this policy in the MS Infra project. So now the entire application should be working. Now if I register, I should receive an email. This shows that I got an email just now. So to summarize what we have learned, we learned how to use network policies. We have learned that we can start with default deny all connections to any services running within a project, and then we can open up specific connections to specific services using labels deployed under part selectors. That way, only the connections that are supposed to be made to your services will be. The code that I have used for building these microservices and the policies that I have used to set up are all available in a Git repo that I'll be posting along with this blog. So look at the blog, you'll find the links. I hope you enjoyed this video. Thanks for watching.