맹군’s 블로그

Dockerfile 내 구문들이 처리되는 방법을 지시하는 구문을 의미한다.
# directive = value 형식의 특수한 주석 형태로 기재한다.
Build 단계로 표시되지 않고, build에 layer를 추가하지도 않는다.
Parser directive가 한번 처리되고 나면 docker는 추가적인 parser directive를 찾지 않는다. Parser directive 이 후 주석, 빈 줄, builder 명령이 처리되고 나면 Parser directive가 나타나더라도 단순한 주석으로 처리된다. 따라서 Parser directive는 Dockerfile 맨 위에 위치해야 한다.
Case-insensitive 성질을 갖지만 convention은 소문자 기재이다.
Parser directive 위에 빈 줄을 포함하는 것 또한 Convention이다. 따라서 line continuation character는 지원되지 않는다.
현재 지원되는 Parser directive는 2 가지이다.
    
syntax
escape
Syntax
# syntax=[remote image reference]
사용 예:
# syntax=docker/dockerfile:1
# syntax=docker.io/docker/dockerfile:1
# syntax=example.com/user/repo:tag@sha256:abcdef...
Syntax directive는 BuildKit 이라는 builder backend를 사용하는 경우에만 쓸 수 있고 Dockerfile을 build하는데 사용되는 Dockerfile syntax의 위치를 정의한다.
Docker에서 Dockerfile을 build하는 default syntax말고 custom dockerfile implementations로 build하기 위해서 사용한다.
Escape
# escape=\ (backslash)
or
# escape=` (backtick)
Escape directive는 Dockerfile 내에서 사용되는 escape 문자를 지정할 때 사용한다. escape directive가 없는 경우 default value는 \ (backslash)이다. 해당 기능은 주로 Windows OS에서 build하는 경우 사용하게 된다. Unix-based OS (MacOS, Linux 등)에서는 escape 문자로 \ (backslash)를 사용하고 directory path separator로 / (slash)를 사용하지만, Windows OS는 escape 문자로 `(backtick)을 사용하고 directory path separator로 \ (backslash)를 사용한다.
Dockerfile에서 default escape character는 \ (backslash)이므로 Windows의 directory path separator를 표기하기 위해서는 Windows PowerShell처럼 \\을 사용해야 한다. 이는 사용에 불편함을 주고 예기치 않는 build 실패를 유발할 수 있다. 따라서 Escape directive로 escape 문자를 ` (backtick)으로 지정해버리면 문제를 간단하게 해결할 수 있다.

[Dockerfile] Parser directive

집에서 사용하는 랩탑의 드라이브 용량을 TreeSize를 통해 확인해보니 C 드라이브가 100 GB 정도 밖에 남아있지 않았다. 어느 부분이 용량을 많이 차지하는가 확인해보니 C:\에 pagefile.sys가 17 GB, hiberfil.sys가 6.3 GB 정도 차지하고 있었다.
해당 파일들이 뭐하는 파일인지 검색해봤다.
hiberfil.sys
This file is something that Windows uses to help your PC wake from hibernation.
https://www.techadvisor.co.uk/how-to/windows/what-is-hiberfilsys-can-i-delete-it-3681469/
pagefile.sys
Windows uses pagefile.sys for storing the data that would otherwise be in the computer’s random access memory (RAM). Sometimes there simply isn’t enough capacity to hold all the necessary files in RAM, so pagefile.sys sits on your hard drive or SSD (C:\pagefile.sys) ready to receive data as necessary, and typically the least-used files in RAM are ‘paged’ out to this file.
It also has another role: storing the information about the computer’s state in case there’s a crash or a power cut.
https://www.techadvisor.co.uk/how-to/windows/what-is-pagefilesys-3608749/
hiberfil.sys는 Windows에서 PC를 최대 절전 모드에서 해제할 때 사용하는 파일이라고 한다. pagefile.sys는 RAM 용량이 모자라는 경우 HDD나 SDD를 RAM처럼 사용하기 위한 일종의 swap 파일 역할을 수행하고 crash가 발생하거나 전원이 끊기는 경우 컴퓨터의 상태에 관한 정보를 저장하는 역할도 수행한다고 한다.
1. pagefile.sys 사용 해제
고급 시스템 설정 > 시스템 속성 > 고급 > 성능 > 설정
성능 옵션 > 고급 > 가상 메모리 > 변경
“모든 드라이브에 대한 페이징 파일 크기 자동 관리” 옵션 해제, “페이징 파일 없음” 선택
2. hiberfil.sys 사용 해제
CMD나 PowerShell을 관리자 권한으로 실행한 후 다음의 cmdlet을 입력한다.
PS C:\> powercfg -h off

