security: add authorization checks to WorkflowStatsSLAHttpHandler - #16159
security: add authorization checks to WorkflowStatsSLAHttpHandler#16159adilburaksen wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces authorization checks in WorkflowStatsSLAHttpHandler by injecting ContextAccessEnforcer and enforcing StandardPermission.GET on workflow programs before retrieving run statistics. A review comment suggests simplifying the instantiation of ProgramReference by using its constructor directly instead of chaining methods via Ids.
| ProgramReference programReference = Ids.namespace(namespaceId).appReference(appId) | ||
| .program(ProgramType.WORKFLOW, workflowId); |
There was a problem hiding this comment.
Instead of using the helper class Ids and chaining multiple method calls (Ids.namespace(...).appReference(...).program(...)), you can directly instantiate ProgramReference using its public constructor. This is more direct, improves readability, and avoids the need to import io.cdap.cdap.proto.id.Ids.
| ProgramReference programReference = Ids.namespace(namespaceId).appReference(appId) | |
| .program(ProgramType.WORKFLOW, workflowId); | |
| ProgramReference programReference = new ProgramReference(namespaceId, appId, | |
| ProgramType.WORKFLOW, workflowId); |
|
@sahusanket this adds the authorization checks that are missing on WorkflowStatsSLAHttpHandler. Same shape as the other handler fixes in this batch — enforce access before returning workflow stats. Rebased against develop not long ago; happy to refresh if needed. |
Summary
WorkflowStatsSLAHttpHandlerserves workflow run statistics, run details, and run comparisons for a namespace/application/workflow selected entirely from the request path, but it did not enforce any access check before reading from theStore. The handler only injectedStore,MRJobInfoFetcher, andMetricsSystemClient, so a principal could read run statistics for workflows in any namespace without an authorization check.This change adds
StandardPermission.GETenforcement on the targeted workflow program before the data read, consistent with the sibling program/workflow handlers in app-fabric.Changes
ContextAccessEnforcervia the existing@Injectconstructor (Guice resolves it fromAuthorizationEnforcementModule; the handler binding inAppFabricServiceRuntimeModuleis unchanged).enforceWorkflowAccess(namespace, app, workflow)helper that builds the workflowProgramReferenceand callscontextAccessEnforcer.enforce(programReference, StandardPermission.GET).workflowStats—.../workflows/{workflow-id}/statisticsworkflowRunDetail—.../workflows/{workflow-id}/runs/{run-id}/statisticscompare—.../workflows/{workflow-id}/runs/{run-id}/compareAll three endpoints are read-only, so
StandardPermission.GETis the appropriate permission. The enforcement mirrors the idiom already used inProgramLifecycleServiceandArtifactHttpHandler.Testing
mvn -o -pl cdap-app-fabric -am compile— BUILD SUCCESS.