-
Epic
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
Log Forwarding Tenancy
-
To Do
-
OBSDA-320 - ClusterLogForwarder configuration by namespace admin so each project can configure their log sink according to their needs and requirements
-
OBSDA-320ClusterLogForwarder configuration by namespace admin so each project can configure their log sink according to their needs and requirements
Goals
- Introduce new CRD that allows individual namespace owners (aka tenants on OpenShift) to configure where Logging should send all logs belonging to that namespace.
- Introduce dedicated roles that give users the ability to create and manage the new CR inside their allowed namespaces.
Non-Goals
- This epic does not cover additional support for specific third party systems.
Motivation
The Log Forwarding API is currently scoped to the entire cluster only and the CR is shared across all tenants. In a multi-tenant environment, having all tenants gain access to the same CR is a big risk since 1) since other could accidentally change/delete other tenant configurations or 2) see authentication details or other "personal" information. To reduce that, every tenant should have the ability to create their own, dedicated CR for configuring log forwarding.
Alternatives
Administrators can fully manage the single CR for all tenants and have RBAC in place so that no one can access that in the first place. Unfortunately, that would add additional toil for the cluster admin but is a possible way to circumstance the tenancy problem.
Acceptance Criteria
- Verify that only users with the given role can create, view and delete the new dedicated CR.
- Verify that a user can configure everything that's already possible with the application input type inside the ClusterLogForwarder.
- Verify that there are no regression for forwarding to systems part of the support matrix.
Risk and Assumptions
- [Assumption] Tenancy-based log forwarding is really just important for container/application logs.