Add user tag prefix to in_forward plugin
- Dominant language
- Ruby
- Stars
- 13.6k
- Forks
- 1.4k
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 20
Description
### Is your feature request related to a problem? Please describe.
Hello,
We're trying to use forward plugin for multi-tenant configuration.
So each tenant would have it's own username and password.
It is basically described in [in_forward_users.conf](https://github.com/fluent/fluentd/blob/master/example/in_forward_users.conf) and [out_forward_users.conf](https://github.com/fluent/fluentd/blob/master/example/out_forward_users.conf) config examples.
What we also want - is to ensure that tenant1 won't send (audit) logs on behalf tenant2.
So, want to add `user_tag_prefix` to security section on server side (in_forward).
### Describe the solution you'd like
Current configuration ([in_forward_users.conf](https://github.com/fluent/fluentd/blob/master/example/in_forward_users.conf)):
```
@type forward
self_hostname input.testing.local
shared_key secure_communication_is_awesome
user_auth yes
username user1
password yes_this_is_user1
username user2
password yes_this_is_really_user2
```
Desired configuration:
```
@type forward
self_hostname input.testing.local
shared_key secure_communication_is_awesome
user_auth yes
user_tag_prefix yes #### NEW
username user1
password yes_this_is_user1
username user2
password yes_this_is_really_user2
```
As a result, tag would have prefix with username:
Original tag coming from user1: `auditlog`
Desired tag after `user_tag_prefix`: `user1.auditlog`
### Describe alternatives you've considered
Nothing
### Additional context
_No response_
Contributor guide
Research direction
Start with the in_forward plugin and the referenced example/in_forward_users.conf configuration, then trace where authenticated users and incoming tags are handled. The change is done when enabling user_tag_prefix makes user1's auditlog become user1.auditlog while preserving the existing authenticated forwarding behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- backend, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100