보안을 하면서 Http를 Https로 바꾼다고 해커로부터의 공격에서 안전하지 않을수도 있다는것을 알았다. Https를 구성하고 안전한 프로토콜을 사용해야만 한다는 사실도 알았다. 그리고, Https를 구성하기 위해 서버와 서버, 서버와 클라이언트 사이에서 서로를 인증할 인증서와 인증키가 필요하다. 보안을 한다는건 서버와 클라이언트 또는 서버와 서버끼리 데이터를 주고 받을때 데이터를 암호화시켜 해커로부터 공격을 받더라도 해커가 데이터의 내용을 알수 없도록하여 데이터 유출이나 피해를 막는데 그목적이 있다. 이때 데이터를 어떻게 암호화를 시킬것인지에 대한 프로세스를 우리는 암호화 알고리즘이라고 부른다. 

암호화 알고리즘을 이용하여 서버와 클라이언트 사이에서 사용할 인증서와 인증키를 생성하기도 하고, 데이터베이스의 인증 패스워드를 암호화시키기도 한다. 이 과정에서 우리는 데이터를 어떤 암호화 알고리즘을 선택하여 암호화를 할지 결정하는데 이때 사용하는 암호화 알고리즘에 MD5, SHA1, SHA2와 같은 알고리즘이 존재를 한다. 그래서 오늘은 어떤 알고리즘을 권장하는지 그렇지 않은 알고리즘은 어떤것인지 왜 사용을 해야하고 왜 사용을 하면 안되는지를 알아보았다.

아래 그림은 어떤 방법으로 암호화를 했느냐에 따른 결과를 보여주는 그림으로 MD5보다는 SHA1이 좀 더 암호화가 복잡하고, SHA1보다 SHA256이 암호화가 더 복잡하다는 걸 알 수 있다. 암호화 알고리즘 역시 오래된 기술이기 때문에 검색을 통해 많은 자료들을 찾아볼수 있다.

MD5

MD5(Message-Digest algorithm 5)는 128비트 암호화 해시 함수이다. RFC 1321로 지정되어 있으며, 주로 프로그램이나 파일이 원본 그대로인지를 확인하는 무결성 검사 등에 사용된다. 1991년에 로널드 라이베스트가 MD4를 대체하기 위해 고안했다. 그러나, 1996년에 MD5의 설계상 결함이 발견되었다. 이것은 매우 치명적인 결함은 아니었지만, 암호학자들은 해시 용도로 SHA-1과 같이 다른 안전한 알고리즘을 사용할 것을 권장하기 시작했다. 2004년에는 더욱 심한 암호화 결함이 발견되었고. 2006년에는 노트북 컴퓨터 한 대의 계산 능력으로 1분 내에 해시 충돌을 찾을 정도로 빠른 알고리즘이 발표되기도 하였다. 현재는 MD5 알고리즘을 보안 관련 용도로 쓰는 것은 권장하지 않으며, 심각한 보안 문제를 야기할 수도 있다. 2008년 12월에는 MD5의 결함을 이용해 SSL 인증서를 변조하는 것이 가능하다는 것이 발표되었다.

SHA

SHA(Secure Hash Algorithm, 안전한 해시 알고리즘) 함수들은 서로 관련된 암호학적 해시 함수들의 모음이다. 이들 함수는 미국 국가안보국(NSA)이 1993년에 처음으로 설계했으며 미국 국가 표준으로 지정되었다. SHA 함수군에 속하는 최초의 함수는 공식적으로 SHA라고 불리지만, 나중에 설계된 함수들과 구별하기 위하여 SHA-0이라고도 불린다. 2년 후 SHA-0의 변형인 SHA-1이 발표되었으며, 그 후에 4종류의 변형, 즉 SHA-224, SHA-256, SHA-384, SHA-512가 더 발표되었다. 이들을 통칭해서 SHA-2라고 하기도 한다.

SHA-1은 SHA 함수들 중 가장 많이 쓰이며, TLS, SSL, PGP, SSH, IPSec 등 많은 보안 프로토콜과 프로그램에서 사용되고 있다. SHA-1은 이전에 널리 사용되던 MD5를 대신해서 쓰이기도 한다. 혹자는 좀 더 중요한 기술에는 SHA-256이나 그 이상의 알고리즘을 사용할 것을 권장한다. SHA-0과 SHA-1에 대한 공격은 이미 발견되었다. SHA-2에 대한 공격은 아직 발견되지 않았으나, 전문가들은 SHA-2 함수들이 SHA-1과 비슷한 방법을 사용하기 때문에 공격이 발견될 가능성이 있다고 지적한다. 미국 표준 기술 연구소(NIST)는 SHA-3로 불리는 새로운 암호화 해시 알고리즘에 대한 후보를 공모하였다.

SHA-256

SHA-256은 현재가장 많은 분야에서 채택하여 사용되고 있는 암호 방식이다. 출력 속도가 빠르다는 장점을 갖고 있다. 또한 단방향성의 성질을 띄고 있는 암호화 방법으로 복호화가 불가능하다. SHA-384, 512, SHA-3보다는 유효 보호 수준이 낮을 지는 모르지만, 현재까지 안정성 문제에서도 큰 단점이 발견되지 않았고, 속도가 빠르기 때문에 인증서, 블록체인 등 많이 사용되고있으며, SHA-2라고 하면 SHA-256이라고 말할 정도로 상용화가 잘 되어있다.

* 단방향 알고리즘

단방향(One-Way) 암호화는 평문을 암호화했을 때 다시 평문으로 복호화할 수 없는 암호화이다. 대표적으로 많이 사용되는 알고리즘이 SHA-256 암호화 알고리즘이다. SHA-256은 임의의 길이 메시지를 256 비트(bits)의 축약된 메시지로 만들어내는 해시 알고리즘이다. 데이터의 수정과 변경을 검출 할 수 있으나 인증은 불가능하다. 인증에 사용하기 위해 메시지 인증 코드와 디지털 서명이 요구된다.

* 안정성

SHA-1은 구글 클라우드 서버를 기반으로 수행된 연구 사례에서 약 900경의 해시 연산을 통해 충돌이 발견된 경험이 있다. 이것을 바탕으로 근본적인 차이가 많이 없는 SHA-256의 안정성이 얼마나 높고 유지될 수 있다고 언급하기에는 어려움이 있다. 하지만 실질적으로 해시 취약점을 대상으로 하는 양자 컴퓨터가 출시되지 않는 이상 최소 근 10년가량은 안전하다는 판단할 수 있다. SHA-256의해 제공되는 해시 알고리즘은 일정한 컴퓨터 연산 속도의 향상을 염두에 둔 가정에도 산술적으로 매우 강력하다는 결론에 도달하게 된다. 

이렇게 해서 MD5와 SHA1, SHA256에 대해 간략하게 알아보았다. 너무 어려워서 이해가 가질 읺지만 적어도 암호화 알고리즘에서 어떤 것이 주로 사용되는지는 알수 있을것 같다. 이 외에도 RSA나 DSA, ED25519와 같은 해시 알고리즘에 대해서도 알아보았다.

RSA

RSA는 공개키 암호시스템의 하나로, 암호화뿐만 아니라 전자서명이 가능한 최초의 알고리즘으로 알려져 있다. RSA가 갖는 전자서명 기능은 인증을 요구하는 전자 상거래 등에 RSA의 광범위한 활용을 가능하게 하였다. RSA는 두 개의 키를 사용한다. 여기서 키란 메시지를 열고 잠그는 상수(constant)를 의미한다. 일반적으로 많은 공개키 알고리즘의 공개키(public key)는 모두에게 알려져 있으며 메시지를 암호화(encrypt)하는데 쓰이며, 암호화된 메시지는 개인키(private key)를 가진 자만이 복호화(decrypt)하여 열어볼 수 있다. 하지만 RSA 공개키 알고리즘은 이러한 제약조건이 없다. 즉 개인키로 암호화하여 공개키로 복호화할 수도 있다. 공개키 알고리즘은 누구나 어떤 메시지를 암호화할 수 있지만, 그것을 해독하여 열람할 수 있는 사람은 개인키를 지닌 단 한 사람만이 존재한다는 점에서 대칭키 알고리즘과 차이를 가진다.