[Windows] pagefile.sys, hiberfil.sys

Application Gateway란?
[MS Docs] Application Gateway란?
Azure에서 제공하는 Layer 7 load balancer로 Web application에 대한 Traffic을 관리할 수 있도록 하는 Web Traffic Load Balancer resource이다. AWS에서는 유사한 기능을 하는 resource를 Application Load Balancer(ALB)라고 부른다.
기존의 Laod balancing 장치는 Transport layer (OSI layer 4 - TCP & UDP)에서 작동하고 원본 IP 주소와 Port를 기반으로 대상 IP 주소와 Port에 Traffic을 Routing하지만 Application gateway는 Packet의 내용을 확인하고 그 내용에 따라 Traffic을 특정 서버에 분배하는 과정을 추가로 거친다. 때문에 L4 load balancing 외에도 URI 경로 또는 Host Header와 같은 HTTP 추가 특성 (URI, Cookie 등)을 기반으로 Routing 결정을 내릴 수 있다.
예를 들어, URL을 기반으로 Traffic routing이 가능하다. /images 가 request의 URL에 포함되어 있는 경우 image에 대해 구성된 Server (pool)의 특정 집합으로 traffic을 routing하거나, /videos가 URL에 포함된 경우 해당 traffic은 비디오에 최적화된 다른 Pool로 routing이 가능하다.
또한 HTTP Request의 Cookie 값에 따라 특정 Server에 Traffic을 분산하는 등 Client의 요청을 보다 세분화해 Server에 전달하거나 Azure WAF를 붙여서 비정상적인 Traffic을 Filtering 하는 것도 가능하다.
현재 지원하는 L7 protocol 은 HTTP, HTTPS, WebSocket, HTTP/2 이며 L4 부하 분산 알고리즘은 Round-Robin 알고리즘을 사용한다.
구성요소
Listener
연결 요청을 확인하는 Logical entity이다. Protocol, Port, Hostname, IP address가 Listener의 구성과 일치하는 Request를 수락한다. Internet 구간의 통신에서 사용하는 인증서를 저장한다.
Routing Rule
Routing 방법을 결정하는 구성 요소로 Listener, Backend Pool, Backend http configuration을 binding한다. Binding된 Listener로 들어오는 request를 Backend pool로 routing하거나 redirection하도록 설정할 수 있다.
HTTP Configuration
HTTP Configuration은 Backend와의 통신 방식, 인증서 등을 저장하는 Object이다. HTTP Configuration에서 지정할 수 있는 설정은 아래와 같다.
Cookie 기반 선호도
Host Header의 Cookie 값을 사용해 사용자 Session을 동일한 Server에 유지
Hostname 재정의
Packet의 Host Header를 rewriting 할지에 대한 설정
Backend 경로 재정의
특정 경로(URL)에 대한 요청이 다른 경로로 routing 될 수 있도록 URL의 경로를 재정의
사용자 지정 Probe
Backend의 상태를 체크하는 사용자 지정 Probe를 mapping
Health Probe
Backend의 상태를 확인하기 위해 정기적으로 backend와 통신하는 Component이다. L4 Load Balancer에도 존재하는 Component이며 backend와 Health Probe가 통신이 안되는 unhealthy 상태인 경우에는 해당 backend server에 문제가 생긴 것이므로 이런 경우 해당 backend는 Application gateway의 backend pool에서 자동으로 제외하고 나머지 backend에만 traffic을 routing한다. HTTP Configuration과 mapping된다.
Application layer (L7) load balancing
https://velog.io/@makeitcloud/란-L4-load-balancer-vs-L7-load-balancer-란
https://www.nginx.com/resources/glossary/layer-7-load-balancing/
Application Layer (L7)에서 부하를 분산한다. 따라서 L3의 IP, L4의 Port 정보 뿐만 아니라 HTTP data (URI, Cookie, HTTP Header 등)을 기반으로 routing할 수 있다. 이는 Packet의 내용을 확인하고 그 내용에 따라 로드를 특정 서버에 분배하는 것이 가능함을 의미한다. 예를 들어, URI나 HTTP Header의 Cookie 값에 따라 특정 서버에 traffic을 분산하는 등 Client의 요청을 보다 세분화해서 서버에 전달하거나 특정 패턴을 가진 바이러스 탐지, DoS/DDoS 등의 비정상적인 트래픽을 필터링할 수 있다. Azure에서는 WAF 정책을 구성해 적용할 수 있게 되어 있다.
Application Gateway 작동 원리
[MS Docs] Application Gateway의 작동 방식
SKU
[MS Docs] v1 SKU와 v2 SKU 간 기능 비교

