Controller Component Threat Model #60

ytimocin · 2024-08-09T22:40:32Z

Adding the threat model doc for the controller component.

template/YYYY-MM-threat-model-template.md

threat/2024-08-controller-component-threat-model.md

architecture/2024-08-controller-component-threat-model.md

architecture/2024-08-controller-component-threat-model/controller-component.png

architecture/2024-08-controller-component-threat-model.md

brooke-hamilton

@ytimocin this is excellent! 🚀

rynowak · 2024-09-27T17:09:45Z

architecture/2024-08-controller-component-threat-model.md

+
+#### Data Serialization / Formats
+
+We use custom parsers to parse Radius-related resource IDs and do not use any other custom parsers and instead rely on Kubernetes built-in parsers. Therefore, we trust Kubernetes security measures to handle data serialization and formats securely. The custom parser that parses Radius resource IDs has its own security mechanisms that don't accept anything other than a Radius resource ID.


We should have an action item to do fuzz-testing on the resource ID.

Custom format + untrusted data -> do fuzz testing.

rynowak · 2024-09-27T17:11:09Z

architecture/2024-08-controller-component-threat-model.md

+
+## Action Items
+
+1. Use a hashing algorithm other than SHA-1 while computing the hash of the configuration of a Deployment object. This is a breaking change because deployments that are already hashed with SHA1 should be redeployed so that reconciler can work as expected.


This isn't a breaking change, we'd just do extra work 😆

rynowak · 2024-09-27T17:20:27Z

architecture/2024-08-controller-component-threat-model.md

+1. Use a hashing algorithm other than SHA-1 while computing the hash of the configuration of a Deployment object. This is a breaking change because deployments that are already hashed with SHA1 should be redeployed so that reconciler can work as expected.
+2. Check if RBAC with Least Privilege is configured for every component to ensure that each component has only the permissions it needs to function. Make changes to the necessary components if required.
+3. Define and implement necessary Network Policies to ensure that communication is accepted only from expected and authorized components. Regularly review and update these policies to maintain security.
+4. Containers should run as a non-root user wherever possible to minimize the risks. Check if we can run any of the Radius containers as non-root. Do the necessary updates.


I'd prefer that these "review" items be handled as part of the threat model review.

For example:

Check if RBAC with Least Privilege is configured for every component to ensure that each component has only the permissions it needs to function.

The threat model is the right place for us to define the "permissions each component needs to function". It doesn't make sense to push this work out of the threat model.

Containers should run as a non-root user wherever possible to minimize the risks. Check if we can run any of the Radius containers as non-root.

This is just scratching the surface in terms of policies applied to our components 😆. See: https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation

Signed-off-by: ytimocin <[email protected]>

…lso the threat model Signed-off-by: ytimocin <[email protected]>

Signed-off-by: ytimocin <[email protected]>

…ng some of them as discussed in the design meeting Signed-off-by: ytimocin <[email protected]>

Signed-off-by: ytimocin <[email protected]>

ytimocin force-pushed the ytimocin/threat/controller branch from a9e6911 to 0ae21ad Compare August 9, 2024 22:41