Skip to content
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

Merged
merged 8 commits into from
May 6, 2024
Merged

docs: add known limitations #416

merged 8 commits into from
May 6, 2024

Conversation

m1ghtym0
Copy link
Member

@m1ghtym0 m1ghtym0 commented May 2, 2024

@m1ghtym0 m1ghtym0 added no changelog PRs not listed in the release notes documentation Improvements for user docs labels May 2, 2024
@m1ghtym0 m1ghtym0 requested review from burgerdev and 3u13r May 2, 2024 09:23
Copy link

github-actions bot commented May 2, 2024

PR Preview Action v1.4.7
Preview removed because the pull request was closed.
2024-05-06 07:01 UTC

@m1ghtym0 m1ghtym0 marked this pull request as ready for review May 2, 2024 09:27
@m1ghtym0 m1ghtym0 requested a review from katexochen as a code owner May 2, 2024 09:27
docs/docs/known-limitations.md Outdated Show resolved Hide resolved
docs/docs/known-limitations.md Outdated Show resolved Hide resolved
docs/docs/known-limitations.md Outdated Show resolved Hide resolved
## 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

open TODO

docs/docs/known-limitations.md Outdated Show resolved Hide resolved
## 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
Copy link
Contributor

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.

Copy link
Member Author

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?

Copy link
Contributor

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.

Copy link
Member Author

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.

docs/docs/known-limitations.md Outdated Show resolved Hide resolved
@m1ghtym0 m1ghtym0 merged commit 17de693 into main May 6, 2024
8 checks passed
@m1ghtym0 m1ghtym0 deleted the m/docs/limitations branch May 6, 2024 06:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements for user docs no changelog PRs not listed in the release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants