-
Notifications
You must be signed in to change notification settings - Fork 0
feat: add NetworkPolicy documentation #78
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
feat: add NetworkPolicy documentation #78
Conversation
WalkthroughThe document has been updated to include a new section on enforcing Network Policies for securing the BTP platform's CustomDeployment services. This section provides guidance on enabling NetworkPolicy enforcement across major cloud providers: GKE, EKS, and AKS. It includes specific commands for enabling this feature during cluster creation or updates, along with a sample YAML configuration for NetworkPolicies. Minor formatting corrections were made, but previous content regarding service access and Ingress controller requirements remains unchanged. Changes
Sequence Diagram(s)(No sequence diagrams generated as the changes do not warrant a visual representation.) Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Reviewer's Guide by SourceryThis pull request adds documentation for NetworkPolicy enforcement in the BTP platform. It provides instructions on how to enable NetworkPolicy enforcement on different cloud providers (GKE, EKS, AKS) and includes an example of a NetworkPolicy configuration. Sequence DiagramNo sequence diagram generated. File-Level Changes
Tips and commands
|
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.
Hey @insider89 - I've reviewed your changes and they look great!
Here's what I looked at during the review
- 🟢 General issues: all looks good
- 🟢 Security: all looks good
- 🟢 Review instructions: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟡 Documentation: 2 issues found
Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.
|
|
||
| ### 6. Network Policies enforcement on the target clusters | ||
|
|
||
| The BTP platform applies NetworkPolicies for CustomDeployment services to restrict access to services to other namespaces. However, not all cloud providers enforce NetworkPolicies by default on their Kubernetes clusters. We strongly recommend enabling NetworkPolicy enforcement on your Kubernetes cluster before creating it. |
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.
suggestion (documentation): Consider clarifying the timing of enabling NetworkPolicy enforcement
The phrase 'before creating it' might be confusing as the cluster would already exist at this point. Consider changing to 'before deploying to it' or 'before using it with BTP' for clarity.
| The BTP platform applies NetworkPolicies for CustomDeployment services to restrict access to services to other namespaces. However, not all cloud providers enforce NetworkPolicies by default on their Kubernetes clusters. We strongly recommend enabling NetworkPolicy enforcement on your Kubernetes cluster before creating it. | |
| The BTP platform applies NetworkPolicies for CustomDeployment services to restrict access to services to other namespaces. However, not all cloud providers enforce NetworkPolicies by default on their Kubernetes clusters. We strongly recommend enabling NetworkPolicy enforcement on your Kubernetes cluster before deploying to it or using it with BTP. |
| name: combined-restrict-internal-allow-external | ||
| namespace: $namespace | ||
| spec: | ||
| podSelector: {} | ||
| policyTypes: | ||
| - Egress | ||
| egress: | ||
| # 1. Allow DNS resolution (covers GKE, AKS, and EKS) | ||
| - to: | ||
| - ipBlock: | ||
| cidr: 10.0.0.0/8 # For the GKE cluster | ||
| - namespaceSelector: | ||
| matchLabels: | ||
| kubernetes.io/metadata.name: kube-system | ||
| podSelector: | ||
| matchLabels: | ||
| k8s-app: kube-dns | ||
| ports: | ||
| - protocol: UDP | ||
| port: 53 | ||
| - protocol: TCP | ||
| port: 53 | ||
| # 2. Allow traffic within the same namespace (curl) | ||
| - to: | ||
| - namespaceSelector: | ||
| matchLabels: | ||
| kubernetes.io/metadata.name: $namespace | ||
| # 3. Allow traffic to all external IPs but block internal IP ranges | ||
| - to: | ||
| - ipBlock: | ||
| cidr: 0.0.0.0/0 | ||
| except: | ||
| - 10.0.0.0/8 | ||
| - 172.16.0.0/12 | ||
| - 192.168.0.0/16 |
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.
suggestion (documentation): Consider explaining the $namespace variable in the NetworkPolicy example
It might be helpful to add a note explaining what the $namespace variable represents and how it should be replaced in the actual implementation.
name: combined-restrict-internal-allow-external
# Replace $namespace with your actual namespace name
namespace: $namespace
spec:
podSelector: {}
policyTypes:
- Egress
egress:
# 1. Allow DNS resolution (covers GKE, AKS, and EKS)
- to:
- ipBlock:
cidr: 10.0.0.0/8 # For the GKE cluster
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.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
docs/launch-platform/self-hosted/installing-on-an-existing-cluster/prerequisites/Infrastructure.md (3)
376-381: LGTM! Consider adding a brief explanation of NetworkPolicies.The new section on Network Policies enforcement is a valuable addition to the documentation. It clearly explains the importance of NetworkPolicies for CustomDeployment services and provides a strong recommendation for enabling enforcement.
Consider adding a brief explanation of what NetworkPolicies are and their benefits for readers who might be unfamiliar with the concept. This could be a single sentence after the first paragraph, such as:
"NetworkPolicies are Kubernetes resources that control the flow of network traffic between pods, providing an additional layer of security within your cluster."
382-419: LGTM! Consider clarifying GKE options and adding version information.The cloud provider-specific instructions are clear, concise, and helpful. They provide actionable steps for enabling NetworkPolicy enforcement across GKE, EKS, and AKS.
Consider the following improvements:
- For the GKE section, clarify when to use
--enable-network-policyvs.--enable-dataplane-v2. A brief explanation of the differences or recommendations would be helpful.- For EKS, consider adding the minimum EKS version that supports NetworkPolicy by default.
- For all sections, it might be helpful to add links to the official documentation for each cloud provider's NetworkPolicy implementation.
Example for GKE clarification:
"Use--enable-network-policyfor basic NetworkPolicy support. For advanced features and better performance, consider using--enable-dataplane-v2, which includes NetworkPolicy enforcement along with other benefits."
421-462: LGTM! Consider generalizing the sample policy and explaining placeholders.The sample NetworkPolicy YAML is a valuable addition, providing a concrete example of how to implement network security in Kubernetes clusters.
Consider the following improvements:
- Add a brief introduction explaining the purpose and scope of this sample policy.
- Explain or provide instructions for replacing the
$namespaceplaceholder.- Generalize the policy to be less cloud-provider specific. For example, the CIDR block
10.0.0.0/8is labeled as "For the GKE cluster", but this might not apply to all GKE clusters or other providers.- Add a note advising users to adjust the policy based on their specific cluster configuration and requirements.
Example introduction:
"Below is a sample NetworkPolicy that demonstrates how to:
- Allow DNS resolution
- Allow traffic within the same namespace
- Allow external traffic while blocking internal IP ranges
Note: This is a starting point and should be adjusted to fit your specific cluster configuration and security requirements."
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- docs/launch-platform/self-hosted/installing-on-an-existing-cluster/prerequisites/Infrastructure.md (2 hunks)
🔇 Additional comments (1)
docs/launch-platform/self-hosted/installing-on-an-existing-cluster/prerequisites/Infrastructure.md (1)
376-462: Great addition to the documentation! Consider minor refinements for clarity and generalization.The new section on Network Policies enforcement is a valuable addition to the infrastructure prerequisites documentation. It provides clear explanations, cloud provider-specific instructions, and a practical example of a NetworkPolicy. These additions will greatly assist users in implementing proper network security for their BTP deployments.
While the content is already of high quality, consider implementing the minor suggestions provided in the previous comments to further enhance clarity and generalization. These refinements will make the documentation even more accessible and applicable to a wider range of users and environments.
Summary by Sourcery
Add NetworkPolicy documentation to guide users on enforcing network policies in Kubernetes clusters for improved security.
Documentation:
Summary by CodeRabbit