기억저장소

[kubernetes] Ingress-nginx --enable-ssl-passthrough 옵션 적용해보기 (with argocd)

빛가닥 — Thu, 21 Dec 2023 17:40:38 +0900

kubernetes 에서 운영을 하다보면 가끔 필요한 기능이 있다. ssl 을 직접 구현하고 있는 백엔드 서비스에 ingress-nginx 로 https 요청을 바이패스만 해 주고 싶은 기능이 그것이다.

예를 들어 아래와 같은 상황에서 필요한 기능이다.

ingress-nginx 은 https 요청에 바이패스만 수행

Ingress 는 https 요청이 들어왔을 때, ssl 처리를 하지 않고 요청을 그대로 백엔드 서비스로 바이패스하는 상황이다.

성능을 일부 희생해도 된다면 ingress-nginx 옵션만 추가하면 바로 구현할 수 있다.

nginx.ingress.kubernetes.io/ssl-passthrough: "true"

다만, 이 옵션은 default 값으로 비활성화 되어 있기 때문에 ingress 옵션을 수정해야 한다.

이 글에선, ssl 을 직접 구현하는 argocd 서비스를 대상으로 Ingress-nginx 의 ssl-passthrough 옵션을 적용해 본다.

환경

nhncloud 환경
kubernetes: v1.27.3
ingress-nginx: v1.8.2
argocd: v2.9.3

Ingress-nginx 설치 및 옵션 적용

Ingress-nginx 로 Ingress controller 로 사용하려고 한다. 설치 관련 링크: https://kubernetes.github.io/ingress-nginx/deploy/

Installation Guide - Ingress-Nginx Controller

Installation Guide There are multiple ways to install the Ingress-Nginx Controller: with Helm, using the project repository chart; with kubectl apply, using YAML manifests; with specific addons (e.g. for minikube or MicroK8s). On most Kubernetes clusters,

kubernetes.github.io

kubectl 로 설치를 한다. 가이드에 따라 아래와 같이 수행한다.

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
serviceaccount/ingress-nginx-admission created
role.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
   (...)

설치되었다.

Ingress-nginx 설정

다만 현재 시점에서는

nginx.ingress.kubernetes.io/ssl-passthrough: "true"

옵션을 바로 적용할 수 없다.

이 때는, ingress-controller 의 옵션을 변경하면 된다. 옵션 목록: https://kubernetes.github.io/ingress-nginx/user-guide/cli-arguments/

Command line arguments - Ingress-Nginx Controller

Command line arguments The following command line arguments are accepted by the Ingress controller executable. They are set in the container spec of the ingress-nginx-controller Deployment manifest Argument Description --annotations-prefix Prefix of the In

kubernetes.github.io

여기서

--enable-ssl-passthrough=true

를 적용하면 된다. 관련 설명: 링크

현재 옵션을 확인해 본다. spec.template.spec.containers 를 확인해 본다.

$ kubectl get deployment/ingress-nginx-controller -n ingress-nginx -o yaml
   (...)
spec:
   (...)
  template:
   (...)
    spec:
      containers:
      - args:
        - /nginx-ingress-controller
        - --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller
        - --election-id=ingress-nginx-leader
        - --controller-class=k8s.io/ingress-nginx
        - --ingress-class=nginx
        - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
        - --validating-webhook=:8443
        - --validating-webhook-certificate=/usr/local/certificates/cert
        - --validating-webhook-key=/usr/local/certificates/key
   (...)

여기에 edit 명령어를 통해 옵션을 적용한다.

$ kubectl edit deployment/ingress-nginx-controller -n ingress-nginx

spec.template.spec.containers 의 args 에 옵션을 추가한다.

확인해본다.

$ kubectl get deployment/ingress-nginx-controller -n ingress-nginx -o yaml
   (...)
spec:
   (...)
  template:
   (...)
    spec:
      containers:
      - args:
        - /nginx-ingress-controller
        - --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller
        - --election-id=ingress-nginx-leader
        - --controller-class=k8s.io/ingress-nginx
        - --ingress-class=nginx
        - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
        - --validating-webhook=:8443
        - --validating-webhook-certificate=/usr/local/certificates/cert
        - --validating-webhook-key=/usr/local/certificates/key
        - --enable-ssl-passthrough=true
   (...)

enable-ssl-passthrough 옵션이 추가되었다.

argocd 설치

argocd 는 gitOps 를 구현하기 위해 사용되는 툴이다. 다만 이 글은 argocd 에 대한 것이 아니라 자세한 설명은 생략한다.

argocd 를 설치하면 기본적으로 자체 ssl 인증서를 통해 ssl 을 지원한다. 그래서 테스트로 좋을 것 같아서 선택하였다.

argocd 및 설치 방법에 대한 것은 공식홈페이지에 자세히 나와있다: https://argo-cd.readthedocs.io/en/stable/getting_started/

공식홈페이지에서 소개하는 방법으로 설치하겠다.

먼저 argocd 를 위한 네임스페이스를 만든다.

$ kubectl create namespace argocd

그리고 최신 stable 버전(현시점 v2.9.3)으로 설치를 한다.

$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
customresourcedefinition.apiextensions.k8s.io/applications.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/applicationsets.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/appprojects.argoproj.io created
serviceaccount/argocd-application-controller created
serviceaccount/argocd-applicationset-controller created
   (...)

설치가 되었다.

이 글에서는 다른 것은 중요하지 않고 서버에 접근하는 것만 확인하려고 하니 연결된 서비스를 확인해 본다.

$ kubectl get service/argocd-server -n argocd -o wide
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE   SELECTOR
argocd-server   ClusterIP   10.254.56.106   <none>        80/TCP,443/TCP   33m   app.kubernetes.io/name=argocd-server

해당 서비스를 통해 argocd 서버에 접근 할 수 있다. 설치 시 ClusterIp 타입으로 설정되어 있다. 이를 LoadBalancer 나 NodePort 로 변환하면 외부에서 접근이 가능한데, 이 글에서는 Ingress 로 접근할 것이기 때문에 여기서는 그냥 ClusterIp 타입으로 둔다.

Ingress 설정

argocd-server 서비스로 연결할 Ingress 를 만들어 본다. 이 때, ssl-passthrough 옵션을 준다.

# argocd-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-server-ingress
  namespace: argocd
  annotations:
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
  ingressClassName: nginx
  rules:
    - host: argocd.crudewebtools.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: argocd-server
                port:
                  name: https

namespace: argocd-server 가 argocd 네임스페이스에 존재하기 때문에 통일하였다.
nginx.ingress.kubernetes.io/force-ssl-redirect: http 요청이 온다면 https 로 리다이렉트 하라는 응답을 전달한다. (308 Permanent Redirect)
nginx.ingress.kubernetes.io/ssl-passthrough: 위에서 설명했듯이, https 요청을 그대로 백엔드 서비스에 전달한다.
host 는 필자가 테스트를 위해 임시로 설정한 값이다.

Ingress 적용

$ kubectl apply -f argocd-ingress.yaml

확인

$ kubectl get ingress
NAME                    CLASS   HOSTS                      ADDRESS          PORTS   AGE
argocd-server-ingress   nginx   argocd.crudewebtools.com   10.10.10.10      80      38m

ADDRESS 는 임시 값이다.

이제 접근해 본다. 브라우저로 접근이 잘 된다.

브라우저 접근. 리다이렉트 되었음.

curl 로 접근

잘 된다.

참고 사항

한편 문서에 따르면 ssl-passthrough 옵션 적용시 다른 어노테이션 옵션을 무시한다고 하며, 성능상 단점이 있다고 하니 유의한다.

https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#ssl-passthrough

https://kubernetes.github.io/ingress-nginx/user-guide/tls/#ssl-passthrough

Spring Boot "You are asking Spring Security to ignore Ant [pattern]" 경고 해결(WebSecurity ignoring -> HttpSecurity permitAll)

빛가닥 — Wed, 1 Feb 2023 16:21:07 +0900

Spring Security 의 구조에 대해서 알면 도움이 된다.

참고:

- Spring Security 공식 문서: https://docs.spring.io/spring-security/reference/servlet/architecture.html

- HttpSecurity, WebSecurity 를 통한 SecurityFilterChain 설정: https://bitgadak.tistory.com/10

Spring 버전

Spring Security 의 경우 Deprecated 된 부분이 있기 때문에 나중에 변경될 수 있다. 이번에 사용한 버전은 아래와 같다.

Spring Boot: 2.7.8
Spring Security: 5.7.6

경고가 발생하는 경우

Spring Boot 에서는 SecurityFilterChain, WebSecurityCustomizer 를 Bean으로 설정함으로 Security 설정을 할 수 있다. (이전에는 WebSecurityConfigurerAdapter 를 상속하여 설정하는 방식이었는데, deprecated 되었다.) 예를 들어 아래와 같이 설정할 수 있다.

@Configuration
public class SecurityConfig {

  @Bean
  public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests()
            .anyRequest().authenticated();  // 모든 요청에 대해 권한 처리
    http.formLogin();  // 로그인페이지
    return http.build();
  }

  @Bean
  public WebSecurityCustomizer webSecurityCustomizer() {
    return (web) -> web.ignoring().antMatchers("/static/**");  // "/static/**" 으로 들어오는 요청 무시
  }
}

이 때, WebSecurityCustomizer 에서 WebSecurity의 ignoring 을 사용하면 경고 메시지가 뜬다.

You are asking Spring Security to ignore Ant [pattern='/static/**']. This is not recommended -- please use permitAll via HttpSecurity#authorizeHttpRequests instead.

메시지가 발생하는 이유

찾아보면 메시지가 출력되는 이유를 설명하고 있는 곳을 발견할 수 있다.

https://github.com/spring-projects/spring-security/issues/10938

WARN when ignoring antMatchers - please use permitAll · Issue #10938 · spring-projects/spring-security

When I use web.ignoring().antMatchers() I'd like to see a DEBUG message instead of a WARNING for each ignored pattern. I'm confused by the message saying it's not recommended and I shou...

github.com

이곳에 따르면 WebSecurity.ignoring() 을 사용할 경우 Spring Security의 어떠한 보호도 받을 수 없기 때문에 permitAll 를 사용하라고 권장하고 있다. 또한 ignoring() 을 사용할 때만 얻을 수 있는 성능상의 이점도 없다고 하며 성능을 고려한 설정 방법 또한 제시하고 있다.

수정

위 사이트를 참고하여 처음의 설정파일을 바꾸면 아래와 같다.

@Configuration
public class SecurityConfig {

  @Bean
  @Order(2)
  public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests()
            .anyRequest().authenticated();  // 모든 요청에 대해 권한 처리
    http.formLogin();  // 로그인페이지
    return http.build();
  }

  @Bean
  @Order(1)
  public SecurityFilterChain exceptionSecurityFilterChain(HttpSecurity http) throws Exception {
    http
            .requestMatchers((matchers) -> matchers.antMatchers("/static/**"))
            .authorizeHttpRequests((authorize) -> authorize.anyRequest().permitAll())
            .requestCache().disable()
            .securityContext().disable()
            .sessionManagement().disable();

    return http.build();
  }
}

