Motivation
I think this could be a good thing to make the falcoctl configuration to be rendered as a secret object rather than a configmap as it may contain sensitive information, for instance the registry.auth section:
Sample falcoctl.yaml content:
artifact:
allowedTypes:
- plugin
follow:
every: 6h
falcoversions: http://localhost:8765/versions
pluginsDir: /plugins
refs:
- container:0.6.3
- k8saudit:0.16.0
- json:0.7.3
rulesfilesDir: /rulesfiles
stateDir: /artifactstate
install:
pluginsDir: /plugins
refs:
- container:0.6.3
- k8saudit:0.16.0
- json:0.7.3
resolveDeps: true
rulesfilesDir: /rulesfiles
stateDir: /artifactstate
indexes:
- name: falcosecurity
url: /etc/falcoctl-custom/index.yaml
backend: file
registry:
auth:
basic:
- password: __some_redacted_password__
registry: __some_redacted_registry_endpoint__
user: app_reguser
Feature
I think this could be a good thing to make the falcoctl configuration to be rendered as a secret object rather than a configmap as it may contain sensitive information, for instance the registry.auth section.
Alternatives
No alternatives for a security concern.
Additional context
FeatureRequest was initially open in falcosecurity/charts repo as issue falcosecurity/charts#977 and is now moved to current repo due to contribution policy evolution.
Motivation
I think this could be a good thing to make the falcoctl configuration to be rendered as a secret object rather than a configmap as it may contain sensitive information, for instance the registry.auth section:
Sample falcoctl.yaml content:
Feature
I think this could be a good thing to make the falcoctl configuration to be rendered as a secret object rather than a configmap as it may contain sensitive information, for instance the registry.auth section.
Alternatives
No alternatives for a security concern.
Additional context
FeatureRequest was initially open in falcosecurity/charts repo as issue falcosecurity/charts#977 and is now moved to current repo due to contribution policy evolution.