mirror of
https://github.com/FairwindsOps/polaris.git
synced 2026-05-09 02:36:43 +00:00
75f70352ba
**Changes** - Refactored the way controllers work to be an interface - Added configurable controllers to include in scans - Added daemonsets, jobs and cronjobs in scans - Added `ReplicationController` type controllers to the supported list - Adjusted logic for failed YAML parsing to bubble up errors - Added better logic for calculating summaries on cluster wide results - Relocated responsibilities for counting types into validators vs spreading it around more packages - Fixed bug where cronjob parsing was using wrong KIND - Added fixtures for mocking new controller types - Added example yamls to test scanning files - Added functions to NamespacedResult(s) to reduce code complexity deep set iterations - Refactored how results get added to namespacedresults so adding more later is easier - Minor signature changes for interface implementing structs for controllers
1.3 KiB
1.3 KiB
Networking
Polaris supports a number of checks related to pod networking.
| key | default | description |
|---|---|---|
networking.hostNetworkSet |
warning |
Fails when hostNetwork attribute is configured. |
networking.hostPortSet |
warning |
Fails when hostPort attribute is configured. |
Background
Although Kubernetes allows you to deploy a pod with access to the host network namespace, it's rarely a good idea. A pod running with the hostNetwork attribute enabled will have access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node. There are certain examples where setting hostNetwork to true is required, such as deploying a networking plugin like Flannel.
Setting the hostPort attribute on a container will ensure that it is accessible on that specific port on each node it is deployed to. Unfortunately when this is specified, it limits where a pod can actually be scheduled in a cluster.