반응형

https://www.samsungsds.com/kr/insights/1258148_4627.html

 

쿠버네티스 보안, 어떻게 해야 할까?

쿠버네티스 보안, 어떻게 해야 할까?

www.samsungsds.com

데브옵스(DevOps)와 데브섹옵스(DevSecOps)

데브옵스(DevOps)와 데브섹옵스(DevSecOps)

이제는 대부분의 IT 개발자와 시스템 운영자들이 데브옵스를 잘 이해하고 있으며 많은 조직이 데브옵스 방식의 민첩성과 유연성을 바탕으로 라이프 사이클을 운영하고 있습니다. 데브옵스는 개발 주기를 단축하고 산출물을 재빨리 배포하는데 큰 장점이 있습니다. 하지만 보안 측면에서는 약점이 있는데 바로 처음부터 보안 요구사항을 적용하지 않은 상태에서 보안 이슈가 생길 경우 전체 라이프 사이클에 부정적인 영향을 미치게 된다는 점입니다. 이로 인해 데브섹옵스 모델이 나왔습니다. 데브섹옵스는 빠른 개발이라는 데브옵스의 장점에 보안을 추가해 라이프 사이클 전체에 적용하는 방법론입니다.

쿠버네티스 보안의 중요성

데브섹옵스는 보안 안정성을 기반으로 빠른 개발·배포·테스트를 지원하기 위해 컨테이너가 중심이 됩니다. 산출물을 개발하고 배포하는 사이클 중간에 보안 요소가 들어가야 하지만 무엇보다 컨테이너 자체의 보안을 우선적으로 고려해야 합니다. 전 세계에서 가장 많이 사용되면서 컨테이너 오케스트레이션을 위한 사실상의 표준이라고 할 수 있는 오픈소스 SW 플랫폼, 쿠버네티스의 보안에 신경을 써야 하는 이유입니다.

최근 미국 사이버보안인프라보안국(CISA)과 국가안전국(NSA)에서 쿠버네티스 보안에 대한 중요성을 강조하며 쿠버네티스 강화 가이드(Kubernetes Hardening Guidance)를 발표했습니다. 권고 조치는 다음과 같습니다.

 

1. 취약점이 있거나 구성이 잘못된 컨테이너 및 파드를 스캔해야 합니다.
2. 최소한의 권한으로 컨테이너와 파드를 실행해야 합니다.
3. 네트워크 분리를 사용하여 피해받지 않도록 제어가 가능해야 합니다.
4. 방화벽을 사용하여 불필요한 네트워크 연결을 제어해야 합니다.
5. 강력한 인증 및 권한 부여를 사용하여 사용자 및 관리자 액세스를 제한해야 합니다.
6. 관리자가 모든 활동을 모니터링하며 잠재적/악의적 활동에 대응할 수 있도록 로그 감사를 사용해야 합니다.
7. 정기적으로 모든 쿠버네티스 설정을 검토하고 취약성 스캔 및 보안 패치가 적용되어 있는지 확인해야 합니다.

 

위 권고 조치의 대표적인 사항은 컨테이너 이미지의 안정성, 인증과 권한 및 보안 감사 등입니다. 본 아티클에서는 쿠버네티스를 운영하거나 컨테이너 형태의 애플리케이션을 개발하는 엔지니어와 개발자 관점에서 코드 수준에서 컨테이너를 안전하게 유지할 수 있는 방법을 살펴보겠습니다.

쿠버네티스 컨테이너 보안 가이드

(1) 컨테이너 이미지 관리

컨테이너 이미지 관리는 매우 중요합니다. 이미지로 인한 취약점, 구성 결함 및 악성 코드 삽입 등으로 보안 이슈가 발생할 수 있기 때문입니다. 이미지는 애플리케이션을 실행하는데 필요한 모든 구성 요소가 포함된 정적 파일입니다. 보안 업데이트가 누락됐거나 지원되지 않는 구성 요소가 있을 경우 취약점이 발생할 수 있습니다. 만약 취약점이 존재하는 상태로 배포될 경우 보안 위험은 커지게 됩니다.

