fix(router): add auth header for workload manager#186
fix(router): add auth header for workload manager#186volcano-sh-bot merged 2 commits intovolcano-sh:mainfrom
Conversation
Summary of ChangesHello @acsoto, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a critical security enhancement by implementing an authentication mechanism for communications between the Router and the Workload Manager. It ensures that sandbox creation requests are properly authorized, allowing the Workload Manager to enforce its security policies by utilizing either an API token or a Kubernetes service account token. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request correctly adds an Authorization header to requests sent from the router to the workload manager, which is an important security improvement. The implementation correctly prioritizes the API_TOKEN environment variable before falling back to the service account token. I have one suggestion to simplify the error handling logic in loadWorkloadManagerAuthToken. However, a significant concern is the absence of unit tests for this new functionality. Tests should be added to verify that the token is loaded correctly from both sources and that the Authorization header is properly set on outgoing requests.
There was a problem hiding this comment.
Pull request overview
This PR adds authentication support for Router->Workload Manager communication by including an Authorization header with a Bearer token. The token is sourced from either the API_TOKEN environment variable or a Kubernetes service account token file.
Changes:
- Added
loadWorkloadManagerAuthToken()function to read auth tokens from environment or service account file - Modified
createSandbox()to set Authorization header when token is available - Defined constant for standard Kubernetes service account token path
acsoto
force-pushed
the
fix-router-wm-auth-header
branch
from
29056c2 to
7ffe317
Compare
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #186 +/- ##
==========================================
+ Coverage 35.60% 36.00% +0.39%
==========================================
Files 29 29
Lines 2533 2558 +25
==========================================
+ Hits 902 921 +19
- Misses 1505 1511 +6
Partials 126 126
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
acsoto
force-pushed
the
fix-router-wm-auth-header
branch
from
7ffe317 to
b14c363
Compare
Signed-off-by: Zhou Zihang <z@mcac.cc>
acsoto
force-pushed
the
fix-router-wm-auth-header
branch
from
b14c363 to
359fbe3
Compare
hzxuzhonghu
left a comment
hzxuzhonghu
left a comment
There was a problem hiding this comment.
Thanks for the fix! Adding the Authorization header from API_TOKEN / service account token makes sense, and the tests cover env/file/missing/error cases well.
Non-blocking suggestions:
- Consider caching the token read if sandbox creation is frequent.
- If token file is missing in some deployments, a lower-verbosity log might avoid noise.
LGTM otherwise.
| return nil, fmt.Errorf("failed to create HTTP request: %w", err) | ||
| } | ||
| req.Header.Set("Content-Type", "application/json") | ||
| if token := loadWorkloadManagerAuthToken(); token != "" { |
There was a problem hiding this comment.
So with this PR, the router will created session for us by default and the 401 issues I mentioned before will not happen again?
There was a problem hiding this comment.
I think so because SDK uses this logic sdk-python/agentcube/clients/control_plane.py to create
if token:
self.session.headers["Authorization"] = f"Bearer {token}"
pkg/router/session_manager.go
Outdated
| } | ||
|
|
||
| func loadWorkloadManagerAuthToken() string { | ||
| if token := strings.TrimSpace(os.Getenv("API_TOKEN")); token != "" { |
There was a problem hiding this comment.
This is not complete, how does this work with workloadmanager
There was a problem hiding this comment.
SDK uses the same logic sdk-python/agentcube/clients/control_plane.py
token_path = "/var/run/secrets/kubernetes.io/serviceaccount/token"
token = auth_token or os.getenv("API_TOKEN") or read_token_from_file(token_path)
...
if token:
self.session.headers["Authorization"] = f"Bearer {token}"There was a problem hiding this comment.
WM pkg/workloadmanager/auth.go
authHeader := c.GetHeader("Authorization")
...
parts := strings.SplitN(authHeader, " ", 2)
if len(parts) != 2 || parts[0] != "Bearer" { ... }
token := parts[1]
authenticated, serviceAccount, err := s.validateServiceAccountToken(...)
tokenReview := &authv1.TokenReview{ Spec: authv1.TokenReviewSpec{ Token: token } }
result, err := s.k8sClient.clientset.AuthenticationV1().TokenReviews().Create(...)There was a problem hiding this comment.
I mean if the API_TOKEN is injected from a thirdparty identity provider, how should workload manager validate it
There was a problem hiding this comment.
That's a valid point. After reviewing the implementation, I’ve confirmed that WM now exclusively accepts K8s TokenReview with system:serviceaccount:*. Both the Router and SDK currently utilize ServiceAccount tokens. The API_TOKEN mentioned in previous versions of the SDK and documentation was a legacy feature; I have removed it to prevent further confusion.
acsoto
force-pushed
the
fix-router-wm-auth-header
branch
from
6196507 to
efa073c
Compare
Signed-off-by: Zhou Zihang <z@mcac.cc>
acsoto
force-pushed
the
fix-router-wm-auth-header
branch
from
efa073c to
da42071
Compare
|
Legacy |
|
/lgtm |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hzxuzhonghu The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind bug
What this PR does / why we need it:
Adds Authorization header for Router->Workload Manager sandbox creation using service account token, so WM auth works when enabled.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Router now reads /var/run/secrets/kubernetes.io/serviceaccount/token for WM calls.
Does this PR introduce a user-facing change?: