CVE-2018-1002105: proxy request handling in kube-apiserver can leave vulnerable TCP connections




[ Enable API Aggregation ]


## kube-apiserver 에 옵션에 다음과 같이 설정

--requestheader-client-ca-file=/etc/kubernetes/ssl/front-proxy-ca.crt
--requestheader-allowed-names=front-proxy-client
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=/etc/kubernetes/ssl/front-proxy-client.crt
--proxy-client-key-file=/etc/kubernetes/ssl/front-proxy-client.key



[ Metrics API 서버 설치 ]

$ mkdir -p ~/ahnsk/metric-server && cd ~/ahnsk
$ cd metrics-server

$ kubectl create -f deploy/1.8+/

$ kubectl -n kube-system get pods -l k8s-app=metrics-server


## metric-server 로그 보기
kubectl -n kube-system logs $(kubectl get pods --namespace=kube-system -l k8s-app=metrics-server -o name)


## metric-server 가 hostname 을 알지 못한다는 로그가 나오면 metric-server 를 변경

$ kubectl edit deployment metrics-server -n kube-system
image: k8s.gcr.io/metrics-server-amd64:v0.3.0
command:
- /metrics-server
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP



[ 취약점 확인 ]

## 1.12.2 버전에서는 metric-server 가 node 의 stats 을 가져오고 있음
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.2", GitCommit:"17c77c7898218073f14c8d573582e8d2313dc740", GitTreeState:"clean", BuildDate:"2018-10-24T06:43:59Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.2", GitCommit:"17c77c7898218073f14c8d573582e8d2313dc740", GitTreeState:"clean", BuildDate:"2018-10-24T06:43:59Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}

$ kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
{"kind":"NodeMetricsList","apiVersion":"metrics.k8s.io/v1beta1","metadata":{"selfLink":"/apis/metrics.k8s.io/v1beta1/nodes"},"items":[{"metadata":{"name":"k1-master01","selfLink":"/apis/metrics.k8s.io/v1beta1/nodes/k1-master01","creationTimestamp":"2018-12-05T08:38:13Z"},"timestamp":"2018-12-05T08:37:09Z","window":"30s","usage":{"cpu":"425054529n","memory":"13992336Ki"}},{"metadata":{"name":"k1-master02","selfLink":"/apis/metrics.k8s.io/v1beta1/nodes/k1-master02","creationTimestamp":"2018-12-05T08:38:13Z"},"timestamp":"2018-12-05T08:37:17Z","window":"30s","usage":{"cpu":"174426537n","memory":"10275528Ki"}},{"metadata":{"name":"k1-master03","selfLink":"/apis/metrics.k8s.io/v1beta1/nodes/k1-master03","creationTimestamp":"2018-12-05T08:38:13Z"},"timestamp":"2018-12-05T08:37:15Z","window":"30s","usage":{"cpu":"322881470n","memory":"10741952Ki"}},{"metadata":{"name":"k1-node01","selfLink":"/apis/metrics.k8s.io/v1beta1/nodes/k1-node01","creationTimestamp":"2018-12-05T08:38:13Z"},"timestamp":"2018-12-05T08:37:14Z","window":"30s","usage":{"cpu":"309956501n","memory":"14327216Ki"}},{"metadata":{"name":"k1-node02","selfLink":"/apis/metrics.k8s.io/v1beta1/nodes/k1-node02","creationTimestamp":"2018-12-05T08:38:13Z"},"timestamp":"2018-12-05T08:37:12Z","window":"30s","usage":{"cpu":"363826460n","memory":"17359508Ki"}},{"metadata":{"name":"k1-node03","selfLink":"/apis/metrics.k8s.io/v1beta1/nodes/k1-node03","creationTimestamp":"2018-12-05T08:38:13Z"},"timestamp":"2018-12-05T08:37:07Z","window":"30s","usage":{"cpu":"256312214n","memory":"15248572Ki"}},{"metadata":{"name":"k1-node04","selfLink":"/apis/metrics.k8s.io/v1beta1/nodes/k1-node04","creationTimestamp":"2018-12-05T08:38:13Z"},"timestamp":"2018-12-05T08:37:13Z","window":"30s","usage":{"cpu":"124689837n","memory":"11814000Ki"}},{"metadata":{"name":"k1-node05","selfLink":"/apis/metrics.k8s.io/v1beta1/nodes/k1-node05","creationTimestamp":"2018-12-05T08:38:13Z"},"timestamp":"2018-12-05T08:37:15Z","window":"30s","usage":{"cpu":"114905912n","memory":"8340284Ki"}}]}



## 1.11.5 패치 적용된 버전에서는 metric-server 가 system:anonymous 계정으로 node 의 stats 을 가져오지 못함
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T18:02:47Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.5", GitCommit:"753b2dbc622f5cc417845f0ff8a77f539a4213ea", GitTreeState:"clean", BuildDate:"2018-11-26T14:31:35Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

$ kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
{"kind":"NodeMetricsList","apiVersion":"metrics.k8s.io/v1beta1","metadata":{"selfLink":"/apis/metrics.k8s.io/v1beta1/nodes"},"items":[]}

$ kubectl logs metrics-server-695bdf6996-sg429 -n kube-system
E1205 08:14:30.157105       1 manager.go:102] unable to fully collect metrics: unable to fully scrape metrics from source kubelet_summary:node1: unable to fetch metrics from Kubelet node1 (192.168.0.93): request failed - "403 Forbidden", response:"Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=stats)"
E1205 08:15:30.148565       1 manager.go:102] unable to fully collect metrics: unable to fully scrape metrics from source kubelet_summary:node1: unable to fetch metrics from Kubelet node1 (192.168.0.93): request failed - "403 Forbidden", response:"Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=stats)"



[ work around 로 해결하는 방법 ]


1. kube-apiserver 옵션에 --anonymous-auth=false 를 넣는 방법 (default 는 true 임)

2. 아래 clusterrolebinding 의 system:basic-user 와 system:discovery 에 들어있는 system:unauthenticated Group 을 삭제

$ kubectl get clusterrolebindings system:basic-user -o yaml
kubectl get clusterrolebindings system:basic-user -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: 2018-11-21T08:44:59Z
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:basic-user
  resourceVersion: "113"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Abasic-user
  uid: bae78dd9-ed69-11e8-b322-3ca82a1c0c40
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:basic-user
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:unauthenticated


그리고 clusterrole 의 system:basic-user 와 system:discovery 에 세팅된 auto repaired 를 false 로 변경


$ kubectl get clusterroles system:basic-user -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: 2018-11-21T08:44:59Z
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:basic-user
  resourceVersion: "58"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Abasic-user
  uid: baae6ff5-ed69-11e8-b322-3ca82a1c0c40
rules:
- apiGroups:
  - authorization.k8s.io
  resources:
  - selfsubjectaccessreviews
  - selfsubjectrulesreviews
  verbs:
  - create







Posted by Kubernetes Korea co-leader seungkyua@gmail.com

처음에는 대충 볼려고 했는데 내용이 좋아서 끝까지 집중해서 봤네요. 전체 요약해 봤습니다.

AWS re:Invent 2018 - Keynote with Werner Vogels

2004-12-12 Amazon Oracle 장애 Lessons learned

  • SOA (Service Oriented Architecture) 로 서비스를 Flexible 하게 구성하였으나 Database Oracle의 로깅 코드 버그로 장애 발생, 12시간 동안 크리스마스 시즌 주문을 받지 못함
  • Oracle 은 SPOF (Single Point of Failure) 이고, Black Box 라 scale, reliability 를 높일 수 있는 방법이 없었음.
  • 1차 변경: Sharding 을 통해 데이터를 분산하여 performance 와  reliability 를 높힘
  • Reducing your blast radius : 장애가 발생하면 모든 면에서 영향을 최소화 해라.
  • 2차 변경: Cell based architectures 로 변경 (cell 단위 독립적으로 구성, 한 곳에 문제가 생겨도 영향도를 최소화함)
  • Cell based Architectures: AWS 는 모두 Cell 단위로 구성되어 있음 (심지어 AZ (Availability Zone) 안에서도 Cell 단위로 구성되어 영향도 최소화 했음) → 근데 왜 한국 Region 은 장애가....???)
  • AZ 서비스에서 DynamoDB 는 Cell 단위로 구성되어 DB 장애가 일어나도 최소화 됨.
  • Relational databases: not designed for the cloud (Sharding 을 하더라도 결국 Database 로 인해 서비스가 종속되게 됨)
  • Decompose the system into fundamental building blocks -> 그래야 multi tenant, fault tolerant, self healing 서비스를 구현 가능