DSA

디지털 서명 알고리즘(Digital Signature Algorithm, DSA)은 디지털 서명을 위한 연방 정보 처리 표준이다. 1991년 8월 미국 국립표준기술연구소(NIST)는 자신들의 디지털 서명 표준(Digital Signature Standard, DSS)에 사용하기 위해 DSA를 제안했으며 1993년 FIPS 186로 채택되었다. 

ED25519

Ed25519는 SHA-512 및 Curve25519를 사용한 EdDSA 서명 체계이다. 또한 Ed25519는 몇 가지 매력적인 기능을 갖춘 공개 키 서명 시스템이다. Ed25519 시그니처는 타원 곡선 시그니처로 여러 수준의 설계 및 구현에서 신중하게 엔지니어링되어 보안을 손상시키지 않으면서 매우 빠른 속도를 달성한다.

- 빠른 단일 서명 확인 (Fast single-signature verification)

- 매우 빠른 배치 검증 (Even faster batch verification)

- 빠른 키 생성(Fast key generation)

- 높은 보안 수준(High security level)

- 완전 방지 세션 키(Foolproof session keys)

- 충돌 탄력성(Collision resilience)

- 비밀 배열 인덱스가 없음(No secret array indices)

- 비밀 지점 조건이 없음(No secret branch conditions)

- 작은 서명(Small signatures)

- 작은 키(Small keys)

위에 보이는 그림이 Ed25519에 대한 알고리즘을 그림으로 표현한 것이며 아래표에서는 많이 사용하는 RSA나 DSA에 비해 ED25519가 얼마나 성능상 우수한지를 보여준다.

* EdDSA

공개 키 암호화에서 Edwards-curve EDDSA (Digital Signature Algorithm)는 트위스트 에드워드 곡선(Twisted Edwards curve)을 기반으로하는 Schnorr 서명의 변형을 사용하는 디지털 서명 체계이다. 보안을 유지하면서 기존 디지털 서명 체계보다 더 빠르도록 설계되었다. 

* Twisted Edwards curve

대수 기하학에서 트위스트 에드워드 곡선(Twisted Edwards curve)은 타원 곡선의 평면 모델로, 2008 년에 Bernstein, Birkner, Joye, Lange 및 Peters가 도입 한 Edwards 곡선의 일반화다. 이 곡선 세트는 수학자 Harold M. Edwards의 이름을 따서 명명되었으며, 타원 곡선은 공개 키 암호화에서 중요하며 트위스트 에드워즈 곡선은 EdDSA라는 전자 서명 체계의 핵심이며 다른 디지털 서명 체계에서 발생하는 보안 문제를 피하면서 고성능을 제공한다.

참조링크

https://jusungpark.tistory.com/34

https://ed25519.cr.yp.to/

https://ko.wikipedia.org/wiki/SHA

https://ko.wikipedia.org/wiki/MD5

https://waytomine.com/sha-256-algorithm-function-bitcoin-network/

https://blog.webernetz.net/ssh-key-fingerprints/

https://www.keycdn.com/support/sha1-vs-sha256

처음 SHA256이나 ED25519는 데이터베이스 보안을 하면서 들었던 용어였다. 그런데, 이번에 이런 보안 용어들을 공부하면서 보니 이것이 데이터베이스 뿐이 아니라, 일반 SSH나 Http 보안에서 인증키를 만들때 사용하는 보안 알고리즘이라는 것을 알았다. 그리고, ED25519와 같은 경우에는 일반 보안 알고리즘과는 다르게 CPU와 같은 하드웨어 인프라 보안 단에서 사용하는 매우 고 난이도의 알고리즘이라는 것도 알았다. 그리고, 이런 보안 알고리즘들은 매우 다양한 보안 분야에서 쉽게 들을 수 있는 용어였다.  처음엔 각각 별개의 기술인 줄 알았지만, 하나씩 하나씩 보다보니 모든 기술들이 서로서로 연결되어 있고, 서로서로 연관되어 있다는 사실을 알았다. SNS의 친구의 친구처럼 말이다. 이로써 그렇게 어렵게만 느껴지던 보안 용어들이 이제는 어떻게 해서 만들어졌고, 지금은 어떤 보안 기술들을 많이 사용하는지는 적어도 내가 지금 쓰고 있는 시스템의 보안 기술들은 어떤것인지는 알 수 있게 되었다. 

Hello, Friends

I attended OpenStack Korea User Group small meetup yesterday. So I shared about how to operate containerized openstack in Korean. I wanted to share it in English for OpenStack Vietnam User Group members.

Nowadays, most OpenStack environment is transferring from packages to containers. So we can use various environments like baremetal, virtual machines and containers. And there are deployment services a lot. Among many depolyment services I usally use TripleO. TripleO meanning is OpenStack on Openstack. This is to use OpenStack for installing OpenStack. Undercloud is for deploying OpenStack. Overcloud is for providing OpenStack service to users(clients or customers).  If Undercloud install OpenStack on Overcloud, controller node's all services are deployed containers. And compute's all agents also are deployed containers.

So I thought about What's the difference between containers and packages? How do I configure OpenStack configuration on OpenStack containers environment? How do I operate it? 

So I wanted to share about these my questions. Because we can modify service configuration through edit service's conf files in the packages environment. But in the containers environment, we can't modify service configurations. After I modify configuration inside container, container's status will be initalized if container restart.

Containers can share specific directory with host system. So we can modify OpenStack service's configurations through shared specific directory between container and host. And we can see OpenStack service's logs through shared specific directory between container and host also. And we can control containers by docker cli commands.

If you have any questions, please send me mail.

보안을 하기 전에는 http를 https로 설정을 하기만 하면 해커들로부터의 침입을 차단하여 안전한 줄로만 알았다. 아마도 대부분의 사람들은 그렇게 생각을 할 수도 있을 것 같다. 그런데, 보안을 하면서 보니 https로 변경했다고 해서 해커들로부터 안전하다라고 볼수는 없다는 것을 알았다. 그리고, 웹에서 보안 기술은 오래되어 관련 자료도 상당히 많이 있고, 이에 대한 용어 설명 그리고, 실제로 적용하려면 어떻게 해야 되는지에 대한 예제를 보여주는 사이트도 상당히 많이 있었다. 

그래서, 이번 블로그에서는 잊어버리기 전에 웹에 대한 보안 용어들을 다시 한번 더 정리해 보는 시간을 가져봤다.

SSL

SSL(Secure Socket Layer) 프로토콜은 처음에 Netscape사에서 웹서버와 브라우저 사이의 보안을 위해 만들어졌다. SSL은 Certificate Authority(CA)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다. 아래는 SSL이 어떻게 작동하는지에 대한 간단한 과정을 설명한 것이다.

