The module lifecycle stage: Experimental
The module has requirements for installation
Before enabling the module, you need to allow the use of experimental modules in the deckhouse ModuleConfig. To do this, set the allowExperimentalModules parameter to true.
Examples of using security policies
-
The example of a network security policy for a web application allowing incoming HTTP and HTTPS requests and outgoing requests in postgresSQL:
apiVersion: neuvector.com/v1 kind: NvSecurityRule metadata: name: web-app-security namespace: production spec: target: policymode: Protect selector: name: nv.web-app.production criteria: - key: service value: web-app.production op: "=" - key: domain value: production op: "=" ingress: - action: allow name: allow-http selector: name: ingress-controller criteria: - key: service value: nginx-ingress op: "=" ports: tcp/80,tcp/443 applications: - HTTP - SSL egress: - action: allow name: allow-database selector: name: nv.database.production criteria: - key: service value: database.production op: "=" ports: tcp/5432 applications: - PostgreSQL -
The example of a global policy that denies SSH access to all containers in a cluster:
apiVersion: neuvector.com/v1 kind: NvClusterSecurityRule metadata: name: global-ssh-restriction namespace: neuvector spec: target: selector: name: containers criteria: - key: container value: "*" op: "=" ingress: - action: deny name: deny-external-ssh selector: name: external criteria: [] ports: tcp/22 applications: - SSH process: - action: deny name: ssh path: /bin/ssh -
The example policy blocking deployment to system namespaces:
apiVersion: neuvector.com/v1 kind: NvAdmissionControlSecurityRule metadata: name: local namespace: neuvector spec: config: enable: true mode: protect client_mode: service rules: - action: deny criteria: - name: namespace op: containsAny path: namespace value: "kube-system,kube-public" comment: "Blocking deployments to system namespaces" -
The example of a reusable group, this group can be referenced in policies via target:
apiVersion: neuvector.com/v1 kind: NvGroupDefinition metadata: name: production-web-services namespace: neuvector spec: selector: name: nv.web-services.production comment: "Production web services group" criteria: - key: service value: web-services.production op: "=" - key: domain value: production op: "="
Mapping Dex groups to NeuVector roles
The following ModuleConfig snippet shows how to assign cluster-wide and namespace-scoped NeuVector roles based on the user’s Dex groups:
apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
name: neuvector
spec:
enabled: true
version: 1
settings:
auth:
allowedUserGroups:
- neuvector-admins
- developers
defaultRole: reader
groupRoleMapping:
- group: neuvector-admins
globalRole: admin
- group: developers
globalRole: none
roleDomains:
admin:
- dev-team-a
- dev-team-b
reader:
- stagingHow NeuVector evaluates this:
- Members of the
neuvector-adminsgroup receive the globaladminrole and can manage the entire cluster. - Members of the
developersgroup receive no global role but becomeadminin namespacesdev-team-aanddev-team-b, andreaderinstaging. - Anyone in
allowedUserGroupswho matches none of the entries above falls back toauth.defaultRole(readerhere). auth.allowedUserGroupsis enforced by Dex before a user reaches NeuVector — make sure the same groups are declared in the correspondingDexProvider.
Running the NeuVector Scanner standalone
See the FAQ entry How to run a one-off vulnerability scan with NeuVector Scanner.