Filter control interface messages using the workload's access rights

[windsource]

Reported by @krucod3:

Description

Implement the access rights for a Workload by providing the Control Interface instance a channel that leads to the Agent (currently the messages from the Control Interface are directly passed to the Server). The Agent can filter the messages depending on the access rights and forward only authorized messages.

Another possibility would be to embed the filtering in the Control Interface task, but this could make it hard to update the accessRights dynamically.

Goals

Authorization for the Control Interface

Tasks

• implement authorizer (PR Authorize requests #301)
• write utests and stests in separate PR
• skip the creation of the control interface if the configuration of the workload does not contain a control interface field. This will be done with an extra issue Control interface shall be created only for configured for it workloads #322

[krucod3]

A concept for the structure of the access rights is already available in #172 (comment).
The concept shall be reviewed and checked for feasibility.
Please write comments here

[windsource]

I have reviewed the proposal for access rights and it looks good to me. Maybe you can add a few examples how it would look in the Ankaios manifest in this issue.

[krucod3]

Here is an example of a config with access rights. Please note that after our discussions some things have changed compared to the initial design and I have not reflected everything there are this is still work in progress. We also have to see how the implementation and the mapping to Rust structures can be made and consider if the proposed structure is easy to maintain and work with.

apiVersion: v0.1
workloads:
  composer:
    runtime: podman
    agent: agent_A
    restartPolicy: NEVER
    dependencies:
      init_workload: ADD_COND_SUCCEEDED
    tags:
      - key: owner
        value: Ankaios team
    controlInterfaceAccess:
      allowRules:
        - desiredStateRule:
            operation: RW_READ
            targets:
              - filterMask: 'desiredState.workloads'
        - desiredStateRule:
            operation: RW_READWRITE
            matchingAllTags: # optional
              - key: group
                value: infotainment
            targets:
              - filterMask: 'desiredState.workloads.*.agent'
                targetValues: ['agent_A', 'agent_B', '']
        - workloadStatesRule:
            operation: RS_READSUBSCRIBE
      denyRules:
        - desiredStateRule:
            operation: RW_WRITE
            targets:
              - filterMask: 'desiredState.workloads.composer'
    runtimeConfig: |
      image: docker.io/nginx:latest
      commandOptions: ["-p", "8081:80"]
  init_workload:
    runtime: podman
    agent: agent_A
    restartPolicy: NEVER
    dependencies:
      workload_C: ADD_COND_SUCCEEDED
    tags:
      - key: owner
        value: Ankaios team
    controlInterfaceAccess:
      allowRules:
        - workloadStatesRule:
            operation: RS_READ
            objectMasks: ['instanceName.agentName=agent_A', 'executionState.state=Failed']
    runtimeConfig: |
      image: docker.io/alpine:latest
      commandArgs: [ "echo", "Hello Ankaios"]
  radio:
    runtime: podman
    agent: agent_A
    restartPolicy: NEVER
    dependencies:
      workload_C: ADD_COND_SUCCEEDED
    tags:
      - key: group
        value: infotainment
    runtimeConfig: |
      image: docker.io/alpine:latest
      commandArgs: [ "echo", "Hello Ankaios"]
  navi:
    runtime: podman
    agent: agent_A
    restartPolicy: NEVER
    dependencies:
      workload_C: ADD_COND_SUCCEEDED
    tags:
      - key: group
        value: infotainment
    runtimeConfig: |
      image: docker.io/alpine:latest
      commandArgs: [ "echo", "Hello Ankaios"]

[krucod3]

The objectMasks will not work this way as we cannot request the read with them when getting the complete state. We need to think of something else here.

Maybe in the initial version we can leave that part out and just allow access to the execution state when

        - workloadStatesRule:
            operation: RS_READ

is specified as an allow rule.

The objectMasks, or something similar can later be used for the subcription only, but the read will be allowed to all states.

[krucod3]

Regarding the implementation of the enums in yaml and the (de)serialization in Rust, we have to use the singleton_map_recursive to get a readable yaml config, otherwise !tags are used per default to specify the enum type (see also here).

Example:

#[derive(Debug, Serialize, Deserialize, Clone, PartialEq, Eq)]
#[serde(rename_all = "camelCase")]
pub struct ControlInterfaceAccess {
    #[serde(with = "serde_yml::with::singleton_map_recursive")]
    pub allow_rules: Vec<AccessRightsRule>,
}

#[derive(Debug, Serialize, Deserialize, Clone, PartialEq, Eq)]
#[serde(rename_all = "camelCase")]
pub enum AccessRightsRule {
    DesiredStateRule(DesiredStateRule),
    WorkloadStatesRule(WorkloadStatesRule),
}

[inf17101]

I am currently fixing uncovered swdds in #56 and since you are already implementing system tests for testing the control interface access rights logic, could you link this swdd swdd~agent-forward-responses-to-control-interface-pipe~1 in the new stests? Then the uncovered swdd is fixed.

[krucod3]

Done.