Using Timescape UI, part of Isovalent Enterprise Platform, for network policy management, you can now perform the following actions: View and track network policy create, update and delete per namespace Create new network policies from existing network flows Compare and differentiate policy changes across time periods * Edit existing network policies using the in-built editor ready to be applied to your cluster manually or via a gitops workflow Introduction Let's dive into some of the updates around policy management and policy editing in Timescape 1.18. So I think you're all going to be familiar with one of the features that we've added in previous releases which is the ability to visualize network policies in the Timescape flow information which is really handy to help troubleshoot when network policies are applied updated or even removed from a cluster as well. So here in my cluster that I set up yesterday, we can see when we've added a number of policies in place into my environment, all these policies sit into the same namespace. At the moment, we've kind of got minimal filters in place we're just looking at the cluster here and we can see we've got lots of cluster traffic going on inside of the cluster and also directional arrows to show egress outside of that cluster as well but I can further refine that by selecting my cluster name. I've only got the single cluster inside of my environment. Say it's not a multicluster setup and I'm just going to look at my namespace that I'm interested in this built out my service map and again, I can see that orange dot stays in place because the policies were used for this particular namespace if I chose a different namespace, that orange dot would have disappeared because it's not part of the available filter. So again I can see all those policies. I can click and view into those policies straight away but we're going to take a moment before we look into that in more detail because one of the other areas that I can now do as well in this. Policy configuration release is I can click on the available flows. I can also then click on the actions tab and we can see here the ability to create a network policy from that particular observed flow as well. So let's just click into that first and foremost and we'll go back through the rest of the network security policy features tab so straight away we can see that I have a view here of the policy that will be created and then I can start to edit that as I'm as I like further as well. So straight away it's going to have a generic name created so that as a human I can add that. So I can either do that here by adding it here test policy click to add and then we can see it's going to update it here as well. Now what we need to be really important of is making sure that we set like where the namespace would be and any endpoint selectors as well because ultimately it's going to select all endpoint selectors and it's going to look at the traffic of either egress or ingress we selected an egress flow. So at the moment this is for all endpoint selectors going to our core API on this particular port, not only do I can click in this kind of service map type view from a policy, but I can also manually edit as well, here. So, if I wanted, I can add another line in and I'm going to manually add in the namespace instead rather than do it through kind of that guided selector here as well. Once I'm done on this, I can click to download this policy and then I can either apply it to my GitOps workflows or I can manually apply it to. Timescape observability my cluster as well if I wanted this was a highly requested feature as we migrate from the Hubble Enterprise UI which is now being end of life from Cilium Enterprise 1.18 release. Going forward, the Timescape UI is the default UI and the only supported UI going forward if you're still running an older version of Cilium Enterprise then you can still use the Hubble Enterprise until you're ready to migrate and transition into the new Timescape UI. So if I click now just into the policies view, we can see I maintain that same filter that was available inside of my environment we still got the same features available as previous where I can see the flows. So, I can click through them or I can manually go through this list as well and I can use the compare feature to see the available policies as and when they come in there's been some enhancements in the background as well in terms of rolling up the policy updates that they're always available even if there's no changes outside of the time to live value that's been set as well. So, you won't lose them that fixes a previous behavior that we saw causing problems as well and once again, I've also got the ability here to click the edit function and I can edit this policy the same way that I edited it before in the view where we click to add a policy and then I would download that and then I can reapply that and it would update this inside of my cluster. So why don't we edit this policy in here and then apply it to my cluster? So here all we're going to do is change the ports to 80 80 and I'm going to add in a six here and let's remove a zero from here as well. So we've edited ports basically going to break some traffic. I'm going to download this. So we can see here it's downloading to the crawler location. crawler file outbox that's the name of the policy. Configure Timescape policy itself. itself. So now in my terminal, I'm just going to apply that file to my cluster. So we can now see that it's configured the existing policies which changed that and then we're just going to wait for that policy to update and then we can show that differential view in my environment we've just give it a moment there for that policy to be ingested into our timescape environment. So now if I look I can see an updated view. So I'm going to look at the compare of when it was first created and then I'm also going to look at the updated dates as well if I scroll down we can now see that the loss configurations being applied. So we're pulling that data through it's been changed since it's first created and then we can see those changes where basically the port 80 was converted into port 8080. Validate Timescape And we remove that zero from that port as well this helps us as a platform owner or a security or a network engineer working with Kubernetes because we can then start to map out and understand where there may be changes inside of our platform that then affect the flows where traffic is allowed or denied between our workloads as well and then finally, if I just hover over in the top right hand comma there, we can also see here that we've got that. Conclusion policy updates being shown along that flow linear graph view as well and that just wraps up a quick walkthrough of policy management using the Hubble Timescape UI thank you.