Open utterances-bot opened 2 years ago
Thank you! I will definitely try this out. Do you have plans to push it in a git repository?
Useful example, thanks! However, setting "securityContext: privileged: true" significantly decreases security and breaks container isolation, thus increasing privilege escalation risks. Is this really needed, any suggestion to improve it?
setting "securityContext: privileged: true" significantly decreases security and breaks container isolation, thus increasing privilege escalation risks. Is this really needed, any suggestion to improve it?
I must admit for me this was a bit of cargo culting. It didn't work without the setting so that's what I added to actually make it work. If it's really necessary or if there is another way... I don't know.
Great! tried a lot but my wiregauard pod kept failing until I read your article, However, in my case kubectl get svc -n wireguard lists me the Private IP of my cluster node and not the Public IP
Did I miss something?
kubectl get svc -n wireguard NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE wireguard LoadBalancer 10.43.209.221 10.0.0.100 51820:30970/UDP 7m21s
Did I miss something?
Not really sure. Maybe there is no public IP assigned to the cluster itself?
@perdian I setup everything like you have mentioned. The client connects but has not internet access.
'''
[Interface] Address = 172.16.16.0/20 ListenPort = 51820 PrivateKey = OIviMX9BPHk1w/bvsXW0Qc2/mY3+HS3iS31aEtsn+Uc= PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ENI -j MASQUERADE PostUp = sysctl -w -q net.ipv4.ip_forward=1 PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ENI -j MASQUERADE PostDown = sysctl -w -q net.ipv4.ip_forward=0
[Peer] PublicKey = AOIzLd2C71DtY8DWgUfuMllRNa0iR1O3tO2WbFO7ICU= AllowedIPs = 172.16.16.10
'''
Used this
I had to change where the wireguard-config
volume is mounted at in the wireguard container from /etc/wireguard/
to /config/
. The init container was fine however.
Due to what I assume have been changes in how the container manages configurations, I had to modify the original instructions to get this working. I hope this helps anyone else who is trying to accomplish this. It will allow for wireguard to fully initialize with the default managed configuration that is generated at container runtime before swapping it out with your own configuration. Here are my sanitized manifests:
wireguard-namespace.yml https://pastebin.com/raw/hbxugbbu wireguard-secret.yml https://pastebin.com/raw/HJwx2MB2 wireguard-service.yml https://pastebin.com/raw/u2GEKvbe wireguard-deployment.yml https://pastebin.com/raw/nAtfSrSD
Thanks a lot @UntouchedWagons and @sholdee for the comments. I've updated the article with the latest changes made by LinuxServer.io. The configuration is working again with the examples given here.
Christian Seifert // Setting up a WireGuard VPN using Kubernetes
Setting up a WireGuard VPN using Kubernetes
https://www.perdian.de/blog/2022/02/21/setting-up-a-wireguard-vpn-using-kubernetes/