Security Policies with Kubernetes (PKS and NSX-T)
Even thinking about security and microservices can be overwhelming, and if you are part of the security team, you are probably thinking…" What in the world? Now the infra team provides all these containers for the development team and all of a sudden my dev guy is using some Kube command to push security policies into NSX-T, dynamically!!!
If you saw all the demos at VMworld, you are probably thinking that security policies are being handled by developers. But is not quite like that.
Let's go over some of the details with security policies, PKS, PAS and NSX-T. So the first thing to be clarified is, there are two levels of Security Policies, there are "K8's network" level security policies, and there are overall security policies.
The "network" security policies (these are how they are called in PKS) are handled by the developer, and are done via the kubectl command line and dynamically pushed to NSX-T. The "overall" policies are still handled by security team by creating NS-groups, predefine rules, labels and policies.
Let me show you the difference.
Policies Created by K8's Admin
First let's take a look at the steps to create a namespace, predefine labels and apply a policy from the K8s admin point of view. These are policies that were already used to create. When developing apps they already know what ports need to be used for communication, and most of the time use templates. The major difference here is, now, the services are split in multiple containers, so they still need to make sure the services are talking to each other. This is nothing new for developers.
Figure 1- Creating a namespace
Figure 2- Creating security group and labels
Figure 3- Creating a k8s Network Policy
Once the Network Policy is applied, NSX will dynamically create source & destination Security Groups and apply the right policy.
Figure 4- CLI executed by k8s admin
This command is done by the k8s admin and will push the policy into NSX, but remember that this policy is for allowing communication between the services in those containers and opening port 80 for the web.
And this is what it will look like in NSX-T
Figure 5 - NSX-T view of the dynamically created policy.
So that is the dynamically created policy by the developer, as before they were already doing those policies to make their services work and the APP talk to DB and WEB.
Policies Created by NSX-T Security Team
So now take a look at how the overall polices are implemented by the security team in NSX-T. Policies can be created on a very granular way and the security team still decide and apply overall polices to the infrastructure.
NSX-T uses NSGroups to group applications. NSGroups are granular to the level of an Application in the PAS or PKS.
NSGroups can be used to group multiple instances of an application to be used for the same purpose, such as Development, State, Canary and Production. By doing so, you can apply policies to each group of application instances. Since NSGroups also allow nesting, it's possible to further group a bunch of similar applications into a larger set.
If you go under Inventory on the main menu of NSX-T you will be able to create groups, IP-sets, MAC-sets, pools and also able to look into services. You are also able to add virtual machines to groups and have a lot of granularity to build policies.
Figure 6 - Creating a membership criteria for a group
Once you have membership criteria then you can create policies based on the NSGroup and rules can be added to the firewall.
Also physical instances can be added to policies.
Figure 7 - Physical SQL databases being added to Group for Security Policies
Figure 8- Security Policy for DB created by Security Team.
Summary
The Security Team still has all the control over policies and can choose to implement policies as granular as they want. And K8s admin can apply polices to control their traffic between namespace and containers.