이미지 취약점이 없더라도 구성이 올바르지 않으면 공격에 노출될 수 있습니다. 불필요한 계정을 갖고 있거나 쓸데없이 네트워크에 노출되는 서비스가 있는 경우에 구성 결함이 발생할 가능성이 있습니다. 또한 컨테이너에 주입된 애플리케이션에 악성코드가 포함되는 경우도 위험합니다. 배포 환경 내 다른 컨테이너나 호스트를 공격할 수 있기 때문입니다. 이를 방지하기 위해서는 사용하는 이미지가 보안이 검증된 것인지 확인해야 하며 OS 패치가 지속적으로 적용되어야 합니다. 또한 컨테이너 이미지 자체에 스캔(Scan)을 하도록 앵커(Anchore)나 클레어(Clair)와 같은 오픈소스 SW를 사용하여 데브섹옵스 파이프라인을 구성하는 것이 좋습니다.

 

 

(2) 네트워크 트래픽 분리

동일한 쿠버네티스 클러스터에서 서로 다른 애플리케이션을 실행하면 특정 애플리케이션이 인접 애플리케이션을 공격할 위험이 있습니다. 네트워크 규칙을 통해 인바운드, 아웃바운드 트래픽을 제한함으로써 트래픽 공격을 방어할 수 있도록 해야 합니다.

다음과 같이 네트워크 규칙을 설정해 아웃바운드 트래픽을 제한하여 네트워크를 분리할 수 있습니다.

kind: NetworkPolicy
metadata:
  name: egress-net-policy
spec:
  podSelector:
 matchLabels:
 app: webserver
egress:
- to:
  - podSelector:
  matchLabels:
  app: database

(3) 파드 보안을 위한 컨텍스트(Context) 적용

파드를 생성할 때 파드와 볼륨에 대한 보안 컨텍스트(Security Context) 기능을 적용할 것을 권장합니다. 파드에 과도한 권한을 부여하면 접근하지 말아야 할 리소스에 접근하게 되어 보안 사고를 일으킬 수 있습니다. 보안 컨텍스트를 통해 불필요한 루트와 커널 접근을 방지할 수 있습니다. 사용 가능한 몇 가지 중요 매개 변수는 다음과 같습니다.

보안 컨텍스트 설정설명
SecurityContext → runAsNonRoot 컨테이너가 루트가 아닌 사용자로 실행되어야 함
SecurityContext → Capabilities 컨테이너에 할당된 Linux 기능을 제어함
SecurityContext → readOnlyRootFilesystem 컨테이너가 루트 파일 시스템에 쓸 수 있는지 여부를 제어함
PodSecurityContext → runAsNonRoot 파드의 일부로 '루트' 사용자가 포함 된 컨테이너의 실행을 방지함

아래는 보안 컨텍스트를 runAsNonRoot로 설정하여 컨테이너가 루트로 실행되는 것을 방지하는 예시입니다.

\spec:
  containers:
    - name: testcontainer
    image: busybox:1.28]
    securityContext:
      runAsNonRoot: true

(4) 파드의 보안 관련 기능 사용 제한

클러스터 관리자는 하나 이상의 PodSecurityPolicy를 작성해 쿠버네티스가 제공하는 보안 관련 기능 사용을 제한할 수 있습니다. PodSecurityPolicy는 사용자가 파드에서 이용할 수 있는 보안 기능을 제어하는 클러스터 수준의 리소스입니다. '클러스터 수준의 리소스'라 함은 정책이 클러스터 전체에 적용된다는 의미입니다. PodSecurityPolicy 리소스의 정책 작업은 Admission Control Plugin에 의해 수행됩니다. PodSecurityPolicy를 적용함으로써 컨테이너가 바인드할 수 있는 포트 범위, 네임 스페이스를 제한해 클러스터를 보호합니다.

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
name: default
spec:
 hostIPC: false
 hostPID: false
 hostNetwork: false
 hostPorts:
 - min: 10000
    max: 12000
privileged: false
  readOnlyRootFilesystem: true
  runAsUser:
   rule: RunAsAny
 fsGroup:
    rule: RunAsAny

마치며

