Alternatywa dla CRL
OCSP stanowi eleganckie rozwiązanie problemu sprawdzania unieważnionych certyfikatów. W przeciwieństwie do tradycyjnych list unieważnień certyfikatów (CRL), które wymagają pobierania całych list, OCSP umożliwia sprawdzenie statusu konkretnego certyfikatu poprzez bezpośrednie zapytanie do odpowiadacza OCSP.
Lokalizacja URL OCSP w Certyfikacie
URL OCSP znajduje się w rozszerzeniu "Authority Information Access" certyfikatu. Typowy format to:
http://ocsp.example.com/ocsp
Ta informacja jest osadzona bezpośrednio w certyfikacie podczas jego wydawania przez urząd certyfikacji.
Zalety OCSP nad CRL
- Aktualność w czasie rzeczywistym: Sprawdzanie statusu odbywa się na żądanie
- Efektywność przepustowości: Pobierane są tylko potrzebne informacje
- Skalowalność: Brak konieczności przechowywania dużych list CRL
Aby włączyć sprawdzanie unieważnień opartych na OCSP, skonfiguruj trustpoint następująco:
crypto pki trustpoint trustpoint-name
revocation-check ocsp
W niektórych scenariuszach może być konieczne użycie niestandardowego URL OCSP:
crypto pki trustpoint trustpoint-name
revocation-check ocsp
url http://custom-ocsp.company.com/ocsp
Do debugowania zachowania OCSP wykorzystaj:
debug crypto pki
To polecenie pozwala monitorować:
- Wysyłanie zapytań OCSP
- Odpowiedzi od serwerów OCSP
- Błędy walidacji certyfikatów
Błąd %CRYPTO-6-IKMP_NO_ID_CERT_ADDR_MATCH występuje, gdy router oczekuje dopasowania tożsamości certyfikatu według adresu IP, ale zamiast tego znajdzie FQDN (Fully Qualified Domain Name).
Mostkowanie Cisco IOU
PJO2
IOUlive64 to open-source’owa alternatywa dla narzędzia IOUlive stworzonego przez Cisco. Umożliwia łączenie wirtualnych routerów i switchy Cisco IOU z rzeczywistą siecią Ethernet, poprzez mostkowanie interfejsów IOU z fizycznymi interfejsami systemu.
Graficzny interfejs dla Containerlab
antimony-team
Antimony to platforma z graficznym interfejsem do projektowania i zarządzania sieciami Containerlab. Umożliwia łatwe tworzenie topologii sieci metodą przeciągnij i upuść oraz edycję kodu topologii obok siebie. Antimony pozwala na pełne zarządzanie instancjami containerlab, oferuje eksperymentalne wsparcie dla Kubernetes, obsługę wielu użytkowników przez OpenID oraz podgląd w czasie rzeczywistym statusu i logów kontenerów. Platforma sprawdzi się zarówno w edukacji, jak i przy lokalnym użytkowaniu, a jej kod jest dostępny na GitHubie wraz z dokumentacją.
Podstawy sieci w K8S
Kubernetes został zaprojektowany do automatyzacji wdrażania, skalowania i zarządzania aplikacjami w kontenerach. Początkowo stworzony przez Google, a następnie udostępniony jako platforma open-source, jest obecnie utrzymywany przez Cloud Native Computing Foundation (CNCF). Chociaż K8s jest popularnym narzędziem do orkiestracji kontenerów na dużą skalę, istnieją alternatywy takie jak Docker Swarm, Hashicorp Nomad, AWS ECS czy Mesos.
Pody (Pods)
Pod jest najmniejszą jednostką w K8s, wewnątrz której znajdować się będzie jeden lub wiele kontenerów (np. Docker). Pod jest pojedynczą instancją aplikacji, na przykład aplikacją sprawdzającą stan urządzeń sieciowych lub mikroserwisem obsługującym logowanie do aplikacji. Warto pamiętać, że Kubernetes zarządza podami, a nie bezpośrednio kontenerami, które żyją wewnątrz podów. Gdy aplikacja musi się skalować, na przykład z powodu zwiększonego obciążenia spowodowanego nowymi użytkownikami, tworzone są nowe pody.
Każdy pod posiada unikalny adres IP. Jeśli mamy wiele kontenerów wewnątrz poda, współdzielą one ten sam adres IP i MAC oraz mogą komunikować się ze sobą przez localhost. Dzieje się tak, ponieważ współdzielą tę samą przestrzeń nazw sieciowych (koncepcja Linuxa, nieco podobna do VRF). Dzielą również pamięć masową w postaci wolumenów. Domyślnie pody mogą komunikować się z innymi podami w tym samym klastrze bez ograniczeń. Omówimy wkrótce, czym jest klaster oraz jak można uczynić to domyślne zachowanie bezpieczniejszym.
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
controlplane Ready control-plane 62m v1.33.0
node01 Ready <none> 61m v1.33.0
Klastry (Clusters)
Klaster Kubernetes to zestaw węzłów zgrupowanych razem, które pomagają równoważyć obciążenie i zapewniać redundancję, jak wspomniano wcześniej. Każdy klaster ma węzeł master, który działa jak mózg klastra, zarządzając innymi węzłami i orkiestrując pody. Każdy klaster zawiera kilka komponentów Kubernetes:
API Server - Pełni rolę frontendu K8s, z którym komunikują się narzędzia CLI, takie jak kubectl
etcd - Rozproszona baza danych typu klucz-wartość przechowująca informacje o klastrze i obiektach
Kubelet - Agent działający na każdym węźle, dbający o to, by pody hostowane na nim były zdrowe
Container runtime - Instalowany na każdym węźle roboczym, np. Docker/cri-o
Controller - Zarządza orkiestracją i reaguje na zdarzenia, takie jak awarie podów lub węzłów
Scheduler - Dystrybuuje pody na węzłach, wyszukując nowo utworzone i przypisując je do węzłów
Klastry K8s domyślnie mają płaski model sieciowy, dzięki czemu wszystkie pody w klastrze mogą komunikować się ze sobą bez potrzeby NAT.
Bardzo ważne jest, aby pamiętać, że pody i ich adresy IP są efemeryczne i mogą się zmieniać, dlatego zazwyczaj nie używamy adresów IP jako identyfikatorów, lecz etykiet podów. Etykietę można traktować jak tag, np. app = networkapp. Wymaga to zupełnie innego myślenia niż w świecie lokalnym, gdzie możemy identyfikować serwer na podstawie jego adresu IP. Przejdźmy do kilku innych komponentów sieciowych.
CNI (Container Network Interface)
CNI to wtyczka w K8s, która definiuje specyfikację określającą, jak powinna być zaimplementowana sieć w naszym klastrze. Wybrana wtyczka określa, w jaki sposób pody otrzymują adresy IP oraz jak działa routing w klastrze. Przykłady CNI to: Cilium, Calico i Weave. Musimy wybrać odpowiedni CNI dla naszych wymagań dotyczących sieci, bezpieczeństwa i obserwowalności, ponieważ mają one różne funkcje. Na przykład różne CNI mają odmienne implementacje polityk sieciowych, które wkrótce omówimy. Jeśli potrzebujemy funkcji filtrowania warstwy 7, możemy wybrać Cilium.
Polityki Sieciowe (Network Policies)
Polityka sieciowa Kubernetes definiuje reguły zapory dla poda lub grupy podów według etykiet, nie adresów IP, bo pody są efemeryczne. Pozwala kontrolować, które pody mogą się komunikować, podobnie jak grupy bezpieczeństwa w AWS, gdzie dozwolony ruch jest określany, a reszta blokowana. Ruch z konkretnych adresów IP podów nie jest możliwy do zablokowania, ale można ograniczać zakresy IP.
Domyślnie wszystkie pody mogą się komunikować, więc polityki sieciowe są kluczowe dla bezpieczeństwa klastra. Nie wszystkie CNI obsługują polityki — np. Flannel ich nie wspiera, więc polityka w takim klastrze nie zadziała. Przykładowo, w typowej aplikacji trójwarstwowej frontend, backend i baza danych domyślnie się komunikują, ale warto ograniczyć dostęp frontendu do bazy danych dla bezpieczeństwa.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: db-policy
spec:
podSelector:
matchLabels:
# Przypisz politykę do podów z etykietą role: db
role: db
policyTypes:
- Ingress
ingress:
- from:
# Zezwól na ruch przychodzący z podów backendowych na porcie TCP 3306
- podSelector:
matchLabels:
role: backend
ports:
- protocol: TCP
port: 3306Po zastosowaniu naszej polityki sieciowej, przepływy ruchu w naszej aplikacji trójwarstwowej będą wyglądać następująco:
- Frontend może komunikować się z backendem
- Backend może komunikować się z bazą danych
- Frontend nie może bezpośrednio komunikować się z bazą danych
Możemy użyć poniższego polecenia, aby zweryfikować naszą Politykę Sieciową:
$ kubectl describe networkpolicies db-policy
Name: db-policy
Namespace: default
Created on: 2025-07-06 01:14:54 +0000 UTC
Labels: <none>
Annotations: <none>
Spec:
PodSelector: role=db
Allowing ingress traffic:
To Port: 3306/TCP
From:
PodSelector: role=backend
Not affecting egress traffic # Nasza polityka nie wpływa na ruch wychodzący - tylko przychodzący
Policy Types: Ingress
Usługi (Services)
Jak już kilkakrotnie wspomnieliśmy, pody w K8s są efemeryczne, co oznacza, że pojawiają się i znikają. W praktyce oznacza to, że trudno jest używać adresu IP poda do wskazania na niego, ponieważ może on zostać zniszczony po pewnym czasie. Tutaj właśnie pojawiają się usługi, które pozwalają nam udostępnić pod lub grupę podów za pomocą jednego stabilnego punktu końcowego. Można o nich myśleć jak o load-balancerach, jakie mamy w chmurze i świecie lokalnym. Usługi dają nam wirtualny adres IP i nazwę DNS, których możemy używać do dostępu do naszych podów.
Zapewniają również równoważenie obciążenia dla zdrowych podów określonych przez selektor etykiet podów, np. role=app. Istnieją różne typy usług, omówmy kilka najpopularniejszych:
ClusterIP - Jest to domyślny typ, dający usługę dostępną tylko wewnątrz naszego klastra
NodePort - Udostępnia naszą usługę na statycznym porcie na IP każdego węzła w naszym klastrze
LoadBalancer - Integruje się z usługą load balancera dostawcy chmury, np. AWS ALB, aby udostępnić usługi zewnętrznie
Ingress
Ingress działa jak load balancer warstwy 7, który pozwala na zewnętrzne udostępnianie usług, zazwyczaj przy użyciu HTTP/HTTPS i kontrolera ingress (np. NGINX lub Traefik) poprzez pojedynczy adres URL. Może być używany do zakończenia TLS i może również wykonywać routing oparty na ścieżkach i hostach do naszych usług K8s. Warto wspomnieć, że istnieje nowoczesny sposób realizacji tego zadania, nazywany Gateway API.
Kube-Proxy
Kube-proxy nie jest tak naprawdę proxy (wcale nie mylące), ale raczej komponentem działającym na każdym z naszych węzłów, utrzymującym reguły sieciowe do udostępniania usług. Implementuje również równoważenie obciążenia, które wykonują nasze usługi K8s. Warto również wspomnieć, że niektóre CNI, jak Cilium, zastąpiły Kube-Proxy nowszymi i bardziej skalowalnymi technologiami, ponieważ domyślnie używa on iptables w tle (technologia prawie tak stara jak niektórzy z nas).
Kubernetes może wydawać się bardzo skomplikowany. Mam nadzieję, że ten artykuł pomógł wyjaśnić niektóre kluczowe koncepcje i pozwolił zrozumieć ogólny obraz. Jeśli chcesz zagłębić się głębiej, istnieje wiele świetnych zasobów, które możesz wykorzystać do poszerzenia swojej wiedzy i zdobycia praktycznego doświadczenia.
Tworzenie Topologii Sieciowych
Przeczytaj całą historię
Zarejestruj się teraz, aby przeczytać całą historię i uzyskać dostęp do wszystkich postów za tylko dla płacących subskrybentów.
Subskrybuj