Controller Threats

README.md

Threats

Spoofing requests to the validating webhook

Description: If a malicious actor could circumvent webhook authentication, they could send unauthorized requests.

Impact: The webhook performs validation only and does not mutate any state. It's unclear what the security impact would be of spoofing.

Mitigations:

1. The webhook authenticates requests (mTLS) from the Kubernetes API server using a certificate managed/rotated by Kubernetes. Our threat model assumes that the API server and mechanisms like Kubernetes-managed certificates are not compromised.
2. The webhook follows a known Kuberentes implementation pattern and uses widely supported libraries to implement mTLS (Kubebuilder).
3. Tampering with the webhook code, configuration, or certifications would require access to modify the radius-system namespace. Our threat model assumes that the operator has limited access to the radius-system namespace using Kubernetes' existing RBAC mechanism.

Status: All mitigations listed are currently active. Operators are expected to secure their cluster and limit access to the radius-system namespace.

Spoofing the Kubernetes API server leading to escalation of privilege

Description: If a malicious actor could circumvent hijack communication between the controller and the API server, the controller would process illegitimate data.

Impact: A malicious actor could use the controllers to escalate privilege and perform arbitrary operations against Radius/UCP.

Mitigations:

1. The controllers authenticates requests to the Kubernetes API server using credentials managed/rotated by Kubernetes. Our threat model assumes that the API server and mechanisms like Kubernetes-managed authentication are not compromised.
2. The webhook follows a known Kubernetes implementation pattern and uses widely supported libraries to communicate (client-go, Kubebuilder).
3. Tampering with the controller code, configuration, or authentication tokens would require access to modify the radius-system namespace. Our threat model assumes that the operator has limited access to the radius-system namespace using Kubernetes' existing RBAC mechanism.

Status: All mitigations listed are currently active. Operators are expected to secure their cluster and limit access to the radius-system namespace.

Denial of service caused by invalid request data

Description: If a malicious actor send a malformed request that triggers unbounded execution on the server.

Impact: A malicious actor could cause denial of service or waste compute resources.

Mitigations:

1. The controllers and webhooks use widely supported libraries for all parsing of unstrusted data in standard formats.
   1. The Go standard libraries are used for HTTP.
   2. The Kubernetes YAML libraries are used for YAML parsing.
2. Radius/UCP implements a custom parser for resource ids, a custom string format. This requires fuzz-testing.

Status: All mitigations listed are currently active. Operators are expected to secure their cluster and limit access to the radius-system namespace.

Information disclosure by unauthorized access to secrets

Description: A malicious actor could circumvent Kubernetes RBAC controls and gain unauthorized access to Kuberentes secrets that are managed by Radius. These secrets may contain sensitive information like credentials intended for use by applications.

Impact: A malicious actor could gain access to sensitive information.

Mitigations:

1. Secret data managed by the controllers is stored at-rest in Kuberentes secrets. Our threat model assumes that the API server and mechanisms like Kubernetes authentication/RBAC are not compromised.
2. Secrets managed by Radius are always placed in the same namespace as the object which "owns" them. This is a requirement of the Kubernetes RBAC model.
3. Secrets managed by Radius as subject to the Kubernetes RBAC model for controlling access. Operators are expected to limit access for users using existing tools.

Status: All mitigations listed are currently active. Operators are expected to secure their cluster and limit access for users.

Escalation of privilege by using Radius to circumvent Kubernetes RBAC controls

Description: A malicious actor could circumvent Kuberentes RBAC controls and create arbitrary resources in Kubernetes by using the Recipe custom resource.

The Recipe controller has limited permissions so it cannot be used directly to escalate privilege in Kubernetes. It also calls into UCP/Radius which operates with a wide scope of permissions in Kubernetes and the cloud.

Authorized users with access to create a Recipe resource in Kubernetes can execute any Recipe in any Environment registered with Radius.

At the time of writing, Radius does not provide granular authorization controls. Any authenticated client can create any Radius resource, and can execute any action Radius is capable of taking. This is not limited to the Kubernetes controllers.

Impact: An authorized user of the Kubernetes cluster with permission to create a Recipe resource can execute any Recipe in any Environment registered with Radius.

Mitigations:

1. Operators should limit access to the Recipe resource using Kubernetes RBAC.
2. Operators should limit direct access to the Radius API using Kubernetes RBAC.
3. We should revisit the threat model and provide a more robust set of authorization controls when granular authorization policies are added to Radius.

Status: These mitigations are partial, and require configuration by the operator. We will revisit and improve this area in the future.

Spoofing UCP API Server could cause Information Disclosure and Denial of Service

Description: If a malicious actor can spoof UCP API Server by tampering with the configuration in the Controller, then the Controller will start sending requests to the malicious server and the malicious server can capture the traffic which can lead to information disclosure. This would effectively disable the Controller causing the Denial of Service.

Impact: All data sent to UCP by the Controller will be available to the malicious actor including payloads of resources in the applications. The functionality of the controller for managing resources will be disabled. Users will not be able to deploy updates to their applications.

Mitigations:

1. Tampering with the controller code, configuration, or certifications would require access to modify the radius-system namespace. Our threat model assumes that the operator has limited access to the radius-system namespace using Kubernetes' existing RBAC mechanism.
2. The resource payloads sent to UCP by the Controller don't contain sensitive operational information (e.g., passwords).

Status: All mitigations listed are currently active. Operators are expected to secure their cluster and limit access to the radius-system namespace.