exceptionSecurityFilterChain 메서드를 통해 새로 생성한 SecurityFilterChain은 기존에 있는 SecurityFilterChain 보다 먼저 경로 체크를 해야 하기 때문에 순서를 정할 필요가 있다. @Order 어노테이션을 통해 /static/** 경로로 오는 요청에 대해 먼저 체크하도록 한다.

사이트에서 언급한 대로 requestCache, securityContext, sessionManagement 에 대한 필터를 제거하도록 한다.

검사

새로 만든 SecurityFilterChain 의 경우 어떤 필터가 있는지 기존 필터체인과 비교해 본다.

디버거를 이용하여 확인해 보면 기존의 필터체인은 15개의 필터를 가지고 있음을 알 수 있다.

filters = {ArrayList@7327}  size = 15
 0 = {DisableEncodeUrlFilter@7339} 
 1 = {WebAsyncManagerIntegrationFilter@7340} 
 2 = {SecurityContextPersistenceFilter@7341} 
 3 = {HeaderWriterFilter@7342} 
 4 = {CsrfFilter@7343} 
 5 = {LogoutFilter@7344} 
 6 = {UsernamePasswordAuthenticationFilter@7345} 
 7 = {DefaultLoginPageGeneratingFilter@7346} 
 8 = {DefaultLogoutPageGeneratingFilter@7347} 
 9 = {RequestCacheAwareFilter@7348} 
 10 = {SecurityContextHolderAwareRequestFilter@7349} 
 11 = {AnonymousAuthenticationFilter@7350} 
 12 = {SessionManagementFilter@7351} 
 13 = {ExceptionTranslationFilter@7352} 
 14 = {AuthorizationFilter@7353}

새로 생성한 필터체인의 경우는 8개의 필터를 가지고 있다.

filters = {ArrayList@7324}  size = 8
 0 = {WebAsyncManagerIntegrationFilter@7330} 
 1 = {HeaderWriterFilter@7331} 
 2 = {CsrfFilter@7332} 
 3 = {LogoutFilter@7333} 
 4 = {SecurityContextHolderAwareRequestFilter@7334} 
 5 = {AnonymousAuthenticationFilter@7335} 
 6 = {ExceptionTranslationFilter@7336} 
 7 = {AuthorizationFilter@7337}

성능에 영향을 줄 수 있는 세션, 캐시, 컨텍스트와 관련된 필터가 사라진 것을 확인할 수 있다.

참고) authorizeRequests 가 아닌 authorizeHttpRequests 를 사용하였기 때문에 맨 마지막에 FilterSecurityInterceptor가 아닌 AuthrizationFilter가 있음을 알 수 있다.

Spring Boot 에서 @Component로 추가한 filter가 WebSecurity의 ignoring에 의해 무시되지 않는 이유

빛가닥 — Tue, 31 Jan 2023 16:16:39 +0900

Spring Boot 는 WAS 를 내장하고 있어서 WAS 에서 사용하는 Filter 를 Bean 으로 등록하여 쉽게 사용 가능하다. 새 필터를 등록하고 싶다면 Filter 인터페이스를 상속하고 @Component 어노테이션만 붙이면 된다. Spring Boot 가 알아서 필터 체인에 추가시켜 준다.

그런데 Spring Security 가 필터를 처리하는 방식을 간과하면 실수할 수 있는 부분이 있다. 예를 들어 위와 같은 방법으로 필터를 추가하고 나서 WebSecurityConfigurerAdapter 에서 WebSecurity를 통해 특정 경로에 대해 ignoring 설정을 한 경우가 있다. 이 때, ignoring 설정한 경로로 접근하면 등록한 필터를 지나지 않을 것이라 생각하기 쉽지만 그렇지 않다. ignoring된 경로로 접근하더라도 필터를 지나는 것을 볼 수 있다.

이 글에서는 이러한 현상이 발생하는 경우와 그 이유를 확인해 보았다.

(FilterRegistrationBean 을 이용하여 추가하거나 @WebFilter 를 이용하여 추가한 필터에도 비슷한 현상이 있다.)

Spring 버전

Spring Security 의 경우 Deprecated 된 부분이 있기 때문에 나중에 변경될 수 있다. 이번에 사용한 버전은 아래와 같다.

Spring Boot: 2.7.8
Spring Security: 5.7.6

1. Spring Security 구조

참고: https://docs.spring.io/spring-security/reference/servlet/architecture.html

Architecture :: Spring Security

Spring Security’s Servlet support is based on Servlet Filters, so it is helpful to look at the role of Filters generally first. The following image shows the typical layering of the handlers for a single HTTP request. The client sends a request to the ap

docs.spring.io

Spring Security 의 구조를 먼저 이해할 필요가 있다. Spring Boot 에서 Spring Security 는 두개의 필터 체인을 생성한다. FilterChain(ApplicationFilterChain)과 SecurityFilterChain 이다.

원본에 화살표 추가. 원본출처: https://docs.spring.io/spring-security/reference/servlet/architecture.html

왼쪽에 FilterChain 은 기존의 WAS 의 필터체인(ApplicationFilterChain)이다. 오른쪽의 SecurityFilterChain 은 Spring Security 에서 사용하는 필터체인이고 실제 인증 절차가 진행된다.

거칠게 요약을 하면, SecurityFilterChain 이라는 기존 필터체인과 분리된 필터체인이 존재하는데, HTTP 요청을 가져와야 하기 때문에 특별한 필터(DelegatinFilterProxy)를 기존 WAS의 FilterChain 에 추가하여 SecurityFilterChain 으로 연결시켜 주는 역할을 하도록 한 것이다.

필터가 요청을 받는 순서는 화살표와 같다. 요청은 ApplicationFilterChain의 순서대로 전달되다가 DelegatinFilterProxy 에서 SecurityFilterChain 로 전달되어 그 내부 필터들을 순서대로 지난다. 그리고 다시 ApplicationFilterChain의 나머지 필터들로 전달된다.

SecurityFilterChain 를 통해 WAS 의 필터체인에서 분리되어 좀 더 Spring 스러운 환경에서 복잡한 필터링 조건을 추가하거나 세세한 작업을 할 수 있게 되어있다.

한편, SecurityFilterChain 은 여러 개 존재할 수 있다.

원본에 화살표 추가. 원본출처: https://docs.spring.io/spring-security/reference/servlet/architecture.html

또한, 다른 경로에 따라 다른 SecurityFilterChain 을 지나도록 할 수 있다. 예를 들어, 위의 그림처럼 /api/** 경로에 대한 SecurityFilterChain과 나머지 경로(/**) 에 대한 SecurityFilterChain을 다르게 설정했다면, 다른 경로에 대한 요청이 서로 다른 필터들을 통과하게 된다.

2. @Component 로 Filter 추가하기

Spring Boot 에서 Filter를 추가할 때, 두 필터체인 중 어느 필터체인에 추가되는지 알면 도움이 된다.

@Component
public class MyCustomFilter implement Filter {
   ...
}

위와 같이 @Component 어노테이션과 Filter 인터페이스를 이용하면 필터체인에 추가되는데, 이 경우 WAS의 ApplicationFilterChain에 추가된다.

원본에 가공. 원본출처: https://docs.spring.io/spring-security/reference/servlet/architecture.html

참고1) 아래와 같이 FilterRegistrationBean 을 통해 추가하는 경우도 WAS의 ApplicationFilterChain에 추가된다.

  @Bean
  public FilterRegistrationBean<MyCustomFilter> filterRegistrationBean() {
    FilterRegistrationBean<MyCustomFilter> registrationBean = new FilterRegistrationBean<>();
    registrationBean.setFilter(new MyCustomFilter());
      ...
    return registrationBean;
  }

참고2) @ServletComponentScan 어노테이션과 @WebFilter 어노테이션을 통해 추가하는 경우도 WAS의 ApplicationFilterChain에 추가된다.

3. HttpSecurity, WebSecurity 설정과 SecurityFilterChain

Spring security 에 대한 설정을 하는 경우 보통 WebSecurityConfigurerAdapter 를 상속받아 HttpSecurity, WebSecurity 를 방법을 사용한다.

(Spring Security 5.7.6 기준으로 WebSecurityConfigurerAdapter의 경우 deprecated 처리되었다. 이제 SecurityFilterChain와 WebSecurityCustomizer를 이용하여 설정을 하면 되는데, 필터 구조에 대한 부분은 동일하다.)

예를 들어 아래와 같이 WebSecurity 를 이용하여 "/api/**" 경로에 대한 ignoring 설정을 할 수 있다.

@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {

  @Override
  protected void configure(HttpSecurity httpSecurity) throws Exception {
    httpSecurity.authorizeRequests()
      ...
  }

  @Override
  public void configure(WebSecurity webSecurity) {
    webSecurity
        .ignoring()
        .antMatchers("/api/**");
  }
}

이 경우 생성되는 구조를 그림으로 표시하면 아래와 같다. WebSecurity.ignoring() 은 필터가 없는 SecurityFilterChain 을 만들게 되고, "/api/**" 경로에 대한 요청을 이쪽 SecurityFilterChain으로 전달한다.

원본에 가공. 원본출처: https://docs.spring.io/spring-security/reference/servlet/architecture.html

HttpSecurity에 대한 설정도 SecurityFilterChain을 만들고 나머지 요청을 받게 될 것이다. 자세한 설명은 생략한다.

4. 원인

이제 MyCustomFilter가 왜 ignoring 설정에 영향을 받지 않는지 알 수 있다. @Component로 등록한 MyCustomFilter는 WAS의 ApplicationFilterChain 에 등록되어 있기 때문에 요청이 어느 SecurityFilterChain을 타든지와 무관하게 지나게 된다.

아래는 /api/** 경로에 대한 요청이라도 MyCustomFilter를 포함한 ApplicationFilterChain 의 모든 필터를 지나는 것을 보여준다.

1. MyCustomFilter를 ApplicationFilterChain에 추가

5. 해결 방법

MyCustomFilter가 WebSecurity.ignoring에 영향을 받게 하기 위해서는 여러 방법이 있겠지만, 가장 간단하다고 생각하는 생각하는 것은 MyCustomFilter 를 ApplicationFilterChain 이 아니라 아래와 같이 HttpSecurity가 생성하는 SecurityFilterChain에 넣는것이다.

2. MyCustomFilter를 SecurityFilterChain에 추가

이 경우 /api/** 경로의 요청이 MyCustomFilter를 지나지 않게 된다.

MyCustomFilter를 SecurityFilterChain 에 넣으려면 HttpSecurity를 설정하는 곳에서 필터를 추가하면 된다. 추가하고자 하는 필터가 Spring Security 에서 제공하는 필터거나 이를 상속했다면, http.addFilter(new 필터()) 로 추가할 수 있다. 그렇지 않다면 addFilterAfter(new 필터(), 기존필터.class) 형식이나 addFilterBefore(new 필터(), 기존필터.class) 형식으로 추가할 수 있다.

  @Override
  protected void configure(HttpSecurity http) throws Exception {
       ...
    http.addFilterBefore(new MyCustomFilter(), DisableEncodeUrlFilter.class);
       ...
}

기존 필터들의 순서는 https://docs.spring.io/spring-security/reference/servlet/configuration/xml-namespace.html#ns-custom-filters 에서 확인할 수 있다.

spring security Pre-Authentication 구현 (AbstractPreAutehnticatedProcessingFilter)

빛가닥 — Tue, 15 Mar 2022 16:57:43 +0900

spring security 의 구조를 어느정도 알고 있다고 가정하고 진행한다.

최종 코드는 여기서 확인할 수 있다: https://github.com/bitgadak/tistory-spring-security-preauth-sample

sprint security 필터에는 서비스에서 요구하는 인증 스펙에 따라 다양한 필터를 사용할 수 있다. 인증에 대한 여러가지 방식이 있겠지만 그 중 하나는 인증이 spring 외부에서 진행되는 pre-authentication 방식이다. 예를 들어 외부에 인증 모듈이 있고, spring 은 인증 모듈을 통과하여 인증된 사용자 ID 와 권한만 받아서 처리 하는 것이다. spring 에서는 이런 형태의 시나리오에 대한 사용할 수 있는 필터 AbstractPreAuthenticatedProcessingFilter 가 존재한다.

시스템의 다른 모듈에 api 를 제공하거나 이미 인증된 사용자에 대해 api 를 제공하는 spring 모듈을 만들어야 할 경우가 생겨 구축한 것을 기록해 보려고 한다.

이러한 api 서버를 도식화하면 아래와 같다.

목표

요청의 HTTP 헤더 값에 따라 권한을 판단할 것이다. 크게 두 가지 종류가 있다. 인증모듈을 통과한 사용자 요청과 시스템 내 다른 모듈에서 부터의 시스템 요청이 있다. 아래와 같이 헤더의 값에 따라서 구분하고 권한을 지정할 것이다.

헤더 값에 따라 spring security 에서 제공하는 Authentication 에 사용자 정보와 권한을 넘긴다. 이것은 PreAuthorize 어노테이션의 hasRole() 를 통해 컨트롤러 별로 접근 권한을 구분할 것이다.

예를 들어 일반 사용자는 @PreAuthorize("hasRole('USER')") 가 붙은 메소드는 호출 가능하지만, @PreAuthorize("hasRole('ADMIN')") 붙은 메소드는 호출 불가능하다.

사용자 요청을 위한 필터와 시스템 요청에 대한 필터 이렇게 두 필터를 AbstractPreAuthenticatedProcessingFilter 를 상속하여 구현하도록 한다. 각각 SystemAuthenticationFilter, UserAuthenticationFilter 이렇게 지정하도록 한다.

1. gradle 을 통한 spring 프로젝트 시작

gradle 로 프로젝트를 구축한다. spring boot plugin 을 통해 build.gradle 를 작성한다. 현시점(2020-03-15)에서 최신 버전을 사용한다.

plugins {
    id 'org.springframework.boot' version '2.6.4'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
}

group 'org.example'
version '1.0-SNAPSHOT'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-security'
    implementation 'org.springframework.boot:spring-boot-starter-web'
}

test {
    useJUnitPlatform()
}

spring-boot-starter-security, spring-boot-starter-web 를 추가한다. 둘 다 2.6.4 버전이다.

2. 프로젝트 구성

아래와 같이 구성한다.

org.example.tistorysecuritypreauthsample
+- config
|  +- auth
|  |  +- SystemAuthenticationFilter.java   // System 요청 filter
|  |  +- SystemAuthenticationProvider.java // SystemAuthenticationFilter 의 Provider
|  |  +- UserAuthenticationFilter.java     // User 요청 filter
|  |  +- UserAuthenticationProvider.java   // UserAuthenticationFilter 의 Provider
|  +- SecurityConfig.java                  // spring security config
+- controller
|  +- SampleController.java                // 테스트 용 controller
+- Application.java

Application.java 에는 main 메소드가 있다.

package org.example.tistorysecuritypreauthsample;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class Application {

  public static void main(String[] args) {
    SpringApplication.run(Application.class);
  }
}

3. 설정

3-1. SecurityConfig.java

먼저 spring security 를 사용하도록 한다. 이를 위해 SecurityConfig.java 를 작성한다.

package org.example.tistorysecuritypreauthsample.config;

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.method.configuration.EnableGlobalMethodSecurity;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

@Configuration
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class SecurityConfig extends WebSecurityConfigurerAdapter {

  @Override
  protected void configure(HttpSecurity http) throws Exception {
    http.csrf().disable();
  }
}

WebSecurityConfigurerAdapter 를 상속하여 구현한다.

PreAuthorize 를 사용하기 위해 @EnableGlobalMethodSecurity(prePostEnabled = true) 를 추가한다.
api 서버로 사용할 것이기 때문에 csrf 를 비활성화한다.

3-2. SystemAuthenticationFilter.java

시스템 요청을 위한 필터 SystemAuthenticationFilter.java 를 작성한다.

package org.example.tistorysecuritypreauthsample.config.auth;

import javax.servlet.http.HttpServletRequest;
import org.springframework.core.annotation.Order;
import org.springframework.security.authentication.ProviderManager;
import org.springframework.security.web.authentication.preauth.AbstractPreAuthenticatedProcessingFilter;
import org.springframework.stereotype.Component;

@Order(1)
@Component
public class SystemAuthenticationFilter extends AbstractPreAuthenticatedProcessingFilter {

  public static final String SYSTEM_AUTH_HEADER = "SYSTEM-AUTH-HEADER";

  public SystemAuthenticationFilter(SystemAuthenticationProvider systemAuthenticationProvider) {
    super.setCheckForPrincipalChanges(true);
    super.setAuthenticationManager(new ProviderManager(systemAuthenticationProvider));
  }

  @Override
  protected Object getPreAuthenticatedPrincipal(HttpServletRequest request) {
    return request.getHeader(SYSTEM_AUTH_HEADER);
  }

  @Override
  protected Object getPreAuthenticatedCredentials(HttpServletRequest request) {
    return "";
  }
}

AbstractPreAuthenticatedProcessingFilter 를 상속하여 필터를 만든다. HttpServletRequest 에서 헤더 정보를 추출한다.

@Order(1): 이 필터가 가장 먼저 나와야 하기 때문에 값을 주어 순서를 고정한다.
Authentication 을 전달할 Provider 를 주입해준다. 이 Provider 는 3-3 에서 설명한다.
setCheckForPrincipalChanges(true): true 로 해주어야 이 필터가 사용된다.
- boot 에서 자동으로 추가하는 filter 를 타고 default Authentication 이 전달되는데, 여기서는 그것을 사용하지 않고, 서비스에 필요한 Authentication 로 갱신해야 하기 때문에 true 로 만든다.
getPreAuthenticatedPrincipal: 여기서 헤더에 있는 값을 추출해 전달한다. SYSTEM-AUTH-HEADER 헤더가 있으면 그 값을, 없으면 null 을 전달한다.
getPreAuthenticatedCredentials: 이 예시에서는 credential 을 사용하지 않는다.

3-3. SystemAuthenticationProvider.java

Authentication 을 시큐리티 컨텍스트로 전달할 Provider 이다. 위의 SystemAuthenticationFilter 에서 이 Provider 를 사용한다.

package org.example.tistorysecuritypreauthsample.config.auth;

import java.util.Collections;
import java.util.List;
import java.util.Map;
import org.springframework.security.authentication.AuthenticationProvider;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.AuthenticationException;
import org.springframework.security.core.authority.SimpleGrantedAuthority;
import org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationToken;
import org.springframework.stereotype.Component;

@Component
public class SystemAuthenticationProvider implements AuthenticationProvider {

  private static final String SECRET_KEY = "password";

  @Override
  public Authentication authenticate(Authentication authentication) throws AuthenticationException {
    String secretKey = (String) authentication.getPrincipal();

    if (secretKey == null || !secretKey.equals(SECRET_KEY)) {
      return null;
    }

    Map<String, Object> userInfo = Map.of("id", "system");
    List<SimpleGrantedAuthority> roles = Collections.singletonList(
        new SimpleGrantedAuthority("ROLE_SYSTEM"));
    return new PreAuthenticatedAuthenticationToken(userInfo, null, roles);
  }

  @Override
  public boolean supports(Class<?> authentication) {
    return PreAuthenticatedAuthenticationToken.class.isAssignableFrom(authentication);
  }
}

authenticate:
- AbstractPreAuthenticatedProcessingFilter 의 getPreAuthenticatedPrincipal() 메소드를 통해 전달되는 값을 여기서 getPrincipal() 를 통해 받는다.
- 이 값을 미리 정해진 값 (위에서는 "password") 과 동일한지 판단한다.
- 사용자 정보를 map 으로 만든다. {id=system}
- 사용자 권한(role) 을 List<SimpleGrantedAuthority> 로 만든다. [ROLE_SYSTEM]
- PreAuthenticatedAuthenticationToken 으로 만들어 전달한다.
supports:
- AbstractPreAuthenticatedProcessingFilter 사용하는 경우, PreAuthenticatedAuthenticationToken 을 사용하고 있기 때문에, Provider 에서도 이것을 허용하도록 한다.

3-4. UserAuthenticationFilter.java

인증된 사용자를 위한 필터 UserAuthenticationFilter.java 를 작성한다.

package org.example.tistorysecuritypreauthsample.config.auth;

import java.util.Collections;
import java.util.List;
import java.util.Map;
import javax.servlet.http.HttpServletRequest;
import org.springframework.core.annotation.Order;
import org.springframework.security.authentication.ProviderManager;
import org.springframework.security.core.Authentication;
import org.springframework.security.web.authentication.preauth.AbstractPreAuthenticatedProcessingFilter;
import org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationToken;
import org.springframework.stereotype.Component;
import org.springframework.util.ObjectUtils;

@Order(2)
@Component
public class UserAuthenticationFilter extends AbstractPreAuthenticatedProcessingFilter {

  public static final String USER_ID_HEADER = "USER-ID-HEADER";
  public static final String USER_ROLES_HEADER = "USER-ROLES-HEADER";

  public UserAuthenticationFilter(UserAuthenticationProvider userAuthenticationProvider) {
    super.setCheckForPrincipalChanges(true);
    super.setAuthenticationManager(new ProviderManager(userAuthenticationProvider));
  }

  @Override
  protected Object getPreAuthenticatedPrincipal(HttpServletRequest request) {
    String userId = request.getHeader(USER_ID_HEADER);
    List<String> roles = Collections.list(request.getHeaders(USER_ROLES_HEADER));

    if (ObjectUtils.isEmpty(userId) || ObjectUtils.isEmpty(roles)) {
      return null;
    }

    return Map.of(
        "userId", userId,
        "roles", roles);
  }

  @Override
  protected Object getPreAuthenticatedCredentials(HttpServletRequest request) {
    return "";
  }

  @Override
  protected boolean principalChanged(HttpServletRequest request,
      Authentication currentAuthentication) {

    if (currentAuthentication instanceof PreAuthenticatedAuthenticationToken) {
      return false;
    }

    return super.principalChanged(request, currentAuthentication);
  }
}

AbstractPreAuthenticatedProcessingFilter 를 상속하여 필터를 만든다. HttpServletRequest 에서 헤더 정보를 추출한다.

@Order(2): 이 필터가 두번째로 나와야 하기 때문에 값을 주어 순서를 고정한다.
Authentication 을 전달할 Provider 를 주입해준다. 이 Provider 는 3-5 에서 설명한다.
setCheckForPrincipalChanges(true): true 로 해주어야 이 필터가 사용된다.
- boot 에서 자동으로 추가하는 filter 를 타고 default Authentication 이 전달되는데, 여기서는 그것을 사용하지 않고, 서비스에 필요한 Authentication 로 갱신해야 하기 때문에 true 로 만든다.
getPreAuthenticatedPrincipal: 여기서 헤더에 있는 사용자 정보값을 추출한다.
- USER-ID-HEADER 헤더에서 사용자 ID 를, USER-ROLES-HEADER 에서 사용자 권한을 추출한다. (권한은 여러개가 가능하다.) 이 값을 Map 타입으로 반환하여 Provider 에서 받을 수 있도록 한다.
getPreAuthenticatedCredentials: 이 예시에서는 credential 을 사용하지 않는다.
principalChanged: 이 필터 전에 SystemAuthenticationFilter 를 먼저 통과하는데, 앞 필터에서 적절한 system Authentication 이 할당되었다면 무시하고 통과시켜야 한다. 그래서 먼저 만들어진 PreAuthenticatedAuthenticationToken 이 있는지 확인하고 있다면 false 를 반환하여 처리하지 않도록 한다.

3-5. UserAuthenticationProvider.java

Authentication 을 시큐리티 컨텍스트로 전달할 Provider 이다. 위의 UserAuthenticationFilter 에서 이 Provider 를 사용한다.

package org.example.tistorysecuritypreauthsample.config.auth;

import java.util.List;
import java.util.Map;
import java.util.stream.Collectors;
import org.springframework.security.authentication.AuthenticationProvider;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.AuthenticationException;
import org.springframework.security.core.authority.SimpleGrantedAuthority;
import org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationToken;
import org.springframework.stereotype.Component;

@Component
public class UserAuthenticationProvider implements AuthenticationProvider {

  @Override
  public Authentication authenticate(Authentication authentication) throws AuthenticationException {
    Map<String, Object> principal = (Map<String, Object>) authentication.getPrincipal();

    String userId = (String) principal.get("userId");
    List<String> roles = (List<String>) principal.get("roles");

    Map<String, Object> userInfo = Map.of("id", userId);
    List<SimpleGrantedAuthority> authorities = roles.stream()
        .map(role -> new SimpleGrantedAuthority("ROLE_" + role))
        .collect(Collectors.toList());
    return new PreAuthenticatedAuthenticationToken(userInfo, null, authorities);
  }

  @Override
  public boolean supports(Class<?> authentication) {
    return PreAuthenticatedAuthenticationToken.class.isAssignableFrom(authentication);
  }
}

authenticate:
- AbstractPreAuthenticatedProcessingFilter 의 getPreAuthenticatedPrincipal() 메소드를 통해 전달되는 값을 여기서 authentication.getPrincipal() 를 통해 받는다. (필터에서 Map 타입으로 전달되어서 Map 으로 받는다.)
- 사용자 ID 를 userId 로 받고, 권한을 roles 를 받는다.
- 사용자 정보를 map 으로 만든다. {id=userId}
- 사용자 권한(role) 을 List<SimpleGrantedAuthority> 로 만든다. [ROLE_*] (ex: ROLE_USER, ROLE_ADMIN ...)
- PreAuthenticatedAuthenticationToken 으로 만들어 전달한다.
supports:
- AbstractPreAuthenticatedProcessingFilter 사용하는 경우, PreAuthenticatedAuthenticationToken 을 사용하고 있기 때문에, Provider 에서도 이것을 허용하도록 한다.

4. Controller

테스트를 할 controller 를 작성한다.

package org.example.tistorysecuritypreauthsample.controller;

import java.util.Collection;
import java.util.Map;
import org.springframework.security.access.prepost.PreAuthorize;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.GrantedAuthority;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class SampleController {

  @GetMapping("/sample")
  public String sample(Authentication authentication) {
    print(authentication);
    return "SUCCESS";
  }

  @PreAuthorize("hasRole('USER')")
  @GetMapping("/sample-user")
  public String sampleUser(Authentication authentication) {
    print(authentication);
    return "SUCCESS";
  }

  @PreAuthorize("hasRole('ADMIN')")
  @GetMapping("/sample-admin")
  public String sampleAdmin(Authentication authentication) {
    print(authentication);
    return "SUCCESS";
  }

  @PreAuthorize("hasRole('SYSTEM')")
  @GetMapping("sample-system")
  public String sampleSystem(Authentication authentication) {
    print(authentication);
    return "SUCCESS";
  }

  private void print(Authentication authentication) {
    if (authentication != null) {
      Map<?, ?> info = (Map<?, ?>) authentication.getPrincipal(); // @AuthenticationPrincipal
      Collection<? extends GrantedAuthority> authorities = authentication.getAuthorities();
      System.out.println("ID=" + info.get("id") + ", ROLE=" + authorities.toString());
    } else {
      System.out.println("unauthenticated");
    }
  }
}

시큐리티 컨텍스트에서 Authentication 을 가져오는 것은 여러 방법이 있지만 여기서는 메소드의 파라미터로 받아오는 방식을 택했다.

Provider 에서 전달한 Principal 은 @AuthenticationPrincipal 어노테이션을 통해서도 받아올 수 있지만 여기서는 authentication 에서 가져온다. Provider 에서 Map 타입으로 전달되었기 때문에 Map 타입으로 받아온다.

5. 테스트

16 개의 경우의 수 가 있는데, 여기서는 일부만 테스트 해 본다. 전체 경우의 수에 대한 테스트는 https://github.com/bitgadak/tistory-spring-security-preauth-sample/blob/master/src/test/java/org/example/tistorysecuritypreauthsample/ApplicationTest.java 에서 확인 가능하다.

5-1. 권한 없는 요청 + 제한없는 메소드: 호출 가능

$ curl http://localhost:8080/sample --silent
SUCCESS

JAVA 로그:
unauthenticated

5-2. 권한 없는 요청 + USER 권한 메소드: 호출 불가

$ curl http://localhost:8080/sample-user --silent
{"timestamp":"2022-03-15T07:31:12.306+00:00","status":403,"error":"Forbidden","path":"/sample-user"}

JAVA 로그:
unauthenticated

5-3. USER 권한 요청 + USER 권한 메소드: 호출 가능

$ curl http://localhost:8080/sample-user -H 'USER-ID-HEADER: tester' -H 'USER-ROLES-HEADER: USER' --silent
SUCCESS

JAVA 로그:
ID=tester, ROLE=[ROLE_USER]

5-4. USER 권한 요청 + ADMIN 권한 메소드: 호출 불가

$ curl http://localhost:8080/sample-admin -H 'USER-ID-HEADER: tester' -H 'USER-ROLES-HEADER: USER' --silent
{"timestamp":"2022-03-15T07:34:30.166+00:00","status":403,"error":"Forbidden","path":"/sample-admin"}

JAVA 로그:

5-5. ADMIN 권한 요청 + USER 권한 메소드: 호출 가능

$ curl http://localhost:8080/sample-user -H 'USER-ID-HEADER: admin' -H 'USER-ROLES-HEADER: USER' -H 'USER-ROLES-HEADER: ADMIN' --silent
SUCCESS

JAVA 로그:
ID=admin, ROLE=[ROLE_USER, ROLE_ADMIN]

5-6. ADMIN 권한 요청 + ADMIN 권한 메소드: 호출 가능

$ curl http://localhost:8080/sample-admin -H 'USER-ID-HEADER: admin' -H 'USER-ROLES-HEADER: USER' -H 'USER-ROLES-HEADER: ADMIN' --silent
SUCCESS

JAVA 로그:
ID=admin, ROLE=[ROLE_USER, ROLE_ADMIN]

5-7. SYSTEM 권한 요청 + SYSTEM 권한 메소드: 호출 가능

$ curl http://localhost:8080/sample-system -H 'SYSTEM-AUTH-HEADER: password' --silent
SUCCESS

JAVA 로그:
ID=system, ROLE=[ROLE_SYSTEM]

잘 된다.

모든 코드는 여기서 확인할 수 있다: https://github.com/bitgadak/tistory-spring-security-preauth-sample

nexus3 docker image 로 private docker repository 만들기

빛가닥 — Mon, 14 Feb 2022 21:57:19 +0900

docker 를 많이 사용하다보니 자연스럽게 개인용 private docker repository 의 필요가 생긴다. nexus3 를 이용하면 docker 환경 내에서 docker repository 를 정말 쉽게 만들 수 있다. 그 과정을 기록해 보려고 한다.

환경

nexus3 는 docker 로 띄울 것이고, ssl 인증이 필요하기 때문에 nginx 가 이 역할을 맡도록 한다.
- nexus 와 nginx 는 모두 docker 컨테이너로 띄울 것이다.
- nexus 컨테이너의 이름은 nexus, nginx 컨테이너의 이름은 nginx 로 할 것이다.
도메인명: 이 글에서는 nexus 인터페이스는 my-test-nexus.com, 그리고 새로 만들 private repository 는 my-test-docker.com 라는 도메인명으로 접근한다고 가정하고 작업한다. (hosts 파일을 고쳐서 테스트한다.)
서버 정보
- OS: CentOS 7.9
- IP: 192.168.101.101
- Docker 20.10.12

nginx 1.20.2 (https://hub.docker.com/_/nginx)
- 용도에 따라 라우팅을 한다. nexus 인터페이스를 위해서 my-test-nexus.com 으로 접근하면 nexus의 8081 로 연결하고, docker repository 를 위해 my-test-docker.com 으로 접근하면 nexus 의 8082 로 전달한다.
nexus3 3.37.3 (https://hub.docker.com/r/sonatype/nexus3/)
- 8081 포트로 인터페이스를 담당하고, 8082 로 docker repository 를 열 것이다.
ssl: repository 에 대해서는 nginx 에서 ssl 인증 처리를 해 줄 것이다.
- 이름은 test-chained.crt, test.key (repository 를 위한 것이기 때문에 my-docker.com 으로 도메인 이름이 들어가 있어햐 한다.)
- 발급 방법은 아래 포스트를 참고한다.
  - openssl 로 self-signed certificate 만들기(추가적인 작업 필요): https://bitgadak.tistory.com/5
  - certbot 으로 let's encrypt 인증서 발급받기: https://bitgadak.tistory.com/6

아래와 같은 구조가 될 것이다.

1. nexus 실행

1.1 nexus 컨테이너 실행

도커 이미지가 유지되어야 하기 때문에 도커 볼륨이 필요하다. nexus 라는 이름으로 만든다.

$ docker volume create nexus

nexus3 3.37.3 이미지로 컨테이너를 만든다.

$ docker run -d --name nexus -v nexus:/nexus-data -p 8081-8082:8081-8082 sonatype/nexus3:3.37.3

컨테이너 이름은 nexus
위에서 만든 볼륨을 연결한다.
nexus 의 기본 포트는 8081 이다. 추가로 8082 포트를 private docker 의 포트로 사용하도록 한다.
- 만약 nexus 포트를 외부에 노출하고 싶지 않다면 -p 옵션은 없어도 된다.

1.2 nexus 설정

nexus 컨테이너가 떴는지 8081 로 접근하여 확인해 보자. 조금 시간이 걸린다.

이하 hosts 를 수정하고 my-test-nexus.com 로 진행한다. 로그인을 해 본다.

최초의 임시 비밀번호는 /nexus-data/admin.password 에 적혀있다.

이걸로 로그인을 할 수 있다. 로그인을 하고 next 를 눌러 진행하다보면 새로운 패스워드를 요구한다.

새로운 패스워드를 넣고 진행하자. Anonymous Access 에 대해서는 기본값(enable)으로 둔다.

완료되었다.

2. Docker repository 설정

nexus 에서 docker repository 관련하여 직접 repository 를 만들 수도 있고, proxy 를 만들수도 있다. 그런데, 굳이 proxy 가 필요할 것 같진 않아서 직접 repository 를 만드는 것으로 진행한다.

(repository 와 proxy 를 모두 만들고 group 으로 묶는 방법도 있긴 한데, 무료 라이센스에서는 지원하지 않는다.)

2.1 Blob Stores

먼저 image 를 저장할 blob stores 를 만든다.

Type 은 File (s3 는 클라우드 저장소) 으로 정하고 이름은 docker-hosted 로 정한다.

enable soft quota 옵션이 있는데, 체크하면 blob 를 모니터링 하다가 용량 초과시 알림을 주는 것 같다. 필요없는 것 같아서 체크하지 않는다.

설정에 대한 자세한 설명은 여기서 참고한다: Configuring Blob Stores

2.2 Repository

repository 를 만든다.

docker (hosted) 를 선택한다.

필요한 정보를 입력하고 저장소를 만든다.

정보는 다음과 같다.

Name: docker-hosted
HTTP: 8082 포트. ssl 은 nginx 에서 처리할 것이기 때문에 여기서는 HTTP 로 열어준다.
Blob store: docker-hosted (위에서 만든 blob store 이다.)
나머지는 기본값으로 설정한다.

repository 를 만들었다. 그러나 아직은 ssl 설정이 안되어서 docker api 로 접근은 안된다.

3. nginx 설정

ssl 인증을 해 주고, 도메인 별 라우팅을 해 주기 위해 nginx 설정을 한다. 여기서는 docker 로 띄우지만, 호스트에 설치하는 것도 상관없다.

nginx docker image 사용에 대해서는 docker hub 를 참고하였다: https://hub.docker.com/_/nginx

Nginx - Official Image | Docker Hub

Quick reference Supported tags and respective Dockerfile links 1.21.6, mainline, 1, 1.21, latest 1.21.6-perl, mainline-perl, 1-perl, 1.21-perl, perl 1.21.6-alpine, mainline-alpine, 1-alpine, 1.21-alpine, alpine 1.21.6-alpine-perl, mainline-alpine-perl, 1-a

hub.docker.com

여기서 nginx 설정을 하는 방법을 여러 가지 소개하고 있는데, 그 중에 하나는 컨테이너 내부의 설정파일을 직접 수정 추가 하는 것이다.

1.20.2 기준으로 Docker run 을 통해 컨테이너를 시작하면 nginx 가 시작하면서, /etc/nginx/nginx.conf 를 불러온다.

여기서 /etc/nginx/nginx.conf 를 직접 수정해도 되지만, 기본 nginx.conf 파일에서는 include /etc/nginx/conf.d/*.conf; 라는 항목이 있어서 /etc/nginx/conf.d 디렉토리의 *.conf 의 설정 정보들을 불러온다.

그래서 해당 디렉토리에 필요한 설정파일을 *.conf 라는 이름으로 추가하는 방식을 통해 설정할 수 있다.

컨테이너 실행시 명령어로 -v 옵션을 주어 추가하는 방법도 있겠지만, Dockerfile 을 통해 필요한 파일이 들어가 있는 새로운 이미지를 만드는 것이 깔끔할 것 같아서 그렇게 실행하려고 한다.

3.1 nexus.conf

nexus 컨테이너는 두 개의 포트가 열려있다. 8081 은 nexus 인터페이스용 포트이고, 8082 는 docker repository 로 사용하려고 연 포트이다.

my-test-nexus.com 으로 들어오면 8081 로, my-test-docker.com 로 들어오면 8082 로 전달하도록 한다.

세부적인 설정 제외하고 간단하게 만들면 다음과 같다.

upstream nexus {
    server nexus:8081;  # docker 로 띄운 nexus 컨테이너 이름
    keepalive 8;
}

upstream nexus-docker-hosted {
    server nexus:8082;  # docker 로 띄운 nexus 컨테이너 이름
    keepalive 8;
}

server {
    listen       80;
    server_name  my-test-nexus.com;

    location / {
        proxy_pass  http://nexus;
    }
}

server {
    listen       443 ssl;
    server_name  my-test-docker.com;

    ssl_certificate     /etc/nginx/test-chained.crt;
    ssl_certificate_key /etc/nginx/test.key;

    location / {
        proxy_pass           http://nexus-docker-hosted;
        client_max_body_size 2048m;  # docker image 업로드시 필요한 업로드 용량 제한 늘리기
    }
}

기타 nginx 설정이 필요하면 추가하도록 하자.

3.2 Dockerfile 및 이미지 생성

ssl 에 대한 파일과 위에서 만든 nexus.conf 설정파일을 넣어 새로운 이미지를 만든다.

디렉토리 구조는 아래와 같다.

/jenkins
+- Dockerfile
+- test-chained.crt
+- test.key
+- conf.d/
   +- nexus.conf

Dockerfile 은 다음과 같다.

FROM nginx:1.20.2

COPY *.crt /etc/nginx/
COPY *.key /etc/nginx/
COPY conf.d/ /etc/nginx/conf.d/

이미지를 만든다.

docker build -t my-nginx:0.1

3.3 nginx 컨테이너 실행

새로 만든 이미지로 컨테이너를 실행한다. 이 때, nginx 컨테이너 내부에서 nexus 컨테이너를 호출할 수 있어야 하기 때문에 link 옵션을 추가한다.

docker run -d --name nginx -p 80:80 -p 443:443 --link nuxus:nuxus my-nginx:0.1

4. 확인

hosts 를 설정하고, 테스트 해 보자. https://my-test-docker.com (https!)로 브라우저로 접근하면 아래와 같이 접근이 가능하다.

그런데, 이 때, self-signed certificate 로 만든 인증서를 사용했다면, docker login 을 해 보면 다음과 같이 나오며 접근이 불가하다.

$ docker login my-test-docker.com
Username: admin
Password: 
Error response from daemon: Get "https://my-test-docker.com/v2/": x509: certificate signed by unknown authority

신뢰할 수 있는 인증서 로 등록되지 않았기 때문인데, CentOS 에서는 /etc/pki/ca-trust/source/anchors/ 에 추가하고 docker 를 재시작하면 되기는 한데, (https://bitgadak.tistory.com/5 의 4.2 참고) 이 경우 docker 를 재시작해야 하는 문제가 있다.

다른 방법으로는 /etc/docker/certs.d/ 에 도메인명 디렉토리 이름을 정하고 그 안에 *.crt 로 crt 파일을 넣는 방법이 있다. 예를 들어 이 경우 도메인이 my-test-docker.com 이기 때문에 만들어둔 crt 를 /etc/docker/certs.d/my-test-docker.com/ 에 넣어주면 된다.

(참고: https://docs.docker.com/engine/security/certificates/)

잘 된다.

직접 push 를 해 보자. 위에서 만든 my-nginx:0.1 을 push 해 본다.

먼저 tag 명령어로 이미지 이름을 my-test-docker.com/ 으로 시작하도록 변경한다.

$ docker tag my-nginx:0.1 my-test-docker.com/my-nginx:0.1

push 한다.

$ docker push my-test-docker.com/my-nginx:0.1
The push refers to repository [my-test-docker.com/my-nginx]
27b7bb9a8f7f: Pushed 
27b1fc072fad: Pushed 
2318312b5335: Pushed 
c75c795b7d44: Pushed 
4e498ce5ae6a: Pushed 
35437a3771fc: Pushed 
108a6d6c3e60: Pushed 
9ccbab2746b8: Pushed 
2edcec3590a4: Pushed 
0.1: digest: sha256:fab48ce9f740e614056c1d308f54297a865ed91d25fbea5eab79e7389af1bee6 size: 2193

잘 들어가 있음을 확인할 수 있다.

docker 환경에서 nginx 로 jenkins ssl 적용

빛가닥 — Wed, 9 Feb 2022 15:00:08 +0900

jenkins 를 외부에 공개해야 할 필요가 있다면 nginx 를 프록시로 사용하여 ssl 을 비롯한 각종 처리를 하게 하는 것도 괜찮은 방법이다. 그런 상황이 생겨서 한 번 적용해 보았다.

환경

CentOS 7.9
docker 20.10.12
- 참고: nginx 컨테이너 내부에서 jenkins 컨테이너를 호출할 수 있어야 한다. run 시 --link 옵션을 사용하여 해결하도록 한다.
nginx 1.20.2
- 직접 설치해서 사용해도 되지만 여기서는 docker 로 실행해보려고 한다.
jenkins 2.289.3
- 8080 포트로 열려있는 상태이다. 실습에서는 docker 로 띄웠는데, 도커를 이용하지 않아도 상관없다. jenkins 를 도커로 구동하는 것에 대해서는 https://bitgadak.tistory.com/3 를 참고한다.
- nginx 에서 해당 컨테이너를 찾을 수 있어야 한다. 이름으로 찾을 수 있는데, jenkins 라는 이름으로 추가되어 있다고 한다.
이 글에서는 임의로 젠킨스 서버 도메인을 my-jenkins.com 정하고, 해당 도메인으로 요청하면 젠킨스로 전달한다.
ssl 인증서: nginx 로 ssl 를 적용할 것이기 때문에 필요하다.
- 이름은 jenkins-chained.crt, jenkins.key 로 준비
- 발급 방법에 대해서는 아래를 참고한다.
  - openssl 로 self-signed certificate 만들기: https://bitgadak.tistory.com/5
  - certbot 으로 let's encrypt 인증서 발급받기: https://bitgadak.tistory.com/6

아래와 같은 형식이 될 것이다.

1. Nginx docker image

nginx docker image 사용에 대해서는 docker hub 를 참고하였다: https://hub.docker.com/_/nginx

Nginx - Official Image | Docker Hub

hub.docker.com

여기서 nginx 설정을 하는 방법을 여러 가지 소개하고 있는데, 그 중에 하나는 컨테이너 내부의 설정파일을 직접 수정 추가 하는 것이다.

1.20.2 기준으로 Docker run 을 통해 컨테이너를 시작하면 nginx 가 시작하면서, /etc/nginx/nginx.conf 를 불러온다.

그래서 해당 디렉토리에 필요한 설정파일을 *.conf 라는 이름으로 추가하는 방식을 통해 설정할 수 있다.

1.1 jenkins.conf

컨테이너 실행시 /etc/nginx/conf.d/ 디렉토리 내부에 들어갈 젠킨스를 위한 설정 파일이다.

jenkins 를 위한 nginx 설정에 대해서는 참고할 만한 정보가 있다.

https://www.jenkins.io/doc/book/system-administration/reverse-proxy-configuration-nginx/

Reverse proxy - Nginx

In situations where you have existing web sites on your server, you may find it useful to run Jenkins (or the servlet container that Jenkins runs in) behind Nginx, so that you can bind Jenkins to the part of a bigger website that you may have. This section

www.jenkins.io

여기를 참고하지만 불필요한 부분을 제거하고 필요한 부분을 추가해서 수정한다.

upstream jenkins {
    server jenkins:8080; # docker 로 띄운 jenkins 컨테이너의 이름이다.
    keepalive 32;
}

# websocket 을 위한 설정
map $http_upgrade $connection_upgrade {
  default upgrade;
  '' close;
}

server {
    listen       80;
    listen       443 ssl;
    server_name  my-jenkins.com; # 요청이 my-jenkins.com 으로 온다면 처리

    ssl_certificate     /etc/nginx/jenkins-chained.crt;
    ssl_certificate_key /etc/nginx/jenkins.key;

    # Jenkins 가 추가로 필요한 header 가 있다면 허용
    ignore_invalid_headers off;

    location / {
        proxy_pass         http://jenkins;
        proxy_redirect     default;
        proxy_http_version 1.1;

        # websocket 을 위한 설정
        proxy_set_header   Connection        $connection_upgrade;
        proxy_set_header   Upgrade           $http_upgrade;

        proxy_set_header   Host              $host;
        proxy_set_header   X-Real-IP         $remote_addr;
        proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_max_temp_file_size 0;

        #this is the maximum upload size
        client_max_body_size       10m;
        client_body_buffer_size    128k;

        proxy_connect_timeout      90;
        proxy_send_timeout         90;
        proxy_read_timeout         90;
        proxy_buffering            off;
        proxy_request_buffering    off; # HTTP CLI commands
    }
}

서버 도메인은 my-jenkins.com 이다.
인증서를 추가한다.
- jenkins-chained.crt 와 jenkins.key 를 /etc/nginx 에 넣을 것이다.
jenkins 에서 websocket 을 사용해서 관련 처리가 있다: http://nginx.org/en/docs/http/websocket.html
- websoket 을 사용하기 위해서는 Connection 헤더와 Upgrade 헤더가 젠킨스까지 잘 타고 가야 한다. 이를 위한 처리이다.
- map 블록: Upgrade 가 헤더가 들어오면 기본적으로 `$connection_upgrade` 변수에 upgrade 를 넣어서 전달하지만, Upgrade 헤더가 없으면 변수에 close 를 넣어서 전달한다.
- `$connection_upgrade` 변수는 젠킨스에 Connection 헤더를 통해 전달된다.
proxy_max_temp_file_size: 이걸 딱히 수정 안하면 1024MB(default) 이상 파일 다운로드가 안된다고 한다. 0 은 제한하지 않는다는 의미이다.
$remote_addr: nginx 변수이다. 클라이언트 주소가 전달된다. 참고
$proxy_add_x_forwarded_for: nginx 변수이다. 들어오는 X-Forwarded-For 헤더에 $remote_addr 이 콤마로 추가된다. 참고
참고한 페이지 에는 있었지만 제거한 설정
- sendfile 은 파일 전달 시 버퍼에 저장할지 말지에 대한 것인데 userContent 를 사용하지 않을 것이라 불필요하다.
- /static: 굳이 나눌 필요가 없을 것 같아서 제거
- /userContent: 젠킨스의 userContent 기능 역시 사용하지 않기 때문에 아예 제거 (userContent: https://www.jenkins.io/doc/book/managing/user-content/)

1.2 Dockerfile 및 이미지 생성

ssl 에 대한 파일과, 위에서 만든 jenkins.conf 설정파일을 넣어 새로운 이미지를 만든다.

아래와 같은 구조이다.

/jenkins
+- Dockerfile
+- jenkins-chained.crt
+- jenkins.key
+- conf.d/
   +- jenkins.conf

Dockerfile 은 다음과 같다.

FROM nginx:1.20.2

COPY *.crt /etc/nginx/
COPY *.key /etc/nginx/
COPY conf.d/ /etc/nginx/conf.d/

이미지를 만든다.

docker build -t my-nginx:0.1 .

2. 실행

새로 만든 이미지로 컨테이너를 실행한다.

docker run -d --name nginx -p 80:80 -p 443:443 --link jenkins:jenkins my-nginx:0.1

nginx 컨테이너 내부에서 jenkins 컨테이너에 접근이 가능해야 하기 때문에 link 옵션을 주었다. 아니면 docker network 를 따로 만들어서 두 컨테이너가 공유하는 방법도 있다.

이제 https 로 jenkins 에 접근이 가능하다.

hosts 를 고치고 https://my-jenkins.com 으로 접근해 보자.

certbot 으로 let's encrypt 인증서 발급받기

빛가닥 — Sun, 30 Jan 2022 00:48:41 +0900

certbot 을 통해 let's encrypt 인증서를 발급받아보자. 현재로서는 가장 간단한 방법인 것 같다. 공식 사이트 가이드를 따라 진행한다. 아래 페이지를 참고했다.

certbot 가이드: https://certbot.eff.org/instructions?ws=nginx&os=centosrhel7 (nginx, centos7)
snapd 가이드: https://snapcraft.io/docs/installing-snap-on-centos

준비

- 외부에서 접근 가능한 ip
- 도메인 (여기서는 필자가 소유하고 있는 crudewebtools.com 도메인을 사용한다.)
- 서버
- 열린 http(80) 포트 (인증서 발급에 필요), 열린 https(443) 포트 (인증서 발급 받고 사용할 것)
환경
- CentOS 7.9
- Nginx 1.20.2
참고
- 본문의 명령들은 모두 root 권한으로 실행하였다. root 가 아닌 경우 일부 sudo 로 실행해야 하는 경우가 있다.

1. Nginx 설치

인증서를 nginx 를 통해 등록하려고 한다. 설치되어 있지 않아서 먼저 설치한다. 이미 설치되어 있다면 생략한다.

nginx 설치는 https://www.nginx.com/resources/wiki/start/topics/tutorials/install/ 를 참고하여 진행하였다.

먼저 repo 를 등록한다. /etc/yum.repos.d/ 디렉토리에 nginx.repo 를 만들고 아래와 같이 작성한다.

[nginx]
name=nginx repo
baseurl=https://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
enabled=1

이제 설치하자.

# yum -y install nginx

설치가 되었으면 확인해 보자. 1.20.2 로 설치가 되었다.

# nginx -v
nginx version: nginx/1.20.2

2. nginx 구동

외부에서 도메인으로 접근 가능한 상태여야 한다. 서버의 ip 에 대한 도메인 등록은 이미 되어 있다고 가정하고 진행한다.

nginx 를 시작해서 접근 가능한지 확인해 보자.

# systemctl status nginx

http 로 접근해 보자 http://crudewebtools.com

접근해 보면 nginx 가 구동중임을 알 수 있다. 인증서가 없기 때문에 경고 표시가 나온다.

3. snapd 설치

certbot 설치 페이지에서는 snapd 로 설치하는 것을 권장하고 있다. 먼저 snapd 를 설치해 보자.

먼저 snapd 가 centos 기본 저장소에 없기 때문에, epel-release 설치가 필요하다.

# yum -y install epel-release

이제 snapd 를 설치하자.

# yum -y install snapd

이제 systemd 에 등록하자.

# systemctl enable --now snapd.socket
Created symlink from /etc/systemd/system/sockets.target.wants/snapd.socket to /usr/lib/systemd/system/snapd.socket.

잘 되었는지 확인. enabled 로 되어 있는 것을 볼 수 있다.

# systemctl list-unit-files | grep snapd.socket
snapd.socket                                  enabled

공식 페이지에는 classic snap support 를 위해서 아래와 같이 링크를 만들라고 하고 있다. 정확히 어떤 의미인지는 모르겠는데, 나중에 --classic 옵션을 사용하게 되기 때문에 추가해 두도록 하였다.

# ln -s /var/lib/snapd/snap /snap

아직 snapd 데몬이 뜨지 않았기 때문에 띄워준다.

# systemctl start snapd

3. certbot 설치

먼저 snapd 를 최신화하라고 한다.

# sudo snap install core; sudo snap refresh core

완료되면 확인해보자

# snap version
snap    2.54.2-1.el7
snapd   2.54.2-1.el7
series  16
centos  7
kernel  3.10.0-1127.19.1.el7.x86_64

이제 certbot 을 설치하자

# sudo snap install --classic certbot
certbot 1.22.0 from Certbot Project (certbot-eff✓) installed

certbot 명령어를 사용하기 위해 심볼릭링크를 걸자.

# ln -s /snap/bin/certbot /usr/bin/certbot

확인해 보자.

# certbot --version
certbot 1.22.0

잘 된다.

4. 인증서 발급

발급을 받아보자.

certonly 옵션은 인증서만 발급받는다는 의미이다. 이 옵션이 없으면 자동으로 nginx 설정을 수정해 준다고 하는데, 어떻게 바꿔주는 지 정확하게 인지하고 있는 것이 아니라면 사용하지 않는 것이 나을 것 같다. 필자의 경우 nginx 설정을 직접 해 줄 것이기 때문에 certonly 옵션을 추가한다.
nginx 에 설정할 것이기 때문에 --nginx 옵션을 추가한다.
도메인이 crudewebtools.com 이니 이것도 정확하게 써 준다.

# certbot certonly --nginx -d crudewebtools.com

이메일을 요구한다. 적어준다.

약관 동의 요구에는 y 로 동의하고, 이메일을 통해 소식을 전달해 준다는 것에 대해서는 거절하였다.

인증서는 /etc/letsencrypt/live 아래 위치한다. 정상적으로 발급되었는지 확인해 보자

# ls -l /etc/letsencrypt/live/crudewebtools.com/
total 4
lrwxrwxrwx 1 root root  41 Jan 30 00:09 cert.pem -> ../../archive/crudewebtools.com/cert1.pem
lrwxrwxrwx 1 root root  42 Jan 30 00:09 chain.pem -> ../../archive/crudewebtools.com/chain1.pem
lrwxrwxrwx 1 root root  46 Jan 30 00:09 fullchain.pem -> ../../archive/crudewebtools.com/fullchain1.pem
lrwxrwxrwx 1 root root  44 Jan 30 00:09 privkey.pem -> ../../archive/crudewebtools.com/privkey1.pem
-rw-r--r-- 1 root root 692 Jan 30 00:09 README

5. nginx 에 인증서 적용

위에서 발급 받은 인증서를 nginx 에 적용해 보자. 테스트를 위한 것이라 간단하게 /etc/nginx/conf.d/default.conf 를 고쳐보았다. 이 때, nginx 의 경우 꼭 fullchain.pem 을 사용해야 한다.

server {
    listen       80;
    listen       443 ssl;
    server_name  crudewebtools.com;

    ssl_certificate     /etc/letsencrypt/live/crudewebtools.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/crudewebtools.com/privkey.pem;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

nginx 를 reload 하자.

# nginx -s reload

이제 https 로 접근해 보자. https://crudewebtools.com

인증서가 적용되었다.

6. 인증서 갱신에 대한 정보

원래 let's encrypt 에서 발급하는 인증서는 유효기간이 3개월이기 때문에 주기적으로 갱신을 해 주어야 한다. certbot 의 경우에도 갱신을 위한 명령어가 존재한다.

그런데, 위 과정을 거쳐 certbot 을 통해 인증서를 발급 받은 경우, 자동으로 만료되기 20 일 전 쯤 갱신을 해준다.

해당 예약 명령은 systemd.timer 에 등록되어 있다.

확인해 보자.

# systemctl list-timers
NEXT                         LEFT       LAST                         PASSED       UNIT                         ACTIVATES
Sun 2022-01-30 01:32:00 KST  49min left n/a                          n/a          snap.certbot.renew.timer     snap.certbot.renew.service
Sun 2022-01-30 22:55:40 KST  22h left   Sat 2022-01-29 22:55:40 KST  1h 46min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

2 timers listed.
Pass --all to see loaded but inactive timers, too.

서버에 별 문제가 생기지 않는다면 자동으로 알아서 계속 갱신해 줄 것이다.

openssl 로 self-signed certificate 만들기

빛가닥 — Fri, 10 Sep 2021 11:56:20 +0900

서버에서 사용할 self-signed 인증서를 만드려고 한다.

X.509 extensions

보통 브라우저에서는 상관없지만, Docker api 등에서는 인증서의 v3 extension 필드를 요구하는 경우가 있다. 이 경우를 위해 extension 의 일부 필드를 사용한다.

- basicConstraints: root 인증서에서 사용할 필드이다. 다른 인증서(서버용 인증서) 에 서명을 하는 경우 필요하다.

- subjectAltName: 서버 인증서에서 사용할 필드이다. 도메인과 일치하는 DNS 값이 있어야 한다. 이전에는 CN(Common Name) 만 도메인과 동일하면 문제가 되지 않았는데, 도커 20.10.8 에서는 api 사용 시 이 값이 도메인과 일치하는 것을 요구해서 추가하였다.

openssl 에서 extension 파라미터를 넘기는 방법이 여러개 있는데, 여기서는 파일을 전달하는 방식을 사용한다.

또한, 파일 전달 형식에서도,-extfile {{config 파일명}} -extensions {{section이름}} 으로 진행하는 방법이 있고, section 이름 없이 필요한 정보만 적은 파일을 -extfile 로 전달하는 방식이 있는데 후자를 선택한다. (-extensions 가 없으면 default section (파일 내에서 별도로 section 으로 정의하지 않은 영역) 을 사용하게 된다.)

extensions 의 종류와 파라미터 전달 방식은 아래를 참고:

- x509 명령어 옵션들: https://www.openssl.org/docs/manmaster/man1/openssl-x509.html

- v3 conig 에 들어갈 수 있는 값, 포맷 정리: https://www.openssl.org/docs/manmaster/man5/x509v3_config.html

진행 환경:

동일한 환경을 유지 하기 위해서 docker 컨테이너를 이용하였지만, 굳이 docker 컨테이너 내부에서 진행할 필요는 없다. 혹시 docker 컨테이너를 사용하려고 한다면 결과물을 호스트 서버로 꺼내야 하니까 마운트 하는 것을 잊지 말자.

- Rocky Linux 8.5 (docker image)
- root 로 진행
- openssl 버전: 1.1.1k (yum install 로 설치한 경우)

인증서 내용:

1. openssl 설치

yum 으로 설치한다.

# yum -y install openssl

버전 확인

# openssl version
OpenSSL 1.1.1k  FIPS 25 Mar 2021

2. root 인증서

2-1. root 를 위한 키를 우선 만든다.

# openssl genrsa -aes256 -out root.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
........+++++
..................................+++++
e is 65537 (0x010001)
Enter pass phrase for root.key:
Verifying - Enter pass phrase for root.key:

이 때, pass phrase 를 요구한다. 나중에 서버 인증서 서명시 필요하니 기억해야 한다.

참고로 비밀번호가 4개 보다 작으면 아래처럼 에러가 발생한다.

UI routines:UI_set_result_ex:result too small:crypto/ui/ui_lib.c:905:You must type in 4 to 1023 characters

또한, 일반적으로는 문제가 없지만, 혹시 권한 문제가 있다면 아래처럼 권한을 변경한다.

# chmod 600 root.key

그 다음은 CSR(Certificate Signing Request) 을 만들자. 미리 정한 값을 넣는다.

# openssl req -new -key root.key -out root.csr
Enter pass phrase for root.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:KR
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:Seoul
Organization Name (eg, company) [Default Company Ltd]:bitgadak
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:bitgadak root
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

잘 들어갔는지 확인해 보자

# openssl req -in root.csr -noout -text
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: C = KR, L = Seoul, O = bitgadak, CN = bitgadak root
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    (...생략...)
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         (...생략...)

이제 인증서를 만들어야 하는데, 거기에 전달할 extensions 을 위한 파일을 만들자. 파일명은 root.ext 로 하였다.

root 에서 필요한 확장 필드는 basicConstraints 이다.

# cat root.ext
basicConstraints = CA:TRUE

이제 위에서 만든 CSR 과 extension 파일을 가지고 인증서를 만든다. (10년)

# openssl x509 -req -days 3650 -in root.csr -signkey root.key -extfile root.ext -out root.crt
Signature ok
subject=C = KR, L = Seoul, O = bitgadak, CN = bitgadak root
Getting Private key
Enter pass phrase for root.key:

내용을 확인해 보자

# openssl x509 -text -in root.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            (...생략...)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = KR, L = Seoul, O = bitgadak, CN = bitgadak root
        Validity
            Not Before: Sep 10 01:48:21 2021 GMT
            Not After : Sep  8 01:48:21 2031 GMT
        Subject: C = KR, L = Seoul, O = bitgadak, CN = bitgadak root
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    (...생략...)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
         (...생략...)
-----BEGIN CERTIFICATE-----
(...생략...)
-----END CERTIFICATE-----

extensiosn 도 잘 들어가 있다.

3. 서버용 인증서

key 를 만들자. 일단은 비밀번호를 추가해서 만들어야 한다.

# openssl genrsa -aes256 -out server-with-password.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
..............+++++
....................................+++++
e is 65537 (0x010001)
Enter pass phrase for server-with-password.key:
Verifying - Enter pass phrase for server-with-password.key:

비밀번호를 제거한 버전을 만든다.

# openssl rsa -in server-with-password.key -out server.key
Enter pass phrase for server-with-password.key:
writing RSA key

서버용 CSR 생성

# openssl req -new -key server.key -out server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:KR
State or Province Name (full name) []: 
Locality Name (eg, city) [Default City]:Seoul
Organization Name (eg, company) [Default Company Ltd]:bitgadak
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:bitgadak.tistory.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

인증서 생성시 필요한 extensions 를 적은 파일을 만든다. 이름은 server.ext 로 하였다.

여기서 필요한 확장 필드는 subjectAltName 이다. 여러 개가 필요한 경우 DNS.1, DNS.2 처럼 넣을 수 있는데, 일단 하나만 적었다. @alt_names 는 alt_names 섹션 ([alt_names] 이하 영역) 을 불러온다는 의미이다.

# cat server.ext
subjectAltName = @alt_names

[alt_names]
DNS = bitgadak.tistory.com

이제 인증서를 만들자 (1년)

# openssl x509 -req -days 365 -in server.csr -extfile server.ext \
  -CA root.crt -CAkey root.key -CAcreateserial -out server.crt
Signature ok
subject=C = KR, L = Seoul, O = bitgadak, CN = bitgadak.tistory.com
Getting CA Private Key
Enter pass phrase for root.key:

확인해 보자

# openssl x509 -text -in server.crt
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            (...생략...)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = KR, L = Seoul, O = bitgadak, CN = bitgadak root
        Validity
            Not Before: Sep 10 01:58:59 2021 GMT
            Not After : Sep 10 01:58:59 2022 GMT
        Subject: C = KR, L = Seoul, O = bitgadak, CN = bitgadak.tistory.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    (...생략...)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name: 
                DNS:bitgadak.tistory.com
    Signature Algorithm: sha256WithRSAEncryption
         (...생략...)
-----BEGIN CERTIFICATE-----
(...생략...)
-----END CERTIFICATE-----

완료되었다. 이제 서버에 적용하면 된다.

4. 기타

4-1. nginx 에서 사용시

nginx 에서 사용하려면 root 인증서 정보가 포함된 crt 를 입력해야 한다고 한다. 순서가 중요하다.

nginx 에서 사용할 crt 만들기. nginx 입장에서는 이름이 중요하진 않은데, server-chained.crt 라고 정했다.

# cat server.crt root.crt > server-chained.crt

이렇게 만든 파일을 nginx 의 설정 파일에서 server 영역 안에 넣어준다.

예시:

server {
    listen       443 ssl;
    (...생략...)

    ssl_certificate     /etc/nginx/server-chained.crt;
    ssl_certificate_key /etc/nginx/server.key;

    (...생략...)
}

4-2. CentOS 에서 신뢰할 수 있는 인정서 추가

Self-Signed 의 경우 Docker api 사용시 에러가 나온다. CentOS 라면 root 인증서를 신뢰할 수 있는 인증서로 추가하면 해결된다.

사용자가 인증서를 추가하는 경우엔

/etc/pki/ca-trust/source/anchors/

에 추가하고

$ sudo update-ca-trust

이렇게 갱신하면 된다.

Docker 가 인식하려면 Docker 의 재시작이 필요하다. 재시작 없이 리로딩 했으면 좋겠는데, 아직 방법을 모르겠다.

수정사항

2022-02-13: 인증서를 만든 컨테이너 이미지를 CentOS 8 에서 Rocky Linux 로 변경 (CentOS 8 저장소 만료로 인해 yum install 이 동작하지 않음)

kubeadm 으로 local kubernetes 환경 구축

빛가닥 — Wed, 8 Sep 2021 14:44:19 +0900

kubernetes 를 제공해 주는 서비스가 많지만 때로는 직접 구축해야 할 필요가 있다. 그런데 막상 설치해보려니 신경 쓸 것도 많고, 선택을 해야 하는 것이 많아서 쉽지가 않았다. 과정을 기록해 보려고 한다.

선택1 - 컨테이너 런타임: docker

kubernetes 는 요구하는 스펙이 맞으면 굳이 특정 컨테이너 런타임을 사용할 필요는 없다. 다만 docker 가 가장 익숙하기 때문에 이를 사용하도록 하였다.

참고: 컨테이너 런타임

선택2 - 설치 도구: kubeadm

kubernetes 환경 설치를 위해 사용할 수 있는 도구들이 있다: kubeadm, kOps, kubespray 등. 이 중 공식 사이트에 가장 설명이 잘 되어 있는 것은 kubeadm 인 것 같아서 이를 선택했다.

선택3 - 네트워크 애드온: calico

kubernetes 의 네트워크를 사용하기 위해서는 kubernetes 네트워크 모델을 구현한 애드온을 실행할 필요가 있다. 많으 종류가 있는데, 그 중 calico 가 간단하고, 많이 사용하고 있어서 선택하였다.

참고: 네트워크 애드온 kubernetes network model

환경

서버1: 컨트롤 플레인 (10.10.1.101)

- CentOS 7.9

- Docker 20.10.8

- kubernetes: 1.22.1

서버2: 워커 (10.10.1.102)

- CentOS 7.9

- Docker20.10.8

- kubernetes: 1.22.1

kubernetes 네트워크:

- 서버 네트워크 대역: 10.10.1.0/24

- kubernetes 네트워크 서비스 대역: 172.22.0.0/16

- kubernetes 네트워크 파드 대역(calico): 192.168.0.0/16

이하 내용에서 별도로 명시하지 않은 과정은 컨트롤플레인 서버와 워커 서버에 모두 적용해야 하는 과정이다.

1. Docker 준비

사실 kubernetes 에서는 컨테이너 런타임이 필요한거지 반드시 Docker 를 사용해야 할 필요는 없다. 그러나 Docker 가 가장 익숙하기 때문에 그대로 사용하도록 했다.

1-1. enabled 설정

docker 서비스가 enabled 상태가 아니면 kubeadm 실행시 warning 이 뜬다. 어차피 docker 는 늘 사용할 것이기 때문에, enabled 로 등록하여 부팅시 docker 가 실행되도록 하자.

$ sudo systemctl enable docker.service

확인

$ systemctl list-unit-files | grep "docker.service"

1-2. Docker cgroup 드라이버 설정

kubernetes 에서는 도커의 cgroup 관리에 systemd 를 사용하는 것을 권장하고 있다. systemd 가 아니면 kubeadm 구동시 warning 이 뜬다. 무시해도 동작은 하는 것 같지만 맞춰주자.

도커를 중지시키고 디렉토리를 만든다. (디렉토리가 이미 존재할 수 있는데 이 경우 생략)

$ sudo mkdir /etc/docker

여기에 daemon.json 을 작성하자.

$ cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF

도커를 다시 실행하고 확인

$ docker info | grep Cgroup

2. iptables 설정

br_netfilter 모듈이 활성화 되어야 한다고 한다. CentOS 7.9 기준으로 이미 활성화 되어 있는데, 명시적으로 추가해 주자.

$ cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF

또한, iptables 관련 sysctl 설정을 수정해야 한다. 역시 CentOS 7.9 기준으로 활성화 되어 있긴 한데, 영구적용을 위해 sysctl.d 에 설정을 추가하자.

$ cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

리로딩 하여 적용한다.

$ sudo sysctl --system

3. swap 끄기

kubelet 사용을 위해서는 swap 을 비활성화 하는 것을 권장한다고 한다. 켜 있어도 kubernetes 실행은 가능하지만, 실제 swap 하는 시점에 예상과 다른 동작이 발생할 수 있다고 한다.

$ sudo swapoff -a

결과 확인

$ free -h

재부팅시에도 반영하려면 /etc/fstab 도 수정하자.

4. SELinux 비활성화

현재 kublet 스펙에서는 꺼야 한다고 한다.

먼저 비활성화

$ sudo setenforce 0

확인

$ sestatus | grep "Current mode"

Current mode 가 enforcing 에서 permissive 로 변경되었다.

이후 재부팅 등의 상황에도 적용되도록 /etc/selinux/config 를 고친다.

$ sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

SELINUX=enforcing 로 되어 있던 라인이 SELINUX=permissive 로 변경되었다.

5. firewalld 설정 (포트 열기)

kubernetes 에서 필요한 포트가 있고 calico 에서 필요한 포트가 있다.

참고

kubernetes 필수 포트: https://kubernetes.io/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
calico 필수 포트: https://docs.projectcalico.org/getting-started/kubernetes/requirements

(주의) 컨트롤 플레인 노드와 워커 노드에서 필요로 하는 포트가 다르다. 이하 각각 설명한다.

6-1. 컨트롤 플레인 (싱글 컨트롤 패널)

컨트롤플레인 서버에서 열지 않으면 문제가 생기는 포트가 있다. firewall-cmd 를 통해 열어준다.

$ sudo firewall-cmd --permanent --add-port=179/tcp
$ sudo firewall-cmd --permanent --add-port=6443/tcp
$ sudo firewall-cmd --permanent --add-port=10250/tcp

179 포트가 안열리면 calico-node 관련 pod 가 ready 상태가 되지 않는다. ready 상태가 아니면, calico 가상 network (예를 들어 192.168.62.129) 에 접근하려고 하면 접근되지 않는다. kubernetes 내부로 가야할 것이 외부 게이트웨이로 빠져버린다.
6443 은 kubelete api 를 위한 포트이다.
10250 을 안열어주면 해당 노드에 돌고 있는 pod 에 대한 kubectl exec 가 동작하지 않는다. 컨트롤 플레인 에서도 필요한지는 모르겠는데, waring 에 나와서 그냥 열어줬다.

공식 페이지에는 10251, 10252 포트도 필요하다고 하는데, 최소한 현재 구성중인 환경 기준으로는 열지 않아도 실행할 때는 문제가 없었다.

firewalld 를 재시작 하여 반영한다. (주의: permanent 로 설정하지 않은 설정값들이 있다면 사라진다.)

$ sudo systemctl restart firewalld

6-2. 워커

워커에서 열어야 하는 포트들이 있다.

$ sudo firewall-cmd --permanent --add-port=179/tcp
$ sudo firewall-cmd --permanent --add-port=10250/tcp
$ sudo firewall-cmd --permanent --add-port=30000-32767/tcp
$ sudo firewall-cmd --permanent --add-masquerade

179 포트가 안열리면 calico-node 관련 pod 가 ready 상태가 되지 않는다. ready 상태가 아니면, calico 가상 network (예를 들어 192.168.62.129) 에 접근하려고 하면 접근되지 않는다. kubernetes 내부로 가야할 것이 외부 게이트웨이로 빠져버린다.
10250 을 안열어주면 해당 노드에 돌고 있는 pod 에 대한 kubectl exec 가 동작하지 않는다.
30000-32767 는 NodePort 서비스 실행시 사용된다.
masquerade 를 안하면 calico 네트워크 대역(192.168) ip 주소로 들어오는 요청을 처리하지 못한다. (물리 네트워크 대역 10.10 이 아닌 192.168 로 들어온다.)

firewalld 를 재시작 하여 반영한다. (주의: permanent 로 설정하지 않은 설정값들이 있다면 사라진다.)

$ sudo systemctl restart firewalld

7. 설치

먼저 레포지토리를 추가한다.

$ cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kubelet kubeadm kubectl
EOF

yum 을 통해 설치한다.

$ sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

먼저 kubelet 을 띄워놓자. 우선 systemctl 에 등록한다.

$ sudo systemctl enable --now kubelet

버전에 따라서 enable 명령시 --now 옵션이 안먹을 때가 있다. 그럴 때는 그냥 아래처럼 리로드 해준다.

$ sudo systemctl daemon-reload

실행

$ sudo systemctl restart kubelet

systemctl 로 확인해 보면 서비스 실행이 실패했다고 뜨는데, 나중에 kubeadm 이 다 구성되면 자동으로 해결된다.

8. 초기화 및 조인

(주의) 이하 진행은 컨트롤 패널 서버와 노드가 다르다.

먼저 컨트롤 플레인에서 kubernetes 를 초기화하고 워커를 추가하는 개념이다.

8-1. 컨트롤 플레인 노드 (싱글 컨트롤 플레인 초기화)

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

여기 보면 옵션이 많은데 하나를 제외하고는 모두 디폴트 값을 사용한다. --service-cidr 값만 수정해 주자. 이것은 서비스에 대하여 kubernetes 에서 할당할 ip 범위이다. 기본적으로 10.96.0.0/16 을 사용하고 있다. 그런데 현재 사설망이 10. 으로 시작해서 헷갈릴 것 같아서 172.22.0.0/16 으로 수정한다. (주의: 비슷한 옵션 --pod-network-cidr 이 있는데, 이건 다른 옵션이다.)

$ sudo kubeadm init --service-cidr=172.22.0.0/16

실행하면 아래와 같은 로그가 나오는데, 워커 노드에서 사용해야 하니 기억해 두자

    (...)
Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 10.10.1.101:6443 --token cmhczt.dqkpcn0fnytprotj \
    --discovery-token-ca-cert-hash sha256:733ec3943111f0bb91e5f37c9afeb878e638af6767e1c9b70e0689e10fec9d10

먼저 현재 사용자 기준으로 위 안내에 나온 걸 실행해 준다.

$ mkdir -p $HOME/.kube
$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

이러면 root 가 아니더라도 kubectl 명령어를 사용할 수 있다. (원래도 단순 호출을 할 수는 있었는데, 실행을 하려면 막혔다.)

이렇게 kubeadm 을 통한 컨트롤플레인 초기화가 완료되었다. 다만 컨트롤플레인에는 calico 설치도 필요하다.

calico 의 경우 노드 서버 수 50개 기준으로 다른 가이드를 주고 있다.

https://docs.projectcalico.org/getting-started/kubernetes/self-managed-onprem/onpremises

이 경우는 50 개 미만의 가이드를 따른다.

먼저 설정 파일을 받는다.

$ curl https://docs.projectcalico.org/manifests/calico.yaml -O

그리고 적용한다.

$ kubectl apply -f calico.yaml

적용 후 시간이 지나면 pending 상태였던 coredns 도 Running 을 바뀌고 calico 관련 서비스가 돌고 있는 것을 확인할 수 있다.

8-2. 워커 노드 (조인하기)

위에서 컨트롤플레인 초기화시 나온 로그를 참고하여 적용한다.

$ sudo kubeadm join 10.10.1.101:6443 --token cmhczt.dqkpcn0fnytprotj \
    --discovery-token-ca-cert-hash sha256:733ec3943111f0bb91e5f37c9afeb878e638af6767e1c9b70e0689e10fec9d10

아래와 같은 로그가 나오며 완료된다.

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

9. 확인

컨트롤 플레인 서버에서 확인해 보자.

$ kubectl get node -o wide

NAME      STATUS   ROLES                  AGE   VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION           CONTAINER-RUNTIME
server1   Ready    control-plane,master   12h   v1.22.1   10.10.1.101     <none>        CentOS Linux 7 (Core)   3.10.0-1160.el7.x86_64   docker://20.10.8
server2   Ready    <none>                 12h   v1.22.1   10.10.1.102     <none>        CentOS Linux 7 (Core)   3.10.0-1160.el7.x86_64   docker://20.10.8

잘 적용되었다.

참고:

현 구조상, 컨트롤 플레인에는 pod 가 뜨지 않는다. pod 를 뜨게 설정할 수 있지만 생략한다.

DooD (docker-outside-of-docker) 를 통해 Jenkins 컨테이너에서 docker 사용하기

빛가닥 — Mon, 6 Sep 2021 20:55:44 +0900

Jenkins 를 docker 를 통해 컨테이너로 띄우는 것이 아주 편해져서 이제는 docker 로 운영하고 있다.

그런데, Jenkins 상에서 Docker 관련 작업이 필요하여 단순하게 컨테이너 내부에서 설치를 하려고 했는데, 내부에서 docker 를 띄우는 것과 관련하여 이것저것 이슈가 있다고 한다. (https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/)

관련해서 좀 더 찾아보았는데, 내부에서 Docker 를 전부 띄우지 말고 외부(호스트 환경) 의 Docker 와 소켓을 공유하여 사용하는 것이 그나만 나은 방법이라고 한다.

이를 기존의 방식인 Docker-in-docker 와 대비하여 Docker-outside-of-docker 라고 부르는 것 같다. 완전히 정착된 이름은 아닌 것 같지만 이 글에서는 이 이름을 사용하겠다.

공식 Jenkins 이미지: https://hub.docker.com/r/jenkins/jenkins

공식 Docker 이미지: https://hub.docker.com/_/docker (여기도 Docker-in-docker 를 추천하지 않는다고 쓰여있다.)

환경

호스트 서버
- CentOS 7.9
- Docker server: 20.10.8
- 사용자는 docker 그룹에 포함되어 있다. (sudo 없이 docker 명령어 입력 가능)
Jenkins 컨테이너
- 기본 이미지: 2.289.3-jdk11
  - 내부에서 Docker 를 사용해야 하기 때문에 이를 베이스로 새로 이미지를 만들 것이다.
- Docker client: 20.10.8

1. Jenkins 이미지 만들기

컨테이너 내부에서 외부(호스트) 도커와 통신해야 하기 때문에 추가로 설치할 것이 있다. 기본 이미지는 현시점 (2021-09-06) 에서 가장 최신의 lts 버전이고, jdk11 이 들어 있는 버전인 2.289.3-jdk11 을 택한다.

젠킨스 이미지: https://hub.docker.com/r/jenkins/jenkins/tags?page=1&ordering=last_updated&name=2.289.3-jdk11

Docker client 가 필요하기 때문에 Dockerfile 를 통해 설치하고 이미지를 만든다. 베이스 이미지가 Debian 기반이기 때문에 Debian 환경에 Docker 설치를 위한 가이드를 참고한다.

공식 가이드: https://docs.docker.com/engine/install/debian/

Dockerfile 은 아래와 같다.

FROM jenkins/jenkins:2.289.3-jdk11

USER root

RUN apt-get update \
 && apt-get -y install lsb-release \
 && curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg \
 && echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null \
 && apt-get update \
 && apt-get -y install docker-ce docker-ce-cli containerd.io
RUN usermod -u {{호스트의사용자아이디}} jenkins && \
    groupmod -g {{호스트의도커그룹아이디}} docker && \
    usermod -aG docker jenkins

USER jenkins

사이트에서 요구하는 패키지들이 있는데, 대부분 이미 설치되어 있고, lsb-release 만 추가로 설치하면 된다.
외부(호스트) 도커 서버를 사용할거라서 docker-ce-cli 만 설치해도 되기는 하지만, docker-ce 를 설치해야 docker 그룹이 생긴다. 괜히 건드렸다가 꼬일 것 같아서 그냥 가이드대로 다 설치했다.
컨테이너 내부 사용자 (jenkins) 가 호스트의 파일에 접근이 가능 가능하도록 호스트 사용자 아이디와 동일하도록 맞춰준다. (위 Dockerfile 에서 {{호스트의사용자아이디}})
- 사용자 아이디는 호스트의 /etc/passwd 에서 확인한다.
컨테이너의 도커 그룹 아이디를 호스트의 도커 그룹 아이디와 동일하게 맞춘다. (위 Dockerfile 에서 {{호스트의도커그룹아이디}})
- 도커 그룹 아이디는 호스트의 /etc/group 에서 확인한다.

이미지를 만든다.

docker build -t my-jenkins:0.1 .

확인

[user@host ~]$ docker image ls
REPOSITORY                 TAG             IMAGE ID       CREATED         SIZE
my-jenkins                 0.1             df9c3ec43a7c   4 minutes ago   1.15GB
jenkins/jenkins            2.289.3-jdk11   ea470c80c15d   5 weeks ago     680MB

2. volume 만들기

jenkins 설정 및 히스토리를 저장하고 재시작시에도 유지되도록 volume 을 만든다.

docker volume create jenkins

확인

[user@host ~]$ docker volume ls
DRIVER    VOLUME NAME
local     jenkins

3. Jenkins 컨테이너 실행

docker run -d --name jenkins \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v jenkins:/var/jenkins_home \
    -p 8080:8080 my-jenkins:0.1

핵심은 docker.sock 을 마운트 하는 것이다. 이를 통해 컨테니어 내부에서 외부(호스트) 의 docker 서버에 접근할 수 있다.
volume 을 마운트하고, 접근 포트를 열어준다.

컨테이너가 잘 떴는지 확인해 보자

[user@host ~]$ docker ps
CONTAINER ID   IMAGE            COMMAND                  CREATED         STATUS        PORTS                               NAMES
d57073d5fec2   my-jenkins:0.1   "/sbin/tini -- /usr/…"   3 seconds ago   Up 1 second   0.0.0.0:8080->8080/tcp, 50000/tcp   jenkins

jenkins 컨테이너 내부에서도 호스트의 docker 에 접근이 가능한지 내부에서 호출하여 확인해 보자

[user@host ~]$ docker exec jenkins docker ps
CONTAINER ID   IMAGE            COMMAND                  CREATED         STATUS         PORTS                               NAMES
d57073d5fec2   my-jenkins:0.1   "/sbin/tini -- /usr/…"   2 minutes ago   Up 2 minutes   0.0.0.0:8080->8080/tcp, 50000/tcp   jenkins

호스트의 도커 서버를 공유하고 있기 때문에 같은 결과가 나온다.