Exposing Services in Kubernetes

HackTricks 지원하기

Kubernetes에서 서비스를 노출하는 다양한 방법이 있어 내부 엔드포인트와 외부 엔드포인트가 이를 접근할 수 있습니다. 이 Kubernetes 구성은 매우 중요하며, 관리자가 공격자가 접근해서는 안 되는 서비스에 접근할 수 있도록 허용할 수 있습니다.

자동 열거

K8s가 서비스를 공개적으로 노출하는 방법을 열거하기 시작하기 전에, 네임스페이스, 서비스 및 인그레스를 나열할 수 있다면, 공개적으로 노출된 모든 것을 찾을 수 있다는 것을 알아두세요:

kubectl get namespace -o custom-columns='NAME:.metadata.name' | grep -v NAME | while IFS='' read -r ns; do
echo "Namespace: $ns"
kubectl get service -n "$ns"
kubectl get ingress -n "$ns"
echo "=============================================="
echo ""
echo ""
done | grep -v "ClusterIP"
# Remove the last '| grep -v "ClusterIP"' to see also type ClusterIP

ClusterIP

A ClusterIP 서비스는 기본 Kubernetes 서비스입니다. 클러스터 내의 다른 앱이 접근할 수 있는 클러스터 내 서비스를 제공합니다. 외부 접근은 없습니다.

그러나, Kubernetes Proxy를 사용하여 접근할 수 있습니다:

kubectl proxy --port=8080

이제 이 스킴을 사용하여 Kubernetes API를 통해 서비스에 접근할 수 있습니다:

http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/

예를 들어, 다음 URL을 사용할 수 있습니다:

http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/

이 서비스를 접근하기 위해:

apiVersion: v1
kind: Service
metadata:
name: my-internal-service
spec:
selector:
app: my-app
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP

이 방법은 인증된 사용자kubectl을 실행해야 합니다.

모든 ClusterIP 나열:

kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,PORT(S):.spec.ports[*].port,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep ClusterIP

NodePort

NodePort가 사용될 때, 모든 노드(가상 머신을 나타냄)에서 지정된 포트가 사용 가능해집니다. 이 특정 포트로 향하는 트래픽은 체계적으로 서비스로 라우팅됩니다. 일반적으로 이 방법은 단점으로 인해 권장되지 않습니다.

모든 NodePort 목록:

kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,PORT(S):.spec.ports[*].port,NODEPORT(S):.spec.ports[*].nodePort,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep NodePort

NodePort 사양의 예:

apiVersion: v1
kind: Service
metadata:
name: my-nodeport-service
spec:
selector:
app: my-app
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
nodePort: 30036
protocol: TCP

If you nodePort를 yaml에서 지정하지 않으면 (열릴 포트입니다) 30000–32767 범위의 포트가 사용됩니다.

LoadBalancer

클라우드 제공업체의 로드 밸런서를 사용하여 서비스를 외부에 노출합니다. GKE에서는 네트워크 로드 밸런서를 생성하여 서비스로 모든 트래픽을 전달하는 단일 IP 주소를 제공합니다. AWS에서는 로드 밸런서를 시작합니다.

노출된 서비스당 LoadBalancer에 대한 요금을 지불해야 하며, 이는 비용이 많이 들 수 있습니다.

모든 LoadBalancers 나열:

kubectl get services --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,EXTERNAL-IP:.status.loadBalancer.ingress[*],PORT(S):.spec.ports[*].port,NODEPORT(S):.spec.ports[*].nodePort,TARGETPORT(S):.spec.ports[*].targetPort,SELECTOR:.spec.selector' | grep LoadBalancer

외부 IP

외부 IP는 Load Balancer 유형의 서비스에 의해 노출되며, 일반적으로 외부 Cloud Provider Load Balancer가 사용될 때 사용됩니다.

이를 찾으려면 EXTERNAL-IP 필드에 값이 있는 로드 밸런서를 확인하십시오.

클러스터로 들어오는 트래픽이 외부 IP(목적지 IP)로 서비스 포트에서 서비스 엔드포인트 중 하나로 라우팅됩니다. externalIPs는 Kubernetes에 의해 관리되지 않으며 클러스터 관리자의 책임입니다.

서비스 사양에서 externalIPsServiceTypes 중 어떤 것과 함께 지정할 수 있습니다. 아래 예제에서 "my-service"는 "80.11.12.10:80"(externalIP:port)에서 클라이언트가 접근할 수 있습니다.

apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- name: http
protocol: TCP
port: 80
targetPort: 9376
externalIPs:
- 80.11.12.10

ExternalName

문서에서: ExternalName 유형의 서비스는 서비스를 DNS 이름에 매핑하며, my-service 또는 cassandra와 같은 일반 선택자에 매핑하지 않습니다. 이러한 서비스는 spec.externalName 매개변수로 지정합니다.

예를 들어, 이 서비스 정의는 prod 네임스페이스의 my-service 서비스를 my.database.example.com에 매핑합니다:

apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: prod
spec:
type: ExternalName
externalName: my.database.example.com

my-service.prod.svc.cluster.local 호스트를 조회할 때, 클러스터 DNS 서비스는 값이 my.database.example.comCNAME 레코드를 반환합니다. my-service에 접근하는 것은 다른 서비스와 동일하게 작동하지만, 리디렉션이 프록시 또는 포워딩이 아닌 DNS 수준에서 발생한다는 중요한 차이점이 있습니다.

모든 ExternalNames 나열하기:

kubectl get services --all-namespaces | grep ExternalName

Ingress

위의 모든 예와 달리, Ingress는 서비스의 유형이 아닙니다. 대신, 여러 서비스 앞에 위치하여 “스마트 라우터” 또는 클러스터의 진입점 역할을 합니다.

Ingress를 사용하여 다양한 작업을 수행할 수 있으며, 다양한 기능을 가진 여러 유형의 Ingress 컨트롤러가 있습니다.

기본 GKE Ingress 컨트롤러는 HTTP(S) 로드 밸런서를 자동으로 생성합니다. 이를 통해 경로 기반 및 서브도메인 기반 라우팅을 백엔드 서비스로 수행할 수 있습니다. 예를 들어, foo.yourdomain.com의 모든 요청을 foo 서비스로 보내고, yourdomain.com/bar/ 경로 아래의 모든 요청을 bar 서비스로 보낼 수 있습니다.

GKE에서 L7 HTTP 로드 밸런서를 사용하는 Ingress 객체의 YAML은 다음과 같을 수 있습니다:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-ingress
spec:
backend:
serviceName: other
servicePort: 8080
rules:
- host: foo.mydomain.com
http:
paths:
- backend:
serviceName: foo
servicePort: 8080
- host: mydomain.com
http:
paths:
- path: /bar/*
backend:
serviceName: bar
servicePort: 8080

모든 인그레스를 나열합니다:

kubectl get ingresses --all-namespaces -o=custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,RULES:spec.rules[*],STATUS:status'

이 경우 각 정보를 하나씩 가져오는 것이 더 나은 읽기를 위해 좋습니다:

kubectl get ingresses --all-namespaces -o=yaml

References

HackTricks 지원하기

Last updated