[Azure] Application Gateway

1. Git config에 template 추가
git config --global commit.template ~/.gitmessage
명령을 실행하면 .gitconfig파일에 다음과 같이 설정된다.
[commit]
    template = ~/.gitmessage
2. Commit message template 작성
Template file로 등록한 ~/.gitmessage 파일을 작성한다.
# <type>: <subject>
##### Subject 50 characters ################# -> |
# Body Message
######## Body 72 characters ####################################### -> |
# Issue Tracker Number or URL
# --- COMMIT END ---
# Type can be
#   feat    : new feature
#   fix     : bug fix
#   refactor: refactoring production code
#   style   : formatting, missing semi colons, etc; no code change
#   docs    : changes to documentation
#   test    : adding or refactoring tests
#             no productin code change
#   chore   : updating grunt tasks etc
#             no production code change
# ------------------
# Remember me ~
#   Capitalize the subject line
#     제목줄은 대문자로 시작한다.
#   Use the imperative mood in the subject line
#     제목줄은 명령어로 작성한다.
#   Do not end the subject line with a period
#     제목줄은 마침표로 끝내지 않는다.
#   Separate subject from body with a blank line
#     본문과 제목에는 빈줄을 넣어서 구분한다.
#   Use the body to explain what and why vs. how
#     본문에는 "어떻게" 보다는 "왜"와 "무엇을" 설명한다.
#   Can use multiple lines with "-" for bullet points in body
#     본문에 목록을 나타낼때는 "-"로 시작한다.
# ------------------
3. Test
Windows 환경에서 Git commit 하는 경우 아래처럼 Commit message가 template으로 출력된다.
그림에서 보면 ^M 이라는 글자가 매 줄마다 붙어있는 것을 확인할 수 있다. 이는 Windows와 Unix/Linux의 차이에서 비롯된 부분이다. Windows의 경우 line ending에 CR(Carriage-Return, \r)과 LF(Line Feed, \n)을 사용하고 UNIX/Linux/Mac은 LF(“\n”)만 사용한다. Git은 리누스 토발즈가 개발한 프로그램이므로 당연히 Linux base이다. 따라서 Windows에서 엔터로 줄바꿈을 하면 Git에서는 Windows의 CR-LF 입력 중 LF만 가지고 개행 처리하고 CR은 글자로 남겨둔다. 이로 인해서 ^M 글자가 남게 되는 것이다.
이 글자를 삭제하기 위해서는 git editor가 vim 인 경우 :%s/\r$를 입력해주면 된다. 하지만 매번 입력해주면 귀찮으므로 나의 경우 WSL에서 ~/.gitmessage 파일을 다시 생성하기로 했다.
위의 그림처럼 정상적으로 출력되는 것을 확인할 수 있다.
Reference
https://ujuc.github.io/2020/02/02/git-commit-message-template-man-deul-gi/
https://stackoverflow.com/questions/1110678/m-at-the-end-of-every-line-in-vim

[Git] Commit message template

IPsec (IP Security)
Network Layer (L3) 상에서 IP Packet 단위로 ‘인증’, ‘암호화’, ‘키관리’를 하는 Internet Protocol Suite.
IPsec은 Internet Protocol Security의 약어로서 통신 중 network layer에서의 보안을 위한 표준이다. IPsec은 인터넷 상에서 VPN(Virtual Private Network)을 구현하는데 사용될 수 있도록 IETF (Internet Engineering Task Force)에서 개발된 protocol set이다. 이는 네트워크상의 IP layer에서의 보안에 중점을 두었으며, 사설 및 공중망을 사용하는 TCP/IP 통신을 보다 안전하게 유지하기 위한 end-to-end encryption과 authentication을 제공한다.
출처 : https://wodonggun.github.io/wodonggun.github.io/study/What-is-IPsec.html
VPN에서 Internet 경유 구간에 일종의 보안 통로인 Tunnel을 형성해줌 (L3에서 동작)
대부분의 OS에서 IPsec 기능을 직접 제공
차세대 인터넷 프로토콜인 IPv6에서는 IPsec을 기본적으로 포함
관련 RFC (Request for Comment)
[RFC 2411] : IP Security Document roadmap
[RFC 2401] : Security Architecture for Internet Protocol
[RFC 2402] : IP Authentication Header
[RFC 2406] : IP Encapsulating Security Payload (ESP)
[RFC 2408] : Internet Security Association and Key Management Protocol (ISAKMP)
[RFC 2407] : The Internet IP Security Domain of Interpretation for ISAKMP
[RFC 2409] : The Internet Key Exchange (IKE)
[RFC 3554] : On the Use of Stream Control Transmission Protocol (SCTP) with IPsec
[RFC 4308] : Cryptographic Suites for IPsec
IPsec 주요 보안 서비스
출처 : https://itragdoll.tistory.com/52
통신 상대방 인증 (Peer Authentication)
데이터 원천 (근원지) 인증 (Data Origin Authentication)
Message Authentication Code를 통해 IP Packet이 올바른 송신처로부터 온 것임을 보장
비연결형 무결성 (Connectionelss Integrity)
    