클라우드 네이티브 생태계가 발전하면서 클라우드의 사용 방식이 근본적으로 바뀌고 있습니다. 보안 역시 기존의 엔드포인트 중심에서 클라우드 전체의 라이프 사이클을 아우르는 방향으로 패러다임이 변화하는 중입니다. 그 중심에 쿠버네티스가 있습니다. 기업의 개발자·데브옵스 엔지니어·IT 운영자는 앞서 소개한 사례를 참고하여 쿠버네티스 보안에 만전을 기해야 합니다. 이를 통해 컨테이너 중심의 애플리케이션을 안전하게 보호할 수 있음은 물론 궁극적으로 데브섹옵스 여정의 기초를 탄탄하게 다질 수 있을 것입니다.


References
[1] https://securityaffairs.cp/wordpress/120807/security/kubernetes-quidance.html
[2] https://kubernetes.io/docs/concepts/policy/pod-security-policy/
[3] https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
[4] https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/

 

반응형
반응형

KubeSphere DevOps: A Powerful CI/CD Platform Built on Top of Kubernetes for DevOps-oriented Teams.

https://kubesphere.io/devops/

 

DevOps With Kubernetes And KubeSphere

KubeSphere DevOps offers powerful CI/CD features with excellent scalability and observability on top of Kubernetes for DevOps-oriented teams.

kubesphere.io

 

반응형
반응형

개발자 로드맵 : roadmap.sh

 

Developer Roadmaps

Community driven roadmaps, articles, guides, quizzes, tips and resources for developers to learn from, identify their career paths, know what they don't know, find out the knowledge gaps, learn and improve.

roadmap.sh

Backend

데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.

DevOps

프런트 엔드(Front-end)는 UI(User-Interface)를 가지고 동작하며 백엔드(Back-end)는 UI없이 프로세스 형태로만 존재한다. 프론트엔드와 백엔드는 프로그램 인터페이스와 서비스의 최초 사용자와 관련된 특성을 나타내는데 사용되는 용어이다. 여기서 “사용자”란 사람 또는 프로그램이 될 수 있다. 프론트엔드 응용프로그램은 사용자들과 직접 상호작용을 하는 프로그램이다.

 

Front-end

반응형
반응형

데브옵스(DevOps)

데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.

“코딩 방법을 아는 시스템 관리자로 보는 시각도 있고 시스템 관리자 스킬을 갖춘 개발자로 보는 시각도 있다. 어떤 면에서 두 가지 정의 모두 타당하다. 데브옵스 엔지니어의 주된 역할은 지속적 전달과 지속적 통합 워크플로우를 도입하는 것이고, 이를 위해서는 데브옵스 툴에 대한 이해와 여러 프로그래밍 언어에 관한 지식이 필요하다.”

DevOps toolchain


 
목적
데브옵스의 목적은 전반적인 배포 파이프라인에 걸쳐있다. 여기에는 개선된 배치(deployment) 주기를 포함하며 다음으로 이어질 수 있다:

1.제품 출시까지 걸리는 기간(time to market) 단축
2.새로운 판의 더 낮은 실패율
3.픽스 간 짧아진 리드 타임(상품 생산 시작부터 완성까지 걸리는 시간)
4.복구 시 더 빠른 평균 시간 (새로운 릴리스의 충돌 및 그 밖에 현재의 시스템를 비활성화하는 상황에서)

단순한 프로세스들은 데브옵스 접근을 사용하여 더 프로그래밍 가능하게되고 유동적으로 되고 있다.
데브옵스는 운영 프로세스의 예측 가능성, 효율성, 보안, 유지보수 가능성을 극대화하는 것이 목적이다. 더 가끔씩 자동화가 이러한 목표를 지원한다.

https://www.slideshare.net/arload/devops-125948933/14?src=clipshare

 

DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)

Slide 14 of 59 of DevOps 오픈소스 트랜드 (클라우드, 모바일 중심)

www.slideshare.net

https://www.slideshare.net/awskorea/devops-on-aws-cloud-and-chatops-voice-ops

http://www.datanet.co.kr/news/articleView.html?idxno=132585

 

데브옵스(DevOps)의 현재와 미래 - ChatOps & VoiceOps (윤석찬)

개발과 운영의 조화 ‘데브옵스(DevOps)’ 구현 전략과 사례 - 데브멘토 세미나

www.slideshare.net

 

데브옵스 성공 지름길 ‘기업 문화 변화’·‘툴 체인 활용’ - 데이터넷

