DevSecOps에 GitOps가 필수적인 이유
게시 됨: 2022-02-24자동화, 추적 가능성, 특히 사전에 격리된 그룹과 이해 관계자 간의 협업을 위한 DevOps의 이점은 크게 인정됩니다. 그러나 DevOps 그룹은 컨테이너화된 Kubernetes 환경으로 작업을 전환하는 중요한 작업을 수행하기 때문에 오랫동안 시도하고 테스트한 DevOps 전술이 짧아질 수 있습니다. 보안 문제와 함정도 고유한 방법으로 나타납니다.
환상적인 정보는 GitOps가 분산 환경의 안정성을 위해 DevOps의 일부 공백을 채우는 역할을 한다는 것입니다. 이는 GitOps 프로세스가 전체 소프트웨어 수명 주기에 적용되는 가장 안전하고 효과적인 전술로 여기에 정의된 DevSecOps에 매우 도움이 되기 때문입니다.
이 기사에서는 GitOps가 CI/CD를 통해 증가하는 안전 검사와 Kubernetes 클러스터에서 애플리케이션 관리의 작성-배포 단계를 통해 DevSecOps를 위한 필수 프레임워크를 제공하는 방법을 살펴봅니다.
고독한 불변의 현실 자원
GitOps는 다음과 같이 설명할 수 있습니다.
Kubernetes 및 기타 클라우드 고유 시스템을 위한 작동하는 설계로, 컨테이너화된 클러스터 및 목적을 위해 Git 배포, 관리 및 모니터링을 통합하는 최상의 절차 세트를 제공합니다.
최종 CI/CD 파이프라인 및 Git 워크플로가 각 작업 및 개발에 활용되는 프로그램을 정확히 관리하기 위한 개발자 실제 경험 방향의 경로입니다.
원하는 구성이 바로 여기 선언되어 있으므로 Git은 진정한 진실의 고독한 리소스입니다. Kubernetes 내에서 실행되는 GitOps 에이전트가 있으며 Kubernetes 내부의 실제 포인트와 Git에 저장된 검색 포인트를 정기적으로 비교합니다. Git에서 모니터링되는 부서에 병합된 새로운 변형은 즉시 Kubernetes에 적용됩니다. 반대로 Kubernetes에 사용된 모든 핸드북 변형은 기계적으로 Git에서 선언된 이상적인 상태로 다시 되돌아갑니다. 구성 드리프트가 제거됩니다.
Git은 일반적으로 변경 불가능한 구성 덕분에 GitOps에 적용되는 진정한 진실의 하나의 리소스로 적절하게 설명됩니다. 무엇보다도 CI와 CD 간의 문제를 구분하는 경계를 유지하는 데 도움이 됩니다. 이러한 방식으로 CI의 일부로 애플리케이션 발전에 관련된 다양한 방식(풀 리퀘스트, 스크리닝, 커밋 등). — Git에서 계속 분리하십시오.
끌어오기 요청을 빌드하는 개발자의 경우 검토 및 허용된 시간에 끌어오기 요청이 병합되어 향후 조정 시 클러스터에 일상적으로 사용됩니다. 이 작업에는 일반적으로 15분이 소요됩니다.
기본적으로 프로세스는 양방향입니다. 이는 향후 조정 루프가 실행될 때(일반적으로 15분마다) Kubernetes에 직접 제조된 수정이 Git에서 왕복된다는 것을 의미합니다. 그럼에도 불구하고 이러한 상황은 DevOps 인력 구성원 또는 최악의 경우 부정적인 행위자 침입자가 클러스터를 즉시 변경할 때 최고보다 훨씬 적습니다. 이러한 직접 클러스터 변형은 병합 요청 및 승인을 통해 적절하게 검증되지 않았으며 결과적으로 드리프트가 발생할 때 문제에 대한 불변의 진실 공급 역할을 하는 Git의 GitOps 이론을 위반합니다.
드리프트 발생을 완화하기 위한 대안으로 Git에서 사용되지 않은 클러스터에 변경 사항이 제조된 경우 GitOps 검사 리소스가 경고를 보낼 수 있습니다. 이러한 일이 발생하면 감사 추적 덕분에 Git의 소프트웨어 코드는 런타임 자연 환경에서 배포된 컨트롤러의 컨트롤러를 통해 클러스터에 설계된 잘못된 수정을 스왑할 수 있습니다.
반대로 불변성을 얻지 못하면 드리프트가 발생할 수 있습니다. 이것은 네트워크 공격의 당사자 또는 DevOps 직원이 실수로 클러스터 구성을 변경하여 Git에 있는 것과 다를 때 구체화될 수 있습니다. 적절한 GitOps 장비를 사용하여 이러한 일이 발생하면 불일치가 표시되므로 GitOps 프로세스가 제공하는 전형적인 DevSecOps를 상징합니다.
적절한 애플리케이션은 Git 리포지토리의 구성에서 원하는 지점이 Kubernetes 클러스터의 실제 상태와 일치하는지 확인하기 위해 지속적인 검사 시스템을 자동화합니다. 또한 리포지토리의 선언된 조건에서 효과적으로 전용되는 즉시 배포를 조정하고 전체 배포하는 데 사용됩니다.
감사 관리
GitOps가 제공하는 감사 기능은 DevSecOps 지원에도 중요합니다. Git 리포지토리에 사실의 하나의 공급으로 남아 있으면 모든 애플리케이션, 코드 및 구성이 버전 관리되고 보호되는 모든 자연 환경에 필수적인 전체 감사 경로가 유지됩니다. 이 감사 추적은 일반적으로 개발자와 운영 직원에게 동등하게 제공되며, 구매 시 클러스터에서 작동하는 항목을 확인하기 위해 구매합니다(대부분의 사용자는 클러스터 구성에 대한 탐색 전용 액세스 권한으로 제한됨).
개발자는 기능 및 DevSecOps 직원 고객처럼 감사 추적에 항상 의존해야 하는 것은 아니지만 어떤 변화가 발생했으며 발생한 리포지토리 조정의 배경이 된 원동력을 이해하는 기능을 사용할 수 있습니다. . 간단히 말해서 개발자와 모든 DevOps 직원은 Git 로그 하나로 모든 것이 가능합니다.
Git의 감사 추적도 사용 가능하며 빌더가 필요할 때 매우 간단하게 표시할 수 있습니다. 이는 빌더가 이해하는 Git 프로그램 보고서에 프로세스의 마무리 유산이 캡처되어 있기 때문입니다.
감사 추적을 사용할 수 있으므로 문제를 일으킨 앱에 대한 조정을 신속하게 롤백할 수도 있습니다. 이는 클러스터가 손상되거나 잘못 구성된 경우에 특히 유용합니다. 이 경우 클러스터를 처음부터 다시 빌드하는 대신 감사 추적이 저장소에서 찾는 포인트로 구성됩니다. 그런 다음 감사 추적에서 원하는 지점이 있는 클러스터 구성 및 프로그램이 배포되고 재구축 절차가 자동으로 수행됩니다.
'왕국의 열쇠'의 수
빌더는 일반적으로 자동화 서버인 Jenkins에 의존하여 Kubernetes 환경용 제조 파이프라인을 위한 CI/CD를 개발, 시험 및 지원합니다. GitOps가 없다면 개발자는 코드를 직접 배포할 때 Kubernetes 클러스터에 즉시 액세스할 수 있습니다. 다시 말해서, 빌더는 조직의 구성 요소이든 원격으로 작업하는 계약자이든 관계없이 출력 환경에 즉시 액세스할 수 있고 대화할 수 있는 "왕국의 열쇠"를 가질 것입니다. 이것은 거의 이상적인 안전 상황이 아닙니다.
앞서 언급한 경우에 선택할 수 있는 모든 것은 부적절한 사용자 또는 더 나쁜 경우 침입자가 노트북에서 실행할 수 있는 제조 클러스터에 대한 KubeConfig 또는 Kubectl 명령 액세스 권한을 갖도록 하는 것입니다. 공격자가 CI 프로세스와 설정된 자격 증명을 손상시킨 경우, 예를 들어 CI 시스템이 액세스할 수 있는 모든 클러스터에 액세스할 수 있습니다.
GitOps가 사용자(또는 공격자)가 흔적을 남기지 않고 클러스터 구성을 수정하지 못하도록 지원한다는 단순한 사실은 개발자의 정신적 부하를 최소화하는 지원 외에도 운영 및 안전 팀에 주로 중요합니다. 예를 들어, 관리를 획득하면 개발자는 일반적으로 Kubernetes 노드 및/또는 kubectl 명령줄에 직접 액세스할 수 없습니다. GitOps는 빌더가 Git에서 개략적으로 설명하는 거의 모든 것을 조정하지만 빌더에 고유한 액세스 제어 권한이 있는 경우를 제외하고 Kubernetes 클러스터 또는 제조 환경에 대한 수동 액세스를 허용하지 않습니다.
GitOps의 DevSecOps는 CD에 대한 이러한 공격 벡터 상황을 방해하여 "왕국의 열쇠"를 보호하는 방법으로 기능합니다. 공개 소스 Flux와 같은 GitOps 운영자(아래에서 이에 대한 추가 설명)가 Kubernetes 내부에서 실행되고 결과적으로 클러스터에 액세스할 수 있는 경우 제어 획득은 Kubernetes 안전 프레임워크 내에서 계속 유지됩니다. 소비자 접근성은 고유한 그룹 및 그룹 구성원의 네임스페이스에 권한을 할당하여 설정됩니다.
DevSecOps와 GitOps가 다른 사람에게 얼마나 큰 도움이 되는지를 보여주는 사례로, 얼마 전 미 공군의 컴퓨터 소프트웨어 책임자인 미 국방부(DoD) Nicolas Chaillan은 DevSecOps와 GitOps가 어떻게 다른지 설명했습니다. — Flux와 함께 — 미국 보안군 전체를 지원하는 소프트웨어 프로그램 발전에서 중요한 역할을 수행합니다.
Chaillan은 "안전과 보안은 타협할 수 없지만 개발자 자체 회사가 효율성과 속도를 향상하기를 원합니다."라고 말했습니다.
예를 들어, GitOps는 "전체 DoD에서 하나의 Platform Just를 설정하고 롤아웃하는 데 있어 우리의 성취의 핵심"이라고 DoD는 주장합니다. DoD에 따르면 System Just one은 보안 파이프라인이 내장된 "허용되고 강화된 CNCF(Cloud Indigenous Computing Foundation) 호환 Kubernetes 배포, 코드 플레이북으로서의 인프라, 강화된 컨테이너의 모음"입니다.
견제와 균형
DevSecOps 절차는 GitOps 공급 확인 및 균형과 결합됩니다. 이러한 방식으로 액세스 가능성 명령은 개발자 또는 침입자가 CI 기간 동안 백도어, 제로 데이 또는 또 다른 형태의 취약성을 도입하기 위해 공급 코드 저장소에 액세스하는 것을 방지하는 데 도움이 됩니다. 절차. 이것은 단순히 모든 pull 요청이 동료 검토를 받기 때문입니다.
CI 시스템을 지원하는 DevSecOps를 통해 코드에 앞서 사용되는 점검 및 균형은 Git 전용이며 클러스터에 배포됩니다. 개발자는 일반적으로 동료 검토를 거친 pull 요청으로 수정 사항을 게시합니다. 검토 및 승인 후 코드는 Git에 병합되고 검색된 상태의 YAML 파일이 그에 따라 변경됩니다.
원하는 조건이 Kubernetes 클러스터에 즉시 적용됩니다. 앞서 언급했듯이 DevSecOps 기능이 있는 올바른 GitOps 장비는 목표 프로세스의 정확한 조건을 지속적으로 추적하여 Git에 선언된 내용을 왕복하는지 확인합니다. 변동이 있을 경우 경보를 발령하여 시정 조치를 취할 수 있습니다.
DevSecOps의 의견
많은 GitOps 도구가 DevSecOps를 지원합니다. 예를 들어 공개 공급 Flux는 Git 리포지토리를 진정한 진실의 불변 소스로 유지하는 데 도움이 됩니다. Flux의 능력은 또한 전용 및 배포된 코드에 대한 CI/CD 동안 견제와 균형을 위한 접근성 규제로 확장됩니다.
훨씬 더 독단적인 Flux 만남을 위해 오픈 소스 Weave GitOps Main은 많은 클러스터에서 자동화 CI/CD를 활성화하는 첫 번째 방법을 단순화합니다. Weave GitOps Main을 사용하여 GitOps 및 DevSecOps 방법을 배치하는 시스템에는 콘솔에서 몇 가지 복잡하지 않은 명령이 포함됩니다.
Weave GitOps Company는 Kubernetes의 안정적인 애플리케이션 배송 및 자동 운영 관리를 자동화하는 초기 GitOps 플랫폼으로 부상했습니다. 하이브리드 클라우드, 멀티 클라우드 및 에지 아키텍처 전반에 걸쳐 규모에 상관없이
몇 가지 도구는 모두 모니터링을 자동화하여 클러스터 구성이 일반적으로 Git에 있는 것과 일치하도록 보장하여 드리프트를 방지하는 데 도움이 됩니다. 완전하고 사용 가능한 감사 추적을 통해 클러스터를 처음부터 다시 구축할 필요 없이 애플리케이션 및 클러스터 구성 롤백을 필수 기반에서 생성할 수 있습니다.
요약하면 GitOps는 분산된 Kubernetes 환경을 위한 DevOps의 진화를 의미하지만 DevSecOps는 애플리케이션 수명 주기 전반에 걸쳐 GitOps의 CI/CD 안정성을 유지하는 중요한 방법으로 부상했습니다.
Steve Waterworth는 Weaveworks 의 기술 마케팅 감독자 입니다.