Amazon Aurora: Scaled-out distributed architecture (Database aware storage service)

  • AWS 에서 가장 빠르게 성장하는 서비스 중에 하나임
  • AZ 단위로 분산이 가능하고 Cell based Architectures 로 mission critical 한 서비스 구현이 가능
  • On quorums and failures 를 적용하였기에 이런 서비스를 구현 가능했음 (AZ 단위로 분산)
  • AZ 마다 2개의 인스턴스를 띄우고 AZ 가 하나 죽고 다른 AZ 에서 인스턴스 1개가 죽어도 read 는 가능, 하지만 쓰기는 못함
  • 10G 링크로 되어 있어 click 만으로 빠르게 복구되어 MTBF(Mean time between failures) 와 MTTR(Mean time to repair) 를 줄일 수 있음
  • Aurora 는 log 만 복사하기 때문에 복제 및 복구가 빠름 (storage node 에서 복사가 이루어짐)
  • AWS Aurora 는 Cloud native database as a foundation for innovation 이다.
  • ASW 유형별 Databases 종류

    • Relational - Amazon Aurora, Amazon RDS
    • Key Value - Amazon DynamoDB
    • Document - Amazon DynamoDB
    • In-Memory - Amazon ElasticCache
    • Graph - Amazon Neptune
    • Time-Series (New) - Amazon Timestream
    • Ledger (New) - Amazon QLDB

How to migrate Oracle to DynamoDB

  • Amazon item master service : sharding 된 Oracle databases 24개로 구성 (6,000억 레코드가 있으며, 50억 update 가 1day 에 일어남), 1년에 30~40% 정도 증가함

  • Oracle 을 DynamoDB 로 변경 (schema 변경 및 Database Migration 진행)
  • Database Migration Service (6,000억 레코드 migration을 live 로 진행)

AWS S3 - Mai-lan Tomsen Bukovec (Vice President, Amazon S3 and Glacier)

  • 전체 10 Trillions objects 가 저장되어 있음
  • 한개의 리전에서 최대 1초에 60 Terabytes 를 관리함
  • 초기에 8개의 microservices 로 구성됨, 현재는 235개 이상의 분산 mircroservices 로 구성됨

AWS Redshift

  • 2018년 11월 1일 아주 큰 Oracle data warehouse 를 Redshift 로 옮김 (올해 가장 기쁜 순간)
  • 성능 향상을 이룸
  • 지난주 (11월 4째주) Redshift concurrency scaling 기능 새로 소개

AWS Lambda

  • 고객들이 serverless 로 가려고 하는가?


    • No Infrastructure provisioning, no management
    • Automatic scaling
    • Highly available and secure
    • Pay for value
  • 2014년 Preview 공개 후 2015년 GA 로 오픈
  • Worker: 고객의 function 코드가 로딩되고 실행되는 환경
  • Firecracker (New): serverless computing을 위한 안전하고 빠른 microVMs


    • KVM hardware virtualizations
    • 실행되는데 125ms 소요 (1개의 호스트에서 1초에 150 microVMs 실행 가능)
    • 1개의 microVM 당 5MB 메모리 사용 (1개의 호스트에 수천개의 microVM 을 띄울 수 있음)
  • Lambda runtime 환경



AWS 의 기능과 서비스의 95% 고객의 피드백으로 부터 개발된 것임

AWS Toolkits 새로운 IDEs

  • PyCharm
  • IntelliJ
  • VS Code

AWS Lambda 신규 기능

  • 사실상 모든 언어 지원 가능해 졌음
    • 기존 지원 언어: NodeJS, JavaScript, Python, Java, .Net, Go
    • 신규 지원 언어: Ruby
    • Lambda 에 Custom Runtime 적용 가능 (Ruby 도 그렇게 구현한 것으로 C++, Erlang 등 다른 언어 들도 적용하여 쓸 수 있음)
  • Lambda Layers: Lambda 를 라이브러리 형태의 함수로 만들어 재사용 가능
  • Nested Applications using Serverless Application Repository (New)

AWS Step Functions 

  • 기존에는 workflow 를 Sequential steps, Parallel steps, Branching steps 로 지원
  • Step Functions service Integrations (New): Step Functions 을 AWS 의 8개 서비스와 함께 쓸 수 있게 지원
    • Step Functions 함께 쓸 수 있는 AWS 8개 서비스: Batch, ECS, Fargate(컨테이너 배포 서비스), Glue(ETL서비스), DynamoDB, SNS, SQS, SageMaker

AWS API Gateway 에서 WebSocket 지원 

  • WebSocket 을 통해 Stateful 지원 가능

AWS ALB 에서 Lambda 지원

  • ALB (Amazon Load Balancer) 뒷단에 Lambda 를 바로 연결 가능 

Amazon Managed Streaming for Kafka

  • Fully managed and highly-available Apache Kafka service



AWS Well-Architected site

Amazon Well-Architected



AWS Well-Architected Tool

  • Measure and improve your architecture using AWS Well-Architectured best practices


Posted by Kubernetes Korea co-leader seungkyua@gmail.com