-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: add known limitations #416
Conversation
m1ghtym0
commented
May 2, 2024
- Move to docs (one place for one information): readme: update links #359
- Some rephrasing
- @burgerdev @3u13r Please check the policy part
|
docs/docs/known-limitations.md
Outdated
## Runtime Policies | ||
|
||
- **Coverage**: While the enforcement of workload policies generally functions well, [there are scenarios not yet fully covered](https://github.com/microsoft/kata-containers/releases/tag/genpolicy-0.6.2-5). It's crucial to review deployments specifically for these edge cases. | ||
- **Policy Evaluation**: The current policy evaluation mechanism on API requests isn't stateful, which means it can't ensure a prescribed order of events. Consequently, there's no guaranteed enforcement that the [initializer](components/index.md#the-initializer) container runs *before* the workload container. This order is vital for ensuring that all traffic between pods is securely encapsulated within TLS connections. TODO: Consequences |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
open TODO
Co-authored-by: Paul Meyer <[email protected]>
docs/docs/known-limitations.md
Outdated
## Runtime Policies | ||
|
||
- **Coverage**: While the enforcement of workload policies generally functions well, [there are scenarios not yet fully covered](https://github.com/microsoft/kata-containers/releases/tag/genpolicy-0.6.2-5). It's crucial to review deployments specifically for these edge cases. | ||
- **Policy Evaluation**: The current policy evaluation mechanism on API requests isn't stateful, which means it can't ensure a prescribed order of events. Consequently, there's no guaranteed enforcement that the [initializer](components/index.md#the-initializer) container runs *before* the workload container. This order is vital for ensuring that all traffic between pods is securely encapsulated within TLS connections. TODO: Consequences |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not so much of an issue with the initializer, but rather with the service mesh sidecar. If the sidecar is not launched, traffic redirection does not happen and we leak plaintext.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there anything else we should mention here in terms of consequences or workarounds?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should have a general warning about relying on execution order, and a specific warning about our service mesh.
Possible workarounds for the unreliable ingress path:
- Terminate TLS in the workload directly.
- Don't serve any secrets to unauthenticated clients.
- Inspect the iptables rules on startup. We could consider making this easier by dropping a canary into the TLS dir after setting up iptables.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I added warnings and the additional points you mentioned.
@3u13r, please add warnings accordingly when you add the service mesh stuff.
Co-authored-by: Markus Rudy <[email protected]>