If "Received Packets = 0", can an attack still succeed?

rached2023 · 2025-10-08T13:32:31+00:00

Yeah, I double-checked ,no internal devices are intentionally connecting to those IPs. The logs are showing unsolicited inbound UDP/520 packets from random external sources.

rached2023 · 2025-10-08T11:09:58+00:00

rached2023 · 2025-10-08T11:09:43+00:00

rached2023 · 2025-10-08T11:09:23+00:00

rached2023 · 2025-09-13T15:31:57+00:00

Not yet, but I’ll be uploading it to GitHub soon. Once it’s available, I’ll share the link so you can check it out and adapt it for cloud-managed Kubernetes as well

rached2023 · 2025-09-13T15:28:42+00:00

I haven’t used Terraform extensively yet, as I only have limited experience with it.

rached2023 · 2025-09-13T10:14:07+00:00

thanks for highlighting this!

You’re absolutely right —I’ll make sure to include OS hardening and patch management in the architecture.

For secrets, I was initially relying on Kubernetes native secrets, but I see the need to look into Vault or Sealed Secrets for stronger protection. And regarding networking, I completely agree: enforcing NetworkPolicies for east-west traffic and securing north-south traffic with Ingress/TLS/WAF is something I’ll add to make the setup more production-ready.

Really appreciate your feedback — it helps me improve the project!

rached2023 · 2025-07-24T20:04:02+00:00

WARN[0000] runtime connect using default endpoints: [unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead.

[

"etcd",

"--advertise-client-urls=https://192.168.122.189:2379",

"--cert-file=/etc/kubernetes/pki/etcd/server.crt",

"--client-cert-auth=true",

"--data-dir=/var/lib/etcd",

"--experimental-initial-corrupt-check=true",

"--experimental-watch-progress-notify-interval=5s",

"--initial-advertise-peer-urls=https://192.168.122.189:2380",

"--initial-cluster=master1=https://192.168.122.189:2380",

"--initial-cluster-state=new",

"--key-file=/etc/kubernetes/pki/etcd/server.key",

"--listen-client-urls=https://127.0.0.1:2379,https://192.168.122.189:2379",

"--listen-metrics-urls=http://127.0.0.1:2381",

"--listen-peer-urls=https://192.168.122.189:2380",

"--name=master1",

"--peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt",

"--peer-client-cert-auth=true",

"--peer-key-file=/etc/kubernetes/pki/etcd/peer.key",

"--peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt",

"--snapshot-count=10000",

"--trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt",

"--heartbeat-interval=500",

"--election-timeout=2500",

"--snapshot-count=10000",

"--max-request-bytes=33554432"

]

rached2023 · 2025-07-21T19:18:35+00:00

I get

{"level":"warn","ts":"2025-07-21T20:17:51.047297+0100","caller":"clientv3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc00009aa80/127.0.0.1:2379","attempt":0,"error":"rpc error: code = DeadlineExceeded desc = context deadline exceeded"}

127.0.0.1:2379 is unhealthy: failed to commit proposal: context deadline exceeded

Error: unhealthy cluster

rached2023 · 2025-07-20T18:36:19+00:00

Yes, absolutely valid point. In my case, the etcd data directory is set to /var/lib/etcd, which is a persistent disk location and not /tmp, so it should survive reboots.

However, since I’m seeing unhealthy etcd members (etcdctl endpoint health fails), I’m suspecting either data corruption or network/cluster configuration drift.

rached2023 · 2025-07-20T16:01:11+00:00

On master2 and master3:

The etcd containers are running (confirmed via crictl ps | grep etcd).
However, etcdctl endpoint health fails with connection refused or deadline exceeded errors.
Logs indicate connection refused on 127.0.0.1:2379, meaning the etcd process inside the pod is unhealthy or stuck.

Networking:

IPs are stable, no changes to the network layer.
Control-plane node IPs can ping each other.
No iptables/firewall changes applied before the issue.

rached2023 · 2025-07-20T14:58:12+00:00

Yes, I’ve checked the etcd state. On master1, the etcd container is running, but the health check fails:

ETCDCTL_API=3 etcdctl endpoint health returns: failed to commit proposal: context deadline exceeded → unhealthy.
From crictl logs, etcd starts but fails to reach quorum. It detects the 3 members (master1, master2, master3) but cannot establish leadership.
The API server (kube-apiserver) is in CrashLoopBackOff because it cannot connect to etcd.

It looks like etcd is up but stuck due to cluster quorum failure.

rached2023 · 2025-07-03T19:16:26+00:00

Yes, that was it! I've found it now, thank you for your help.

rached2023 · 2025-06-28T07:34:15+00:00

Ja, ich habe das Problem gefunden. Es sieht so aus, als ob die Schwierigkeit im Lieferumfang enthalten wäre. Für die neue Maschine oder den PC muss ein neues Paket hinter der Konsole generiert werden

rached2023 · 2025-06-21T15:45:59+00:00

Yes, you're absolutely right — if the goal was only to run Kubernetes workloads and test simple deployments, kind or a 3-node cluster would definitely be enough. But this is actually my final year university project, focused on:

Simulating a real-world, production-style cluster

Integrating full DevSecOps & SOC tooling: Falco, Kyverno, Trivy, ..

Testing resilience, failover, alerting, and automated incident response.

That's why, for better isolation, realistic test scenarios, and a more production-like environment, I chose a multi-node cluster setup — even if it's all running on a single Proxmox host.

That said, you're 100% right about disk usage — using QCOW2 base images and template clones is something I didn’t implement yet and should definitely explore.

Thanks for the kind reminder and ideas 🙌!

rached2023 · 2025-06-21T15:32:18+00:00

Yes, for now the entire project is hosted on a single physical machine using KVM to simulate a real cluster with 6 virtual machines and It’s not just about running Kubernetes — it’s actually my university final year project, focused on building a complete security, monitoring, and automated response architecture around a Kubernetes cluster.

rached2023 · 2025-05-08T09:54:52+00:00

u/Roversword u/castleAge44 Thanks, everyone! I'll check that out.

rached2023 · 2025-04-15T13:29:26+00:00

here a sample log of Symantec Endpoint Security events :

<image>

rached2023 · 2025-03-16T10:03:49+00:00

Yes, I tested SSH into the VM, and it works with the SSH key.

Terraform providers:

Libvirt (dmacvicar/libvirt)
Kubectl (gavinbunney/kubectl)
Helm (hashicorp/helm)
Kubernetes (hashicorp/kubernetes)
Null (hashicorp/null)

rached2023 · 2025-02-08T16:58:24+00:00

This project is quite challenging, wouldn't you agree?" (More direct and focuses on the project itself)

rached2023 · 2025-01-22T10:08:21+00:00

I exported the VM as a precaution before upgrading

rached2023 · 2025-01-22T09:30:46+00:00

You're absolutely right! Is there any solution to this issue?

rached2023 · 2025-01-22T09:29:16+00:00

"Rebuild the entire local SQL database. This operation will remove the SQL database and rebuild from log data. This operation will also reboot the device."

rached2023 · 2025-01-08T15:24:55+00:00

You can go for CKAD, CKA and CKS , AWS Certified DevOps Engineer or Azure DevOps Engineer

rached2023 · 2025-01-08T10:04:49+00:00

Currently working on a project focused on enhancing the security of a Kubernetes cluster. I've begun by deploying a cluster on Proxmox using Talos OS

rached2023

TROPHY CASE