SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-07-01 03:33:13 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

Netbird should be able to handle the users of service account as any normal user #577

New Issue
Open
opened 2025-11-20 05:14:05 -05:00 by saavagebueno · 0 comments
saavagebueno commented 2025-11-20 05:14:05 -05:00
Owner
Copy Link

Originally created by @MohammedNoureldin on GitHub (Jan 12, 2024).

Is your feature request related to a problem? Please describe.
In self-hosted Netbird, as soon as I try to call the API of Netbird using an access token issued by my Identity Provider a service account, the whole system starts to be horribly slow (reported here https://github.com/netbirdio/netbird/issues/1461). The direct cause of this is that Netbird is not able to find the user of the service account, while such users should be recognized and handled as same as any normal user by Netburd.

To Reproduce
Steps to reproduce the behavior:

  1. In the Identity Provider, e.g. KeyCloak, create a client named "netbird-backend" that enables service account. Actually this user is probably already there because it is part of setting Netbird up.
  2. Request an access token from the IdP:
token_response=$(curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=netbird-backend&client_secret=$netbird_backend_service_user_secret&grant_type=client_credentials&scope=openid" $netbird_oidc_device_authorization_token_endpoint)

access_token=$(echo $token_response | jq -r '.access_token')
  1. Use that access token to call Netbird API:
users=$(curl -X GET https://$netbird_management_subdomain.$domain_name/api/users -H "Authorization: Bearer $access_token")

This will return 401 because the user created implicitly by KeyCloak for the service account client is not being found by Netbird.

Expected behavior
The system should not be affected by any invalid API calls.

NetBird status -d output:

logs of management:

2024-01-12T10:39:35Z INFO management/server/account.go:1543: overriding JWT Domain and DomainCategory claims since single account mode is enabled
2024-01-12T10:39:35Z DEBG management/server/file_store.go:275: acquiring global lock
2024-01-12T10:39:35Z DEBG management/server/file_store.go:285: took 640ns to acquire global lock
2024-01-12T10:39:35Z DEBG management/server/file_store.go:269: took 0 ms to persist the FileStore
2024-01-12T10:39:35Z DEBG management/server/account.go:1213: looking up user ce277538-2213-4ec5-bb96-4a4aedfa969c of account cmghd4oj5m1c73dihv1g in cache
2024-01-12T10:39:35Z DEBG management/server/account.go:1289: cache doesn't know about ce277538-2213-4ec5-bb96-4a4aedfa969c user
2024-01-12T10:39:35Z DEBG management/server/account.go:1294: cache doesn't know about 1 users from store, reloading
2024-01-12T10:39:35Z DEBG management/server/account.go:1151: account cmghd4oj5m1c73dihv1g not found in cache, reloading
2024-01-12T10:39:36Z DEBG management/server/account.go:1163: 4 entries received from IdP management
2024-01-12T10:39:36Z WARN management/server/account.go:1177: user ce277538-2213-4ec5-bb96-4a4aedfa969c not found in IDP
2024-01-12T10:39:36Z DEBG management/server/account.go:1151: account cmghd4oj5m1c73dihv1g not found in cache, reloading
2024-01-12T10:39:36Z DEBG management/server/account.go:1163: 4 entries received from IdP management
2024-01-12T10:39:36Z WARN management/server/account.go:1177: user ce277538-2213-4ec5-bb96-4a4aedfa969c not found in IDP
2024-01-12T10:39:36Z DEBG management/server/file_store.go:281: released global lock in 1.573880277s
2024-01-12T10:39:36Z DEBG management/server/account.go:1213: looking up user ce277538-2213-4ec5-bb96-4a4aedfa969c of account cmghd4oj5m1c73dihv1g in cache
2024-01-12T10:39:36Z DEBG management/server/account.go:1289: cache doesn't know about ce277538-2213-4ec5-bb96-4a4aedfa969c user
2024-01-12T10:39:36Z DEBG management/server/account.go:1294: cache doesn't know about 1 users from store, reloading
2024-01-12T10:39:36Z DEBG management/server/account.go:1151: account cmghd4oj5m1c73dihv1g not found in cache, reloading
2024-01-12T10:39:37Z DEBG management/server/account.go:1163: 4 entries received from IdP management
2024-01-12T10:39:37Z WARN management/server/account.go:1177: user ce277538-2213-4ec5-bb96-4a4aedfa969c not found in IDP
2024-01-12T10:39:37Z ERRO management/server/http/middleware/auth_middleware.go:82: Error when validating JWT claims: user ce277538-2213-4ec5-bb96-4a4aedfa969c not found in the IdP
2024-01-12T10:39:37Z ERRO management/server/http/util/util.go:80: got a handler error: token invalid
2024-01-12T10:39:37Z ERRO management/server/telemetry/http_api_metrics.go:181: HTTP response 3720184415: GET /api/users status 401
2024-01-12T10:39:37Z DEBG management/server/telemetry/http_api_metrics.go:201: request GET /api/users took 2211 ms and finished with status 401

Describe the solution you'd like
Netbird should somehow be able to deal with the users created implicitly by KeyCloak. At the moment such users are not fetched when calling the /users endpoint of keycloak, while they can be accessed when calling such users by ID. A possible solution is to explicitly make Netbird look up the ID of the user, to which the access token was issued, in case it could not be found in Netbird. This will add the possibility to use Netbird without creating any redundant user or any PAT creation, but only by using the power of IdP.

In summary, Netbird should be able to handle the users of service accounts as same as any other user.

UPDATE

At the moment it seems that users associated with service account client can be fetched only by their ID. I do not see this as an issue, as their ID is any part of the access token. So this should be used to check if the user exists or not, not only by relying on the cached fetched users.

Originally created by @MohammedNoureldin on GitHub (Jan 12, 2024). **Is your feature request related to a problem? Please describe.** In self-hosted Netbird, as soon as I try to call the API of Netbird using an access token issued by my Identity Provider a service account, the whole system starts to be horribly slow (reported here https://github.com/netbirdio/netbird/issues/1461). The direct cause of this is that Netbird is not able to find the user of the service account, while such users should be recognized and handled as same as any normal user by Netburd. **To Reproduce** Steps to reproduce the behavior: 1. In the Identity Provider, e.g. KeyCloak, create a client named "netbird-backend" that enables service account. Actually this user is probably already there because it is part of setting Netbird up. 2. Request an access token from the IdP: ``` token_response=$(curl -X POST -H "Content-Type: application/x-www-form-urlencoded" -d "client_id=netbird-backend&client_secret=$netbird_backend_service_user_secret&grant_type=client_credentials&scope=openid" $netbird_oidc_device_authorization_token_endpoint) access_token=$(echo $token_response | jq -r '.access_token') ``` 3. Use that access token to call Netbird API: ``` users=$(curl -X GET https://$netbird_management_subdomain.$domain_name/api/users -H "Authorization: Bearer $access_token") ``` This will return 401 because the user created implicitly by KeyCloak for the service account client is not being found by Netbird. **Expected behavior** The system should not be affected by any invalid API calls. **NetBird status -d output:** logs of management: ``` 2024-01-12T10:39:35Z INFO management/server/account.go:1543: overriding JWT Domain and DomainCategory claims since single account mode is enabled 2024-01-12T10:39:35Z DEBG management/server/file_store.go:275: acquiring global lock 2024-01-12T10:39:35Z DEBG management/server/file_store.go:285: took 640ns to acquire global lock 2024-01-12T10:39:35Z DEBG management/server/file_store.go:269: took 0 ms to persist the FileStore 2024-01-12T10:39:35Z DEBG management/server/account.go:1213: looking up user ce277538-2213-4ec5-bb96-4a4aedfa969c of account cmghd4oj5m1c73dihv1g in cache 2024-01-12T10:39:35Z DEBG management/server/account.go:1289: cache doesn't know about ce277538-2213-4ec5-bb96-4a4aedfa969c user 2024-01-12T10:39:35Z DEBG management/server/account.go:1294: cache doesn't know about 1 users from store, reloading 2024-01-12T10:39:35Z DEBG management/server/account.go:1151: account cmghd4oj5m1c73dihv1g not found in cache, reloading 2024-01-12T10:39:36Z DEBG management/server/account.go:1163: 4 entries received from IdP management 2024-01-12T10:39:36Z WARN management/server/account.go:1177: user ce277538-2213-4ec5-bb96-4a4aedfa969c not found in IDP 2024-01-12T10:39:36Z DEBG management/server/account.go:1151: account cmghd4oj5m1c73dihv1g not found in cache, reloading 2024-01-12T10:39:36Z DEBG management/server/account.go:1163: 4 entries received from IdP management 2024-01-12T10:39:36Z WARN management/server/account.go:1177: user ce277538-2213-4ec5-bb96-4a4aedfa969c not found in IDP 2024-01-12T10:39:36Z DEBG management/server/file_store.go:281: released global lock in 1.573880277s 2024-01-12T10:39:36Z DEBG management/server/account.go:1213: looking up user ce277538-2213-4ec5-bb96-4a4aedfa969c of account cmghd4oj5m1c73dihv1g in cache 2024-01-12T10:39:36Z DEBG management/server/account.go:1289: cache doesn't know about ce277538-2213-4ec5-bb96-4a4aedfa969c user 2024-01-12T10:39:36Z DEBG management/server/account.go:1294: cache doesn't know about 1 users from store, reloading 2024-01-12T10:39:36Z DEBG management/server/account.go:1151: account cmghd4oj5m1c73dihv1g not found in cache, reloading 2024-01-12T10:39:37Z DEBG management/server/account.go:1163: 4 entries received from IdP management 2024-01-12T10:39:37Z WARN management/server/account.go:1177: user ce277538-2213-4ec5-bb96-4a4aedfa969c not found in IDP 2024-01-12T10:39:37Z ERRO management/server/http/middleware/auth_middleware.go:82: Error when validating JWT claims: user ce277538-2213-4ec5-bb96-4a4aedfa969c not found in the IdP 2024-01-12T10:39:37Z ERRO management/server/http/util/util.go:80: got a handler error: token invalid 2024-01-12T10:39:37Z ERRO management/server/telemetry/http_api_metrics.go:181: HTTP response 3720184415: GET /api/users status 401 2024-01-12T10:39:37Z DEBG management/server/telemetry/http_api_metrics.go:201: request GET /api/users took 2211 ms and finished with status 401 ``` **Describe the solution you'd like** Netbird should somehow be able to deal with the users created implicitly by KeyCloak. At the moment such users are not fetched when calling the /users endpoint of keycloak, while they can be accessed when calling such users by ID. A possible solution is to explicitly make Netbird look up the ID of the user, to which the access token was issued, in case it could not be found in Netbird. This will add the possibility to use Netbird without creating any redundant user or any PAT creation, but only by using the power of IdP. In summary, Netbird should be able to handle the users of service accounts as same as any other user. ### UPDATE At the moment it seems that users associated with service account client can be fetched only by their ID. I do not see this as an issue, as their ID is any part of the access token. So this should be used to check if the user exists or not, not only by relying on the cached fetched users.
saavagebueno added the feature-requestidpconfig-idpself-hosting labels 2025-11-20 05:14:05 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2022 Q1
2022 Q1
accessibility
acl
agent
agent
Android
Android
api
authentik
automation
azure
battery-usage
bug
cache
client
client-ui
cloud
cloud-only
cloudflare
community
compatibility
config-idp
config-issue
connection
contribution
coturn
cross-vpn
dashboard
data-usage
distribution
dns
docker
documentation
duplicate
enhancement
enhancement
event-stream
feature-request
freebsd
getting-started
go
good first issue
gui
help wanted
home-assistant
idp
inconsistency
integration
integrations
ios
ipv6
jwt
k8s
keycloak
linux
login
macos
management-service
missing-docs
mobile
moved-internal
needs-review
netbird-ui
networking
new-platform
nginx
notification
okta
openwrt
packaging
peer-management
peer-management
peer-management
performance
postgres
posture-checks
psk
pull-request
Mirrored from GitHub Pull Request
 question
refactor
relay
release
rfc
routes
security
security-related
self-hosting
server
signal
sleep-issue
ssh
ssl
status
store
synology
system-compatibility-issue
test-suite
third-party-integration
triage
triage-needed
troubleshooting
UX
waiting-feedback
windows
wontfix
zitadel
No Label config-idp feature-request idp self-hosting
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#577
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?