Notary Service
[Container image 인증 관련 글 목록]
Docker Notary : Docker Content Trust (DCT)
DCT를 사용해서 Dcoker Hub에 서명된 Trust Image Push 하기
Notary와 DCT를 사용해서 Private Registry에 서명된 Trust Image Push하기
개인 인증서를 사용해서 Notary Service 구동
kubernetes image인증 - Portieris
Notary란?
Image File로 Container를 생성해서 서비스를 제공하는데
사용했던 Image File이 악의적인 용도로 배포된 Image 라면 심각한 피해가 발생 할 수 있음
또는 Registry에 Push되어 있는 Image를 악의적인 누군가가 가로채서 악성 코드를 심거나 위/변조를 할 가능성이 있음
이러한 상황을 방지하기 위해
Image File이 신뢰된 Image 라는 것을 보증해주는 Notary라는 것이 있음
Notary는 Image에 서명을 해서 위/변조 여부를 검증해서
해당 Image의 진실성을 보증해주는 "공증 서비스" 역할을 수행함
[ 참고 ]
Notary 단어 듯 (공증인)
법률 당사자나 관계자의 부탁을 받아 민사에 관한 공정 증서를 작성하며,
사서 증서에 인증(認證)을 주는 권한을 가진 사람.
Notary 의 특징
- 오픈소스
- TUF (The Update Framework)를 기본 Security framework로 사용
- Go Language를 사용하여 개발
- Docker Image의 무결성, freshness를 보장하는 MetaData를 생성, 관리, 배포.
- 서명된 컬렉션을 만들고 키 관리 및 서명 인터페이스를 제공
TUF
TUF란?
Notary Service는 TUF를 기반으로 동작하기 때문에 TUF의 개념에 대해서 알 필요가 있음.
TUF : The Update Framework
요즘 소프트웨어는 정적이지 않고 매우 자주 업데이트가 됨.
이에 따라 업데이트를 관리하는 시스템에 대한 보안이 필요해지게 되어 개발된 것이 바로 TUF.
TUF는 저장소, 서명 Key에 대한 보안을 제공하여 악성코드, key 노출 등 공격을 예방할 수 있음.
TUF는 Linux Foundation에 의해서
Cloud Native Computing Foundation의 일부로써 제공되어 지고
Cloudflare, Datadog, Docker, DigitalOcean, Flynn, IBM, MS, LEAP, Kolide, VMware 같은 회사에 의해 제품에서 사용되어짐.
Uptane이라고 불리는 TUF는 자동차에서 공중파 업데이트를 보호하기 위해서 광범위하게 사용됨.
TUF 설계 원칙
[ Trust ]
정상적으로 신뢰된 파일만 다운로드 받아야함.
파일에 대한 신뢰성은 영원하면 안됨.
갱신되지 않으면 소멸되어야 함.
파일에 대한 신뢰성은 오직 root 만이 부여할 수 있음
[ Mitigating Key Risk (Compromise-Resiliense) ]
암호화에 사용되는 키에 대한 보안.
빠르고 안전하게 키 교체 및 폐기와 같은 보안 기능을 제공해서
키 노출을 최소화하고
키가 노출되더라도 안전성이 유지되는 기능을 제공함.
[ Integrity ]
Server에 저장되어있는 파일에 대한 무결성을 보장
Server의 저장소 자체에 대한 무결성을 보장
[ Freshness ]
소프트웨어가 Update되는 경우는
대부분 Bug 혹은 취약점을 보완하는 Update가 많이 이루어지기 때문에
소프트웨어는 항상 최신상태를 유지해야함.
Client가 Update 요청 시
공격자가 최신 version 소프트웨어를 취약점이 있는 소프트웨어로 바꿔치기 해서
Client에 설치하게 한 후 취약점을 이용해 공격할 수 있기 때문에
Client가 Update하기 위해 최신 version 소프트웨어를 받아오는 과정이 중요함.
그렇기 때문에 TUF에서는
Update 시 현재 version 보다 이전 version 파일은 차단하는 등
Update Process 가 정상적인지 확인해주는 역할을 수행함.
TUF Key
TUF 는 기능 구현 로직을 위해 MetaData와 Role 라는 개념을 사용함
[ MetaData ]
저장소나 application의 상태에 대해 검증가능한 레코드를 생성하는데 사용됨.
[ Role ]
한 그룹이 행할 수 있는 행동을 정의해 놓은것.
Role 은 상위 MetaData를 서명하는데 사용됨.
TUF는 상위 4가지의 설계 원칙을 구현하기 위해
꼭 필요한 최상위 Role 4개를 제공하고 해당 Role 해당하는 Key로 MetaData 를 서명함.
[ Root Key ]
다른 Key들에 대한 정보를 담고 있는 "Root metadata file" 을 서명.
모든 Trust에 대한 Root가 되는 Key.
해당 metadata file에는 root의 ID, timestamp, snapshot, targets의 public key가 존재
이 public key로 다른 metadata file의 서명을 검증
소유자 : Owner
[ Target Key ]
해당 타겟(Docker 에서는 이미지)의 정보를 담고 있는 "Target metadata file" 을 서명.
이 Target metadata file에는 이미지의 File Name list, Size에 대한 Hash 정보가 있음.
소유자 : Owner 또는 Admin
[ Timestamp Key ]
각 MetaData들에 대한 단기 expiry time이 기록되어 있는 "Timestamp metadata file"을 서명.
해당 metadata file에는 이 metadata file의 만료시간, 파일이름, 크기, 가장 최근 snapshot의 Hash가 존재.
- snapshot 파일의 무결성 검증.
새션을 가로채 해킹을 하는 Replay Attack을 방지하기 위해 각 MetaData들은 timestamp로 관리 됨.
server로부터의 요청이 있을때마다 자동으로 생성됨.
소유자 : Notary Service
[ Snapshot key ]
모든 MetaData 파일 자체들에 대한 snapshot 정보가 담겨있는 "Snapshot metadata file"을 서명.
해당 metadata file에는 파일이름, 크기, root, target, delegation의 metadata file Hash가 존재.
- 다른 metadata의 무결성을 검증
소유자 : Owner 또는 Admin, 위임을 통해 multi-sign가능한 사용자
[ Delegation Key ]
delegation metadata file을 서명
Targets metadata file의 내용과 동일
소유자 : 권한을 위임받은 collaborator
Notary Service 아키텍처와 구성요소
Notary Server와 Notary Signer
Notary Client는 하나 또는 그 이상의 (원격)Notary Service로부터 MetaData를 Pull 해옴.
일부 Notary Client는 MetaData를 하나 또는 그 이상의 Notary Service로 Push 함
Client는 Root, Targets, Snapshot MetaData를 생성하고 서명한 뒤에 Notary Server에 MetaData를 Upload함
Notary Service는 Notary Server 및 Signer로 구성됨.
[ Notary Server ]
관련된 DataBase에 있는 여러 신뢰할 수 있는 컬렉션에 대한 서명된 TUF MetaData files를 저장하고 업데이트함.
Upload 되어있는 모든 MetaData는 유효하고 서명되어있으며 일관됨을 보장함.
TimeStamp MetaData를 생성함.
신뢰할 수 있는 collection의 가장 최신이며 유효한 MetaData를 저장하고 Client에게 제공한다.
[ Notary Signer ]
개인키를 Notary Server DataBase로부터 분리된 DataBase에 저장함.
키는 Javascript Object Signing and Encryption을 사용하여 암호화되어 있음.
Notary Server가 요청하면 언제든지 키를 가지고 서명 작업을 수행함.
Client - Server - Signer 의 Sequence Diagram
아래는 Notary의 Client, Server, Signer의 흐름을 표현한 그림.
(참고)
Notary Server는 선택적으로 JWT(JSON Web Tokens)을 사용하여 Client 인증을 지원할 수 있음.
JWT를 사용하기 위해서는 접근제어를 관리하는 authorization Server와, cert bundle가 필요함
cert bundle = 토큰을 서명에 사용되는 공개키.
상위 그림은 JWT 를 사용하는 경우임.
[그림의 1번]
Notary Server 에서 Token 인증이 활성되어있는 상태에서
새로운 MetaData의 Update Request를 Notary Server로 전송함.
하지만 Token 정보가 없기 때문에 인증 401 오류가 발생
[그림의 2번]
Client는 HTTPS를 통한 기본 인증을 통해 authorization Server에 로그인하고,
다음 향후 요청에 필요한 Bearer Token을 받아옴.
[그림의 3번]
Client가 새로운 MetaData 파일을 Bearer Token 과 함께 Upload 하면
Notary Server는 충돌 확인을 위해
이전 Version의 MetaData와 충돌되는 항목이 있는지 파일들을 검사하고
서명, 체크섬, Upload된 MetaData의 유효성을 검증함.
[그림의 4번]
Upload된 MetaData가 검증되면,
Notary Server에서 Timestamp, Snapshot MetaData를 생성하고
여기서 생성된 Timestamp, Snapshot MetaData를 서명받기 위해 Notary Signer로 전송
[그림의 5번]
Notary Signer는 Signer DataBase로부터 암호화된 개인키를 검색하고, 복호화하여,
해당 개인키를 사용해서 MetaData를 서명함.
서명이 성공하면 서명된 MetaData를 Notary Server에게 돌려보냄.
[그림의 6번.]
Notary Server 에서 생성한 MetaData와
Client에서 Upload하고자 하는 Metadata (Root, Target, Snapshot)를
TUF DataBase에 저장함.
생성된 timestamp와 snapshot MetaData는
Client가 Upload 한 MetaData 파일이 신뢰할 수 있는 컬렉션에 대해 가장 최신임을 인증함.
마침내 Notary Server는 Client에게 200을 return 해주며 Upload가 완료되었음을 알림.
[그림의 7번.]
Client는 유효한 Bearer Token을 사용하여
Server로부터 만료되지 않은 최신 MetaData를 내려받을 수 있음
(Timestamp가 만료되지 않은 경우)
Notary Server는 MetaData가 만료되지 않았으므로 DataBase에서 MetaData만 가져오면 됨.
(Timestamp가 만료된 경우)
Notary Server는 새로운 timestamp를 생성하고,
서명을 위해 Notary Signer를 요청하고,
새로 생성된 timestamp를 DataBasese에 저장하는 전체 시퀀스를 다시 한번 실행해야함.
그런 다음 저장된 MetaData와 함께 새로운 timestamp를 요청하는 Client에게 보냄.
제 글을 복사할 시 출처를 명시해주세요.
글에 오타, 오류가 있다면 댓글로 알려주세요! 바로 수정하겠습니다!
참고
[Docker Notary]
https://docs.docker.com/notary/
https://gruuuuu.github.io/cloud/docker-notary/#
[TUF]
https://gruuuuu.github.io/security/tuf/#
https://theupdateframework.io/
'클라우드 > Docker' 카테고리의 다른 글
| 12. DCT를 사용해서 Docker Hub에 서명된 Trust Image Push 하기 (0) | 2020.11.08 |
|---|---|
| 11. Docker Notary : Docker Content Trust ( DCT ) (3) | 2020.11.08 |
| 09. Docker Version Update (0) | 2020.09.21 |
| 08. Docker htpasswd 명령 실패 오류 (0) | 2020.09.15 |
| 07. Docker login 실패 오류 해결법 (1) | 2020.09.15 |