FairwindsOps / polaris

What happened?

If I have the file structure as follows:

manifests/pod_dev.yaml
manifests/pod_prod.yaml

with the same Kubernetes object definition but different specs

When running polaris audit --audit-path=manifests it outputs:

{
  "PolarisOutputVersion": "1.0",
  "AuditTime": "2023-03-07T10:43:15-03:00",
  "SourceType": "Path",
  "SourceName": "manifests",
  "DisplayName": "manifests",
  "ClusterInfo": {
    "Version": "unknown",
    "Nodes": 0,
    "Pods": 0,
    "Namespaces": 0,
    "Controllers": 2
  },
  "Results": [
    {
      "Name": "test-pod",
      "Namespace": "",
      "Kind": "Pod",
      "Results": {},
      "PodResult": {...},
      "CreatedTime": "0001-01-01T00:00:00Z"
    },
    {
      "Name": "test-pod",
      "Namespace": "",
      "Kind": "Pod",
      "Results": {},
      "PodResult": {...},
      "CreatedTime": "0001-01-01T00:00:00Z"
    }
  ],
  "Score": 50
}

In this structure, it is not possible to link the PodResult to the file it was defined.

What did you expect to happen?

For each PodResult to contains the file path from where they were originally defined

How can we reproduce this?

manifests/pod_dev.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  automountServiceAccountToken: true
  serviceAccountName: test
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

manifests/pod_prod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  automountServiceAccountToken: true
  serviceAccountName: test
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    resources:
      limits:
        cpu: 100m
      requests:
        cpu: 100m

polaris audit --audit-path=manifests

Version

Polaris version:7.3.2

Search

I did search for other open and closed issues before opening this.

Code of Conduct

I agree to follow this project's Code of Conduct

Additional context

This could probably be a feature request, not a bug... feel free to re-label it

I've looked at this and discussed a bit with @rbren. We currently make the association between a ResourceProvider and the audit results. In the case of the directory option, ResourceProvider.Resources contains every valid YAML file residing in the provided directory.

In your example, polaris audit --audit-path=manifests just gives a ResourceProvider with a Path of manifests. As mentioned elsewhere, this requires quite a bit of refactoring to make that association. I am thinking that we modify ResourceProvider.Resources to be a struct that encapsulates the source YAML as it does now, plus some additional metadata that would include the file path. And hopefully that does not break support for #505

I think we want to add Filename to the GenericResource struct

polaris/pkg/kube/resource.go

Line 37 in d55cd4b

type GenericResource struct {

Not able to determine which PodResults belong to each file when auditing a directory