[MUSIC] Hello and welcome, Orlando Gentil here. Today we will demonstrate how we can make FSS more secure. Before we start, let's understand the scenario where we going to work today. In today's scenario we have our web server that lives on the public subnet. This web server we will make it access the mount target that is on a private subnet. In that sub private net there is also private VM that it's not related to the web server. The very first thing that we're going to do is to create a security list. And see how it affects the overall environment when the web server is using it to access the mounts targets. Security lists, they're defined it for the whole subnet. When we create a security list, the rules do apply for both the mount target and the private VM. Let's take a look on the VCNs. We know that our web server is on the public subnet, so it's 10.0.0.0/24. And we have to have access to a private subnet, so we're going to put it on the security list, we're going to add the ports that are required for NFS. The source port is going to be 10.0.0.0/24 TCP and the destination ports we have all these ports here 111, 2048, 2049, 2050. We 're going to put the description here NFS, Required TCP ports, then add another rule here, where we going to have the same source. And now UDP, Hello, 111, 24a. And those are NFS required UDP ports. You're going to create a rule. Now, let's go our instance, I'll start Cloud Shell. So from the web server, we are going to check them out that we have on our FSS, Server. And, We have our file system demo, that's the file system that should be accessible by the web server. But remember that we mentioned that we have also a private VM running on the same subnet as the mount point. Let's see what's going to happen if I try to run the same command, Pointing to the privately VM IP? It also has a NFS server, that's a super confidential and it's limited to just servers on instances within the same subnet. Well, that sounds the security list left things in quite open. And the web server should not be accessing this here. This is a good scenario to show what we can do with network security groups. First thing that we're going to do is to delete the security list that we have created. So, come back to the VCN and the private subnet, We're going to remove all the NFS ports that we allowed. By doing that everything that we did was undone and we can't even access the FSS mount. Let's go now to Network Security Groups. We're going to create a Network Security Group same FSS, Access rules want to create on the same compartments and box. And we proceed the same way that we will created the Security List. The source is going to be my public subnet, Those will be the TCP ports, get a copy from my notes here. This ports are also documented on the present on the recommendation on the link that's shown here. On the documentation, they show that you have to create Ingress and Egress. The Ingress point to the destination ports, the Egress you should swap should be this port here should be the source port. This is because of the way that the the Ripple network works and some of the high availability features that we have on FSS they require that rules. We are not concerned about creating those rules here on the demo because our Ingress it's quite permissive, and it allows every single protocol so we're creating just the Ingress rules. But if you have a more tight environment, you need to create Ingress like we are demonstrating in also Egress as per the documentation. FSS, Required TCP ports we will add another rule for our UDP. The source is going to decider our private, our public subnet this time UDP, And 2048. Now that we have the Network Security Group created, we have acquired and Network Security Groups they are acquired directly on the vinex. In this case, we are going to navigation menu, storage, mount targets. Go to the mount target details. And we're going to to have the Network Security Groups option here. You're going to edit, we have our FSS access rules, Save changes. Let's see what happens now? Clear, 219 is our mount target, we can still access it. Let's see what happens if we go to our private VM and can see our super confidential mount. It's not already not showing, why? Because let me pull one image here. So instead of having a security list that is applied to the host subnet, now we have a Network Security Group. In the rules that we have there, they apply only to the vinix that it's assigned to the mount target. There's, by doing this, the web server, we will not be able to read anything on the private VM. Now, back to the web console, we can see that our show more command timeout. And we achieved our goal that is to make the NFS server running on the private VM inaccessible by the web server. If you want to use NS Network Security Groups with file storage from the while you create the file system, the Network Security Groups needs to be created before them. So when it's time to create the Mount Target, you can just assign the security group. But if you didn't create it's not a problem you can come at any time. And as we did change the Network Security Group option here and include the security group after the creation. So this concludes our demo for FSS and Network Security Groups. I hope you guys enjoyed, and see you in the next video.