1. [웹브라우저] SSL로 암호화된 페이지를 요청하게 된다. (일반적으로 https://가 사용된다)

2. [웹서버] Public Key를 인증서와 함께 전송한다.

3. [웹브라우저] 인증서가 자신이 신용있다고 판단한 CA(일반적으로 trusted root CA라고 불림)로부터 서명된 것인지 확인한다.  또한 날짜가 유효한지, 그리고 인증서가 접속하려는 사이트와 관련되어 있는지 확인후 암호화키를 비롯한 url 및 http 데이터를 암호화해서 전송한다.

4. [웹서버,웹브라우저] 웹브라우저와 웹서버는 Private Key를 사용해서 세션을 복호화하고 암호화된 세션을 통해 통신을 한다.

SSL이 무엇을 말하는지 의미를 한번 살펴보았다. 이전에는 SSL 프로토콜 하나만 존재하는 줄 알았는데 그게 아니였다. 우리가 알고 있는 SSL은 TLS 1.2 혹은 1.3을 의미하는 것이며, 보안에서는 SSL 버전2와 버전3이 존재를 하고 이를 사용하지 말라고 대부분의 보안 가이드에 권장을 하고 있다. 그러면, 왜 사용을 못하게 하는것일까? 분명히 그 이유가 있을 것이다. 그래서, 해당 이유를 찾아보았다. 

SSLv2을 권장하지 않는 이유

SSLv2는 1995년 2월에 출시된 프로토콜로 상당히 노후된 프로토콜이다. 그래서 많은 취약점들이 나타났고 이제는 어떠한 웹 환경에서도 활용이 적합하지 않다. 그 중 하나가 DROWN(Decrypting RSA with Obsolete and Weakened eNcryption)이라는 해커의 공격이다. 

DROWN 해커는 중간자(man-in-the-middle, MITM) 위치에서, 목표 서버에 다수의 SSLv2 연결을 만든다. 이때 해커가 다수의 SSLv2 연결을 이루어낼 경우, 서버를 공격하여 세션 키 값을 알아낼 수 있다. 이 키 값을 이용해, 어떤 통신 내용이든 복호화 할 수 있다.

그래서 다음 2가지 요건 중 1가지라도 충족된다면, 서버는 DROWN 공격에 노출되게 된다.

1. SSLv2 요청을 지원하는 경우

2. 개별 키가 SSLv2 연결을 허용하는 서버에서 사용될 경우 (최신버전 SSL/TLS 프로토콜 포함)

DROWN을 입증한 연구진은 HTTPS 서버에서  SSLv2 연결을 허용할 경우 중간자 공격이 가능해지고, 해커는 SSLv2 연결을 활용하여 서버에 침투를 한다. 그리고, 세션 키를 찾아내어, TLS 트래픽마저 복호화를 할 수 있다. DROWN은 인터넷 보안을 위한 필수 암호화 프로토콜인 SSL 및 TLS에 의존하는 HTTPS 및 기타 서비스에 영향을 미치는 심각한 취약점이다. 이 프로토콜을 사용하면 인터넷을 사용하는 모든 사람이 웹을 탐색하고, 전자 메일을 사용하고, 온라인 쇼핑을하고, 제 3자가 통신을 읽을 수 없는 인스턴트 메시지를 보낼 수 있다.
또한 DROWN은 공격자가 암호, 신용 카드 번호, 영업 비밀 또는 재무 데이터를 포함하여 암호화를 해제하고 민감한 통신을 읽거나 훔칠 수 있도록 한다. 2016 년 3 월 공개 당시, 모든 HTTPS 서버의 33 %가 공격에 취약한 것으로 나타났다. 다행히도이 취약점은 현재 훨씬 덜 널리 퍼져 있으며, 2019 년 현재 SSL Labs는 HTTPS 서버의 1.2 %가 취약하다고 한다.

SSLv3을 권장하지 않는 이유

SSLv3.0은 설계된지 15년 가까이가 되었고 그동안 많은 종류의 취약점이 발견되어 더이상 안전하지않다. 그 중 가장 대표적인 이유가 바로 POODLE(Padding Oracle On Downgraded Legacy Encryption)이다. 

Google의 보안 전문가들(Bodo Moller 외 2명)은 SSL 3.0의 설계상의 취약점과 이를 활용한 공격법 "POODLE (Padding Oracle On Downgraded Legacy Encryption)"에 대한 상세 보고서를 공개('14,10.14)했다. "POODLE"은 CBC모드 블록암호문에 대한 패딩 오라클 공격을 활용한 공격기법으로 TLS 연결 설정과정에서 하위버전인 SSL3.0으로 연결 수립을 유도한 뒤, 패딩 오라클 공격을 통해 암호화된 통신내용을 복호화하는 공격기법이다. "POODLE"에 대한 특별한 대응방안이 존재하지 않아서 SSL v3.0을 사용하지않는 것이 현재로써는 최선책이다.

※ SSL/TLS : 통신 과정에서 보안과 데이터 무결성을 제공하는 보안 프로토콜. 넷스케이프사에서 SSL을 개발 하여 업계표준으로 사용되다가 수정을 거쳐 TLS로 명칭을 변경하고 국제표준으로 채택됨
※ 패딩 오라클 공격 : 알고리즘 자체 취약성이 아니라 컴퓨터 동작 시간, 온도, 소리, 전자적 노이즈, 전력사용량 등 부가적인 현상을 공격 도구로 활용하는 사이드 채널 공격의 일종

TLS

TLS (Transport Layer Security)는 클라이언트와 서버간의 통신을  보호하고 암호화하기 위해 사용되는 암호화 프로토콜이다.  넷스케이프 커뮤니케이션스사가 개발한 SSL(Secure Sockets Layer)에 기반한 기술로, 국제 인터넷 표준화 기구에서 표준으로 인정받은 프로토콜로, 표준에 명시 된 정식 명칭은 TLS지만 SSL이라는 용어로 많이 사용되고 있다.

TLS 1.0은 1999년에 나온 프로토콜이며 TLS 1.1의 경우 2006년 공개 되었다. 물론 공개된지 오래 된 만큼 취약점이 많이 나온 상황이며,  2008년에 공개 된 TLS 1.2 에 비해 보안 알고리즘이 취약하여 Google, MS, Apple등은 좀 더 나은 보안을 위해 지원을 중단했다.

(  TLS는 현재 1.0, 1.1, 1.2, 1.3(최신)으로 총4개의 버전이 있다. )

※ TLS1.0, TLS1.1은 POODLE 및 BEAST와 같은 다양한 공격에 취약!
► POODLE(Padding Oracle On Downgraded Legacy Encryption) 취약점
     : 구식 암호화 기법을 악용할 수 있게 하는 프로토콜 다운그레이드 취약점

► BEAST(Browser Exploit Against SSL/TLS) 취약점
    : 앤드 유저 브라우저에서 HTTPS의 쿠키들을 해독하고 효과적인 타킷의 세션을 하이제킹할 수 있는 취약점

TLS 1.2 and TLS 1.3

TLS 1.0 과 1.1 을 보안해 나온것이 바로 TLS 1.2 버전이다. 최근 대부분의 웹사이트에서는 TLS1.2 버전 이상을 사용하도록 권고하며, 대부분이 TLS 1.2가 설정되어 사용이 되고 있다. 그런데, 이 역시 2006도에 나온 프로토콜이기 때문에 점점 기존 취약점들에 약해지기 시작했다. 그래서, 최근 2017년에 나온 TLS 1.3를 사용하기 시작했고, 많은 브라우저들과 웹서버들이 이를 지원을 하기 시작했다. 따라서, 앞으로 웹서버에서 보안을 적용할 계획을 가지고 있다면 TLS 1.3을 사용해야 할 것이다. 또한, TLS 1.2는 300ms가 걸리는 반면 TLS 1.3은 200ms면 사용이 가능하므로 속도도 그만큼 빨라졌다고 볼 수 있다.

참조 링크

https://www.trendmicro.co.kr/kr/blog/drown-sslv2-vulnerability-rears-ugly-head-puts-one-third-of-https-servers-at-risk/index.html

https://drownattack.com/

https://www.krcert.or.kr/data/trendView.do?bulletin_writing_sequence=22128

https://idchowto.com/?p=46322

https://dokydoky.tistory.com/463

이렇게해서, 웹서비스에서 보안 관련 용어들을 살펴보았다. 물론 그럼에도 보안은 여전히 어려운듯 하다. 그러나, 많은 사람들이 보안 관련 글을 공유하고 실제로 어떻게 적용을 하면 되는지, 적용을 했다면 어떻게 검증하는지에 대한 글들은 검색을 통해서 쉽게 확인할 수 있다. 따라서, 마음만 먹으면 얼마든지 관련 자료들을 검색하고 알아갈 수 있다고 생각한다.

Hello, My blog vistors

How about your days? In my case, I am working about openstack security for my customer site. so I am very busy nowadays. But I have learend a lot of things like OpenStack, Container, Linux, Network and Security through this project.

In this post, I'd like to share about OpenStack Container Architecture and how to install and manage openstack services with container. Actually, Nowadyas I am working about openstack security. so I have thinking about how to set security vulnerable items in openstack container environment. 

I had to anaylsis openstack container environment and architecture. Because I had only installing docker exprience. so I didn't know commands for operating container environment well. But I can do it now. 

Anyway, I discovered that docker and host's directory mount to each mapped directory like below architecture. We can modify configuration of openstack services through host's mapped directory. And we can monitor openstack service logs also through the host's mapped directory. However we can't modified somthing inside docker operating system. If something modify inside docker operating system, docker's configuration will back after docker restart. The mean is that docker environment can't modify.

I was curious why container environment of RHOSP13(Red Hat OpenStack Platform 13) can't modify. I wanted to know how to launch and manage container for openstack services. so I was looking openstack documents and finding various things on the internet. And I noticed that OpenStack containers launch and manage using paunch. If you visit following the site (https://github.com/openstack/paunch), you can see below contents.

paunch

Utility to launch and manage containers using YAML based configuration data

• Free software: Apache license
• Documentation: https://docs.openstack.org/developer/paunch
• Source: https://opendev.org/openstack/paunch
• Bugs: https://bugs.launchpad.net/paunch
• Release Notes: https://docs.openstack.org/releasenotes/paunch

Features

• Single host only, operations are performed via the podman client.
• Zero external state, only labels on running containers are used when determining which containers an operation will perform on.
• Single threaded and blocking, containers which are not configured to detach will halt further configuration until they exit.
• Co-exists with other container configuration tools. Only containers created by paunch will be modified by paunch. Unique container names are assigned if the desired name is taken, and containers are renamed when the desired name becomes available.
• Accessable via the paunch command line utility, or by importing python package paunch.
• Builtin debug command lets you see how individual containers are run, get configuration information for them, and run them any way you need to.

Debugging with Paunch

The paunch debug command allows you to perform specific actions on a given container. This can be used to:

• Run a container with a specific configuration.
• Dump the configuration of a given container in either json or yaml.
• Output the podman command line used to start the container.
• Run a container with any configuration additions you wish such that you can run it with a shell as any user etc.

The configuration options you will likely be interested in here include:

In the first paunch's features, it is [Single host only, operations are performed via the podman client]. I was curious about podman. So I searched about podman on the internet. The description what I found is like below. If you visit following site (https://github.com/containers/libpod), you can see podman more detail.

Podman

Libpod provides a library for applications looking to use the Container Pod concept, popularized by Kubernetes. Libpod also contains the Pod Manager tool (Podman). Podman manages pods, containers, container images, and container volumes.

Overview and scope

At a high level, the scope of libpod and Podman is the following:

• Support multiple image formats including the OCI and Docker image formats.
• Support for multiple means to download images including trust & image verification.
• Container image management (managing image layers, overlay filesystems, etc).
• Full management of container lifecycle.
• Support for pods to manage groups of containers together.
• Resource isolation of containers and pods.
• Support for a Docker-compatible CLI interface through Podman.
• Integration with CRI-O to share containers and backend code.

This project tests all builds against each supported version of Fedora, the latest released version of Red Hat Enterprise Linux, and the latest Ubuntu Long Term Support release. The community has also reported success with other Linux flavors.

After I learned about things that I want, I started to analysis RHOSP13 provisining process. RHOSP13 have undercloud and overcloud. Undercloud is for openstack deployment, Overcloud is for openstack service. In the undercloud node, it have installed various openstack packages for deploying openstack like below process. Ansible has playbooks that deploy openstack container service to overcloud. Ansible will deploy openstack to overcloud node using the playbooks. And It is step 5.

In the step 1, It will be common services tagging. Common services are like haproxy, Memcahed, RabbitMQ, MySql and Redis.

In the step 2, It will be Openstack services logging like below.

In the step 3, It will be OpenStack services DbSync. Ofcourse, these openstack services are all containers.

In the step 4, It will be OpenStack services configuration. 

In the last step 5, It will be Storage service configuration like cinder, cinder backup, conder volume and manila.

Today, I write about OpenStack container. Nowadays, Technical trend is moving to containers. However I think container is not perfect yet.  But It will improve continue. So I am interested about container technology. If I have any posting, I want to write about container architecture more deeply.

See you next time. Bye~~~