[Feature Request] - Operator FalconNodeSensor API Secrets

[darktempla]

Overview

As a user I would like to reference a secret to provide the falcon_api.client_id and falcon_api.client_secret sensitive values to the FalconNodeSensor object so that I can safely store it in source control.

Extra Information

• Using version 0.9.1 of the Operator on OpenShift.
• This is an enabler from a GitOps point of view and allows users to leverage other secret management solutions to create the secret object and keep sensitive information out of source control.
• This change would bring feature parity to the operator aligning it to the HELM chart.
  ** Move CID to Secret Object falcon-helm#87

[redhatrises]

Hello,

Please use the imagePullSecrets, or if using git, it is recommended for these values to be injected by a post-merge job from CI/CD or GH/Gitlab secrets that injects the values in into the CR config and updates the deployment post-merge of a PR. Otherwise, we don't have plans to implement this since imagePullSecrets and git with CI/CD and/or GH/Gitlab secrets should be used for this. The forthcoming helm chart for the operator will also be another way to handle this as well.

[tskinner-oppfi]

Forgive my ignorance as I'm still trying to understand the differences between using the falcon API and using an image from a registry. I would like to use the falcon api but not being able to specify a secret that stores the client_secret is a blocker. Can I use image pull secrets without specifying a custom image?

apiVersion: falcon.crowdstrike.com/v1alpha1
kind: FalconNodeSensor
metadata:
  name: falcon-node-sensor
spec:
  falcon:
    cid: <CID>
  node:
    imagePullSecrets: <IMAGE_PULL_SECRET>

Why is recommended to not use a secret if using git? We use dozens of helm charts and a handful of operators and none of them dictate that users should not store secrets in secrets. They allow referencing native k8s secrets in CRDs and charts.
That being said they are all open source so maybe I'm misunderstanding how this operator is supposed to work given some of the constraints here.

[aprohorov-callsign]

We're using the Operator on GKE with Autopilot, which is prevent us to use Flacon image from a private repository (at least 2 weeks GKE support isn't able to add our repository the an allow-list as mentioned in the doc). So we have to use client_id and client_secret.

[miguelcvent]

I found a bypass by using Kyverno. Kyverno is a configurable AdmissionController, so it will modify the fields on the fly. This is just a patch, because the usual solution is the operator to allow specifying secret refs directly.

The kyverno policy required to do this is:

apiVersion: kyverno.io/v2beta1
kind: ClusterPolicy
metadata:
  name: set-creds-on-falcon-resources
  annotations:
    policies.kyverno.io/title: Set falcon credentials from secret
    policies.kyverno.io/category: Other
    policies.kyverno.io/severity: medium
    policies.kyverno.io/subject: Pod,Deployment,Secret
    kyverno.io/kyverno-version: 1.9.0
    policies.kyverno.io/minversion: 1.9.0
    kyverno.io/kubernetes-version: "1.24"
spec:
  rules:
    - name: set-creds
      match:
        any:
          - resources:
              kinds:
                - FalconAdmission
                - FalconContainer
                - FalconImageAnalyzer
                - FalconNodeSensor
      context:
        - name: apikey
          apiCall:
            urlPath: "/api/v1/namespaces/{{request.namespace}}/secrets/example"  # Remember to change this reference!
            jmesPath: "data"   
      mutate:
        patchStrategicMerge:
          spec:
            falcon_api:
              client_id: '{{ apikey | client | base64_decode(@) }}'
              client_secret: "{{ apikey | secret | base64_decode(@) }}"

And this is the corresponding secret:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: example
data:
  secret: ZW5jb2RlZCBleGFtcGxlCg==
  client: Y2xpZW50IGlkCg==

NOTE: Despite kyverno documentation says {{request.namespace}}, it didn't worked for me and I finally had to hard-code the namespace where the secret lives on.

[evanstoner]

Thank you for the example @miguelcvent !