vmware / kube-fluentd-operator

Auto-configuration of Fluentd daemon-set based on Kubernetes metadata
Other
319 stars 99 forks source link

How to use the kube-fluentd-operator to run separate instance of Fluentd - one for Infrastructure and another for Applications #106

Open sb1975 opened 4 years ago

sb1975 commented 4 years ago

Is your feature request related to a problem? Please describe. Need a solution for Fluentd in a multitenant environment, specific concern is Whether we can restrict a separate Fluentd instance for each tenant in its own namespace. A simple scenario : Keep Infrastructure and Application pods separate. run separate instance of Fluentd - one for Infrastructure and another for Applications. Describe the solution you'd like A clear and concise description of what you want to happen. Enhance the logging-operator to allow creating a seperate instance of Fluentd per namespace. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

carpenterm commented 4 years ago

@sb1975 the goal of KFO is to enable multiple teams using different namespaces to use a single instance of Fluentd. Could you please explain why you would need separate Fluentd instances?

sb1975 commented 4 years ago

@carpenterm , our use case is as mentioned above : Isolation of Infrastructure namespaces (infrastructure pods ) with other Tenant namespaces (pods) Lets say I have some infrastructure components running within namespaces like kube-system,prometheus,openstack,undercloud,ceph and also I need to continue to capture the logs from the host: /var/log/auth.log /var/log/calico/audit/tsee-audit.log /var/log/calico/flowlogs/flows.log /var/log/kern.log /var/log/libvirt/libvirtd.log /var/log/libvirt/qemu/*.log /var/log/syslog

Then I need to capture logs for my tenants/application pods(which are untrusted) and I need to ensure as much isolation and validation that they cannot access more than they need. So they cannot change their configmap with any value they want, they should not be able to capture logs from infrastructure namespaces.

Now I see we have a restriction in place as below "The only allowed directive is of type mounted-file" so the tenant namespace configmap is restricted in that sense.

So the question is then how do we ensure the existing functionality and isolation of the Infrastructure is maintained alongside the Tenants/Application namespaces.