클라우드 시대를 맞아 서비스의 지속적인 개발·배포가 중요시되면서 애자일, 데브옵스 등의 개념이 중요해지고 있다. 그러나 국내 기업·기관들은 오랫동안 워터폴 방식의 소프트웨어 개발방법에 익숙하기에 애...

www.datanet.co.kr

▲ 데브옵스 구성도 
▲ 애플리케이션 생명주기 주요단계별 지원 도구 

반응형
반응형


데브옵스(DevOps)는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서, 

소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.


데브옵스의 목적은 전반적인 배포 파이프라인에 걸쳐있다. 

여기에는 개선된 배치(deployment) 주기를 포함하며 다음으로 이어질 수 있다:


  • 더 빠른 타임 투 마켓
  • 새로운 릴리스의 더 낮은 실패율
  • 픽스 간 짧아진 리드 타임(상품 생산 시작부터 완성까지 걸리는 시간)
  • 복구 시 더 빠른 평균 시간 (새로운 릴리스의 충돌 및 그 밖에 현재의 시스템를 비활성화하는 상황에서)

단순한 프로세스들은 데브옵스 접근을 사용하여 더 프로그래밍 가능하게되고 유동적으로 되고 있다.데브옵스는 운영 프로세스의 예측 가능성, 효율성, 보안, 유지보수 가능성을 극대화하는 것이 목적이다. 더 가끔씩 자동화가 이러한 목표를 지원한다.



...

반응형
반응형
DevOps!! 도데체 왜, 어떻게 할까??




데브옵스(DevOps)의 현재와 미래 - ChatOps & VoiceOps (윤석찬)



당신은 DevOps 엔지니어가 아닙니다.






...

반응형
반응형

세 가지 방법 : DevOps를 뒷받침하는 원칙




첫 번째 방법 은 특정 부서 또는 업무 부서의 성과와는 달리 전체 시스템의 성과를 강조합니다. 이는 대규모 부서 (예 : 개발 또는 IT 운영) 또는 개별 기여자 (예 : , 개발자, 시스템 관리자).


IT 부서가 사용할 수있는 모든 비즈니스 가치 흐름에 중점을 둡니다. 즉 요구 사항이 식별되면 (예 : 비즈니스 또는 IT) 개발자가 개발 한 다음 IT 운영으로 전환 한 다음 서비스의 형태로 고객에게 제공됩니다.


첫 번째 방법을 실제로 적용한 결과는 알려진 결함을 다운 스트림 작업 센터로 전달하지 않으며, 로컬 최적화가 글로벌 성능 저하를 일으키지 않고, 항상 흐름을 증가 시키며 항상 시스템의 심오한 이해를 달성하려고 시도하는 것을 포함합니다 (Deming에 따라) .




두 번째 방법 은 왼쪽 피드백 루프에 대한 권리를 창출하는 것입니다. 거의 모든 프로세스 개선 이니셔티브의 목표는 피드백 루프를 단축하고 증폭하여 필요한 수정을 지속적으로 수행 할 수 있도록하는 것입니다.


두 번째 방법의 결과에는 모든 고객, 내외부의 이해 및 응답, 모든 피드백 루프의 단축 및 확대, 그리고 필요한 곳에 지식의 포함이 포함됩니다.




제 3의 길은 두 가지를 육성하는 문화를 창조하는 것입니다 : 지속적인 실험, 위험을 감수하고 실패로부터 배우기; 반복과 연습이 숙달의 전제 조건임을 이해하십시오.


우리는 이것들을 똑같이 필요로합니다. 실험과 위험을 감수하는 것은 우리가 지금까지 해왔 던 것보다 위험 지대에 더 깊숙이 들어가는 것을 의미한다고 할지라도, 우리가 개선하기 위해 계속 노력하도록하는 것입니다. 우리는 너무 멀리 지나갈 때 위험 지대에서 물러나는 데 도움이 될 수있는 기술을 숙달해야합니다.


제 3의 방법의 결과는 일상 업무 개선에 시간을 할당하고, 위험을 감수하는 팀에게 보상하는 의식을 만들고, 탄력성을 높이기 위해 시스템에 결함을 도입하는 것을 포함합니다.


...

반응형
반응형

개발자 로드맵 - Roadmap to becoming a web developer in 2017


https://github.com/WegraLee/developer-roadmap






Balsamiq 을 이용해서 만들었다고 하네요. 



...

반응형

+ Recent posts