Sign in Subscribe
Concepts

Securing SVN Services with Kubernetes Network Policies

Andrios Robert

• 1 min read

In Kubernetes, that gate is a Network Policy.

Kubernetes Network Policies define how pods talk to each other and to the outside world. Without them, every pod can connect anywhere on the cluster. With them, you set clear rules for ingress and egress traffic. They are your firewall at the pod level.

A Network Policy is a Kubernetes resource written in YAML. It declares selectors for pods and namespaces, combined with rules for allowed traffic. Pods not matched by a policy remain open by default unless you set a default deny.

Key fields include:

  • podSelector: Targets pods in the namespace where the policy lives.
  • ingress: Lists inbound rules, including ports and peer selectors.
  • egress: Controls outbound connections.
  • policyTypes: Defines whether the policy covers ingress, egress, or both.

For SVN infrastructure running on Kubernetes, Network Policies are essential for isolating SVN repositories, build agents, and deployment services. Locking down traffic between SVN pods and external users reduces attack surface and prevents data leaks. You can define policies that only allow SVN-related pods to communicate over specific TCP ports, blocking everything else.

Example: Restrict access so SVN pods only accept traffic from authorized CI/CD pods inside the same namespace.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: svn-repo-ingress
spec:
 podSelector:
 matchLabels:
 app: svn-repo
 policyTypes:
 - Ingress
 ingress:
 - from:
 - podSelector:
 matchLabels:
 role: ci-agent
 ports:
 - protocol: TCP
 port: 3690

Apply with:

kubectl apply -f svn-repo-ingress.yaml

After deployment, test connectivity. Pods outside the rule should fail when attempting to reach the SVN repository, confirming the policy works.

Integrating Kubernetes Network Policies with SVN services strengthens cluster security. They give precision over who connects, where, and how.

Build and run these policies faster with hoop.dev. See them in action on your cluster in minutes—no manual overhead, just working access control from the first deploy.