Message Authentication Code (MAC)를 통해 각 IP Packet 별로 무결성 보장
송신 측에서 인증데이터 / MAC 값을 계산하여 전송하고 수신 측에서 이를 검증
기밀성 (Confidentiality)
    
대칭 암호화를 통해 기밀성을 제공. 단, AH Protocol은 암호화를 지원하지 않으며 ESP Protocol만 암호화를 지원
(제한된 트래픽 흐름의 기밀성) ESP/터널모드의 경우 New IP헤더를 통해 터널 / 보안 게이트웨이 구간의 트래픽 흐름 정보는 노출되지만 원본 IP 헤더는 암호화되어 있기 때문에 터널/보안 게이트웨이와 종단 노드 구간의 트래픽 흐름의 기밀성은 보장
접근 제어 (Access Control)
    
보안 정책을 통해 송수신 IP패킷에 대한 시스템 접근을 제어
접근 제어 방식은 IP 패킷의 허용, 폐기, 보호 등이 있음
재생공격 방지 (Replay Attack Protection) 등
    
송신 측에서 IP 패킷별로 순서번호(Sequence Number)를 전송하고 수신측에서 해당 보안연관(SA : Security Association)에 순서번호를 유지하고 이를 검증함으로써 Replay attack을 방지
Replay Attack
A replay attack (also known as playback attack) is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and re-transmits it, possibly as part of a spoofing attack by IP packet substitution. This is one of the lower-tier versions of a man-in-the-middle attack.
Another way of describing such an attack is: “an attack on a security protocol using replay of messages from a different context into the intended (or original and expected) context, thereby fooling the honest participant(s) into thinking they have successfully completed the protocol run.”
Security Association (SA)
An SA is a set of IPsec specifications that are negotiated between devices that are establishing an IPsec relationship. These specifications include preferences for the type of authentication, encryption, and IPsec protocol that shuold be used when establishing the IPsec connection. An SA can be either unidirectional or bidirectional, depending on the choices made by the network administrator. An SA is uniquely identified by a Security Parameter Index (SPI), an IPv4 or IPv6 destination address, and a security protocol (AH or ESP) identifier.
http://elearning.kocw.net/document/lec/2011_2/andong/Network/06.pdf
SA : IP 보안 프로토콜, 프로토콜의 운용모드, 보안 알고리즘, 보안 키와 키의 수명 등에 대한 통신 쌍방 간의 합의
키 관리 프로토콜(ISAKMP)은 SA의 설정 및 해제 기능 담당
각 Host는 송신과 수신 트래픽을 위해 별도의 SA 설정
IPsec 운용 모드
IP의 내용(Payload)만을 보호하느냐, 아니면 Header까지 모두 보호하느냐에 따라서 전자는 전송 모드 (Transport mode), 후자는 터널 모드 (Tunnel mode)라고 구분한다.
1. Transport Mode
Transport mode는 아래의 그림과 같이 Tunnel의 범위가 끝단에서 끝단까지 그려져 있다. 이는 Transport layer라는 L4는 End-to-End의 데이터 전송을 보장하기 때문이다.
이미지 출처 : https://brunch.co.kr/@younggiseo/97
이미지 출처 : https://reakwon.tistory.com/108
보낼 데이터가 OSI 7 Layer의 L4까지만 내려온 상태에서 데이터 보호 절차를 거친다. 출발지와 도착지의 정보를 담고 있는 IP Header가 IPsec Header 밖에 위치하므로 암호화되지 않는다. 따라서 IP Header는 보호되지 않는다.
2. Tunnel Mode
Internet Protocol을 완벽하게 보안처리하기 위한 송수신 기기간의 가상 파이프로 메시지를 주고 받아 ‘터널링’을 구축했다라고도 부른다. 끝단과 끝단이 아니라 가운데 장비 간에 기둥 모양의 파이프가 그려진다.
이미지 출처 : https://brunch.co.kr/@younggiseo/97
이미지 출처 : https://reakwon.tistory.com/108
L3에서 주고받는 Data 전체 (data + IP Header)를 암호화하고 Header가 부착된다. 출발지와 도착지 주소 정보를 갖는 IP Header도 암호화되므로 네트워크 상에서 이 Packet이 어디로 가는지 식별할 수 없게 된다. 따라서 Tunnel 입구를 지나칠 때 도착지인 반대편 장비(목적지)에 대한 주소 정보가 포함된 새로운 IP Header를 추가한다. 즉 최초 출발지와 최종 목적지에 대한 Traffic의 기밀성(Confidentiality)은 보장된다. 단, 새로 추가된 IP Header의 구간 정보는 식별 가능하므로 전송 도중 유출될 수 있다 (제한적 Traffic 흐름의 기밀성). 보통은 Router가 이러한 새로운 Header를 추가해 준다.
Protocol
IPsec은 인증에 대해서만 검사하는 Authentication Header (AH) Protocol과 Payload 전체를 보호하여 기밀성(Confidentiality)을 제공하는 Encapsulating Security Payload (ESP) Protocol을 제공한다.
1. Authentication Header (AH) Protocol
발신지 Host를 인증하고 IP Packet의 무결성(Integrity)을 보장한다. Authentication을 위해 Hash 알고리즘과 대칭 키가 사용되어 Message Digest를 생성하고 Header에 삽입한다. AH는 인증과 무결성은 보장하지만 기밀성은 보장하지 않는다.
Authentication Header의 구성
이미지 출처 : https://reakwon.tistory.com/108
Packet Processing (출처 : https://themeat.tistory.com/104)
    
Outbound
        
SA 조사 (SA Lookup)
일련번호 생성 (Sequence Number Generation)
무결성 검사 값 검증 (ICV Verification)
조각화 (Fragmentation)
Inbound
        
재조립 (Reassembly)
SA 조사
일련번호 검증 (Sequence Number Verification)
무결성 검사 값 검증 (ICV Verification)
Transport mode에서의 AH
Tunnel mode에서의 AH
2. Encapsulating Security Payload (ESP) Protocol
Message Authentication Code와 암호화를 사용해 인증과 기밀성을 제공한다. 또한 AH가 보장하는 IP Packet의 무결성 등 AH가 제공하는 모든 서비스를 모두 보장할 수 있다. 인증과 암호화는 선택적으로 적용할 수 있어 인증만 적용하거나 인증 + 암호화 모두 적용 가능하다.
Encapsulating Security Payload Header의 구성
이미지 출처 : https://reakwon.tistory.com/108
Packet Processing (출처 : https://themeat.tistory.com/104)
    
Outbound
        
SA 조사 (SA Lookup)
패킷 암호화 (Packet Encryption)
일련번호 생성 (Sequence Number Generation)
무결성 검사 값 검증 (ICV Verification)
조각화 (Fragmentation)
Inbound
        
재조립 (Reassembly)
SA 조사
일련번호 검증 (Sequence Number Verification)
무결성 검사 값 검증 (ICV Verification)
패킷 복호화
Transport mode에서의 ESP
Tunnel mode에서의 ESP
Reference
https://reakwon.tistory.com/108
https://brunch.co.kr/@younggiseo/97
https://itragdoll.tistory.com/52
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/overview-of-ipsec.html#id-overview-of-ipsec
https://en.wikipedia.org/wiki/Replay_attack
http://www.ktword.co.kr/abbr_view.php?m_temp1=2029
https://wodonggun.github.io/wodonggun.github.io/study/What-is-IPsec.html
http://elearning.kocw.net/document/lec/2011_2/andong/Network/06.pdf
https://themeat.tistory.com/104

맹군’s 블로그https://mhsong55.github.io

[Dockerfile] Parser directive

[Windows] pagefile.sys, hiberfil.sys

[Azure] Application Gateway

[Git] Commit message template

IPsec

맹군’s 블로그
https://mhsong55.github.io