https://rancher.com/ logo
Join Slack
Powered by
Where in the Rancher UI are you expecting things t...
# neuvector_suse-security
q
Where in the Rancher UI are you expecting things to show up, and what are you expecting to see? 😉
n
Here's an example in the Rancher UI. I would expect our group definitions to show up (the ones we defined in the NeuVector UI).
q
I do not believe it's integrated quite like that
--If-- one has the NeuVector extension installed you get this view
But I wouldn't expect that you'd do any real work with those groups directly in the rancher interface.
n
Right, the idea was more to be able to quickly take a look at the CRD definition when we need to. IIRC there's a way to export the whole NeuVector config? I imagine GroupDefinitions would be there too?
q
Yeah, sorry, but that's not entirely absorbed up into the rancher interface. On a certain level, best practice dictates that you head off to a security tool to do the security.
n
Yeah no worries, I don't expect deep integration or anything, it's merely to inspect the yaml. The context is that we're trying to move away from clickops and towards having groups and rules checked out in source control so we can more easily track modifications, replicate accross clusters, etc.
Im just trying to wrap my head around how to achieve that
q
one sec
n
I think this part of the docs explains part of the process, gonna start there CRD - Custom Resource Definitions | Neuvector Docs
q
obv, this is the way in the UI
❤️ 1
Above, I'm filtering to just grab a namespace, assuming that's your app stack. Then, exporting the CRD so it can be applied to another cluster.
You notice when the UI popped up interrogating me for a mode, I asserted that in the export I want all the groups to be set to monitor mode. This is me playing out the scenario in my head that we built all these rules using the Discover mode in a test environment, and now I want to follow the development lifecycle of my application over to a QA cluster.
n
yeah makes sense
Do network rules work similarly? I dont see any export functionality for those.
q
They're in there. 😄
here's the CRDs I just expoprted in that vid above
cfgGroupsExport_20260610111426.yaml
n
Ohhh I see! Makes a lot of sense. Thanks for bearing with me 😅
q
In this scenario, you'd ensure that the name space existed on your target cluster, then you would just apply this Yammo file however you normally do things. for example 
kubectl apply -f cfgGroupsExport_20260610111426.yaml
n
Perfect, that makes it easy to work with groups and transfer those around!
q
Now, in our QA cluster, while the application is going through the QA it always would be, you will see alerts for any rule of violations, so you can be sure you've got the rules established correctly. This (Monitor) is just doing a dry run against Protect mode.
🙂
a la
And you could totally avoid any click ops kinds of things by using API commands to grab all these CRD's, and shipping them with your code, even checking these things into gitops and doing pull requests to make incremental security changes. The world is your oyster.
🙌 1
n
Thanks Jorn, with that we have a much better idea of where we're going.
q
That's awesome!
f
To Jorn's point. All of the groups live in controllers memory, unless also backed to PV, they do not exist as CRDs unless you export those, as Jorn showed in his video. Once you export and apply, you will see them as CRDs, and after that they should appear in Rancher. Then in Rancher you could setup a Nav Link to that specific CRD for easier UI access.
👍 1
🙌 1
n
Sorry if this is a dumb question, but I'm having trouble understanding how linked groups work. We have a couple of user-defined groups, and when I export them one by one, I notice that some 
NvGroupDefinition
are duplicated between exports. Won't that cause issues or conflicts? Do I need to literally export ALL groups/rules everytime theres a change to any one of them?
f
Usually, when people get to the point where they adopt gitops for their security policies they either re-export them, and use GIT for versioning, or they already figured out where to add rules, and they simply add those themselves. But otherwise, a group is a k8s CRD and as any other resource you can keep reapplying it and will change the definition
n
Im not sure I understand what you mean so I'm probably misunderstanding something. Let's say I export group A, it has some selectors defined. Then, I export group B, which also exports group A as a linked group. That means I have a duplication of group A. If I then want to modify group A, I have those two places to modify now. That doesnt sound right to me.
f
Ahhh, ok, my bad, it was misunderstanding on my side
I will need to test this out to give you an answer. All of NA sales folks are at half year QBR at the moment. I will have some time to tinker with this next week
n
Thanks 🙂
For reference, this is what Im talking about. The net result is that I end up with a group defined multiple times depending on how I export.
👍 1
@future-smartphone-18156 @quaint-candle-18606 still unsure how to proceed, please let me know if you have ideas!
Hey, still looking for guidance on this!
f
So despite the fact that NV allows you to export custom groups created by the user, those groups are just a logical way to manage different groups. If you look at the exported file of the group - you will notice that the 
policyMode/s
are set to 
N/A
. That said, the mode that will be used by NV will be defined by the actual child group.
Open in Slack
PreviousNext
Powered by