Skip to content

Latest commit

 

History

History
161 lines (125 loc) · 12.4 KB

mitigations.md

File metadata and controls

161 lines (125 loc) · 12.4 KB

Mitigation Strategies Analysis for conductor-oss/conductor

Mitigation Strategy: Worker Authentication and Authorization (Conductor-Level)

Mitigation Strategy: Worker Authentication and Authorization (Conductor-Level)

  • Description:

    1. Enable Authentication: Configure Conductor server to require authentication for worker registration and task polling. This is typically done through configuration files (e.g., application.properties or application.yml).
    2. Implement a Custom AuthManager (if needed): If the built-in authentication mechanisms (e.g., basic auth) are insufficient, implement a custom AuthManager interface. This allows you to integrate with external authentication systems (e.g., OAuth2, LDAP).
    3. Define Authorization Rules: Within Conductor, define authorization rules that map worker identities (obtained during authentication) to allowed task types or queues. This can be done through:
      • Task Definitions: Add metadata to task definitions (e.g., owner, allowedWorkers) to specify which workers are allowed to execute them.
      • Custom AuthorizationService: Implement a custom AuthorizationService interface to enforce more complex authorization logic. This service can check worker identities against a database, external authorization server, or other criteria.
      • Queues: Use different queues for different worker types and configure authorization at the queue level.
    4. **Enforce Authorization in ExternalPayloadStorage: ** If using ExternalPayloadStorage, ensure that authorization checks are performed when workers access payloads. The ExternalPayloadStorage implementation should verify that the requesting worker is authorized to access the specific payload.

  • Threats Mitigated:

    • Worker Impersonation (Medium Severity): Prevents unauthorized workers from registering with the Conductor server and polling for tasks.
    • Unauthorized Task Execution (Medium Severity): Ensures that workers can only execute tasks they are authorized to perform, preventing a compromised worker from executing arbitrary tasks.

  • Impact:

    • Worker Impersonation: Risk reduced significantly (e.g., from Medium to Low).
    • Unauthorized Task Execution: Risk reduced significantly (e.g., from Medium to Low).

  • Currently Implemented:

    • Basic authentication is enabled on the Conductor server.

  • Missing Implementation:

    • Fine-grained authorization rules based on worker identity and task type are not implemented. All authenticated workers can execute all tasks.
    • A custom AuthManager or AuthorizationService is not implemented.
    • Authorization checks within ExternalPayloadStorage are not implemented.

Mitigation Strategy: Workflow Definition Validation and Sanitization (Conductor-Level)

Mitigation Strategy: Workflow Definition Validation and Sanitization (Conductor-Level)

  • Description:

    1. Schema Validation: Define a strict JSON schema for workflow definitions. Use a schema validation library (e.g., jsonschema in Python, or a similar library in Java) within the Conductor server to validate workflow definitions before they are persisted.
    2. Whitelisting Allowed Tasks: Maintain a whitelist of allowed task types (system tasks and registered worker tasks). Reject workflow definitions that contain unknown or unauthorized task types.
    3. Input Parameter Validation: Within the schema, define constraints on input parameters for each task type (e.g., data types, allowed values, regular expressions). Validate task inputs against these constraints before task execution.
    4. Custom WorkflowDefValidator: Implement a custom WorkflowDefValidator interface to enforce more complex validation rules. This validator can check for:
      • Potentially dangerous task configurations (e.g., excessive timeouts, large input payloads).
      • Circular dependencies between tasks.
      • Compliance with organizational policies.
    5. Restrict System Task Usage: Carefully control which users/roles have permission to create or modify workflows that use system tasks (e.g., HTTP, EVENT, SUB_WORKFLOW). System tasks can have broad capabilities, so their misuse can be dangerous.

  • Threats Mitigated:

    • Malicious Workflow Definitions (High Severity): Prevents the execution of workflows that contain unauthorized tasks, dangerous configurations, or malicious input parameters.
    • Workflow Injection Attacks (High Severity): Reduces the risk of attackers injecting malicious code or commands into workflow definitions.

  • Impact:

    • Malicious Workflow Definitions: Risk reduced significantly (e.g., from High to Low).
    • Workflow Injection Attacks: Risk reduced significantly (e.g., from High to Medium).

  • Currently Implemented:

    • Basic validation of workflow definitions is performed (e.g., checking for valid JSON syntax).

  • Missing Implementation:

    • Formal JSON schema validation is not implemented.
    • Whitelisting of allowed task types is not enforced.
    • Input parameter validation within the schema is not comprehensive.
    • A custom WorkflowDefValidator is not implemented.
    • Restrictions on system task usage are not enforced.

Mitigation Strategy: Access Control for Workflow Definitions (Conductor-Level)

Mitigation Strategy: Access Control for Workflow Definitions (Conductor-Level)

  • Description:

    1. Role-Based Access Control (RBAC): Implement RBAC for managing workflow definitions. Define roles (e.g., "workflow_admin", "workflow_viewer", "workflow_executor") with different permissions:
      • Create: Ability to create new workflow definitions.
      • Read: Ability to view existing workflow definitions.
      • Update: Ability to modify existing workflow definitions.
      • Delete: Ability to delete workflow definitions.
      • Execute: Ability to start new workflow executions.
    2. Integrate with Authentication: Integrate the RBAC system with the Conductor server's authentication mechanism. Map authenticated users to roles.
    3. Enforce Permissions in API and UI: Enforce RBAC permissions in both the Conductor API and UI. Prevent unauthorized users from performing actions they are not allowed to perform.
    4. Metadata-based Access Control: Use metadata associated with workflow definitions (e.g., owner, group) to implement more granular access control. For example, only the owner of a workflow or members of a specific group might be allowed to modify it.

  • Threats Mitigated:

    • Unauthorized Workflow Modification (High Severity): Prevents unauthorized users from creating, modifying, or deleting workflow definitions.
    • Unauthorized Workflow Execution (Medium Severity): Prevents unauthorized users from starting new workflow executions.

  • Impact:

    • Unauthorized Workflow Modification: Risk reduced significantly (e.g., from High to Low).
    • Unauthorized Workflow Execution: Risk reduced significantly (e.g., from Medium to Low).

  • Currently Implemented:

    • Basic authentication is in place, but RBAC is not implemented.

  • Missing Implementation:

    • Formal RBAC roles and permissions are not defined.
    • RBAC is not enforced in the Conductor API or UI.
    • Metadata-based access control is not implemented.

Mitigation Strategy: Rate Limiting and Throttling (Conductor Server API)

Mitigation Strategy: Rate Limiting and Throttling (Conductor Server API)

  • Description:

    1. Identify API Endpoints: Identify the key API endpoints of the Conductor server (e.g., /api/workflow, /api/tasks, /api/metadata).
    2. Define Rate Limits: Define appropriate rate limits for each endpoint, based on expected usage patterns and server capacity. Consider different rate limits for different types of requests (e.g., read vs. write operations). Rate limits can be defined per user, per IP address, or globally.
    3. Implement Rate Limiting: Use a rate limiting library or framework (e.g., Bucket4j, resilience4j) within the Conductor server to enforce the defined rate limits. Reject requests that exceed the limits, returning an appropriate HTTP status code (e.g., 429 Too Many Requests).
    4. Configure Timeouts: Set appropriate timeouts for API requests to prevent slow clients or attackers from consuming server resources indefinitely.
    5. Monitor and Adjust: Continuously monitor API usage and adjust rate limits and timeouts as needed.

  • Threats Mitigated:

    • Denial of Service (DoS) (High Severity): Protects the Conductor server from being overwhelmed by excessive API requests.
    • Resource Exhaustion (Medium Severity): Prevents attackers or misbehaving clients from consuming excessive server resources.

  • Impact:

    • Denial of Service (DoS): Risk reduced significantly (e.g., from High to Medium).
    • Resource Exhaustion: Risk reduced significantly (e.g., from Medium to Low).

  • Currently Implemented:

    • No rate limiting or throttling is implemented on the Conductor server API.

  • Missing Implementation:

    • All aspects of rate limiting and throttling are missing.

Mitigation Strategy: Auditing and Logging (Conductor-Level)

Mitigation Strategy: Auditing and Logging (Conductor-Level)

  • Description:

    1. Enable Audit Logging: Configure Conductor to log all significant events, including:
      • Workflow creation, modification, and deletion.
      • Workflow execution start, completion, failure, and termination.
      • Task assignment, completion, and failure.
      • User authentication and authorization events.
      • Changes to Conductor server configuration.
    2. Log Relevant Information: Include relevant information in each log entry, such as:
      • Timestamp.
      • User ID (if authenticated).
      • Workflow ID and task ID.
      • Event type (e.g., "workflow_started", "task_failed").
      • Input parameters and output results (if appropriate, and with proper sanitization to avoid logging sensitive data).
      • Error messages and stack traces (for failures).
    3. Configure Logging Destination: Configure Conductor to send logs to a secure, centralized logging system (e.g., Elasticsearch, Splunk, CloudWatch Logs).
    4. Log Rotation and Retention: Implement log rotation and retention policies to manage log file size and storage duration.
    5. Regular Log Review: Regularly review audit logs to detect suspicious activity, anomalies, or security incidents. Use automated tools and manual analysis.
    6. Alerting: Configure alerts based on specific log events or patterns (e.g., repeated authentication failures, unauthorized workflow modifications).

  • Threats Mitigated:

    • Detection of Security Incidents (All Severities): Provides an audit trail for investigating security incidents and identifying the root cause.
    • Non-Repudiation (Medium Severity): Provides evidence of user actions and system events, making it difficult for users to deny their actions.
    • Compliance (Varies): Helps meet compliance requirements for auditing and logging.

  • Impact:

    • Detection of Security Incidents: Significantly improves the ability to detect and respond to security incidents.
    • Non-Repudiation: Risk reduced moderately.
    • Compliance: Helps meet compliance requirements.

  • Currently Implemented:

    • Basic logging is enabled, but it is not comprehensive or centralized.

  • Missing Implementation:

    • Comprehensive audit logging of all significant events is not implemented.
    • Logs are not sent to a secure, centralized logging system.
    • Log rotation and retention policies are not well-defined.
    • Regular log review and alerting are not formalized.