Bitnami 유료화 대응 방안과 여러 생각들

최근 Broadcom이 Bitnami를 인수하면서 Bitnami 이미지가 유료화되었습니다. 또한, Helm chart도 더 이상 유지보수가 이루어지지 않게 됩니다.

Broadcom이 Bitnami에 대한 권리를 가지게 되면서 이제 보안 설정에 대한 비용을 받겠다는 것으로 보이는데, 현재 회사에서도 Bitnami를 기존에 유용하게 사용하고 있어서 대응이 필요했습니다.

간단하지만 이를 대응하는 과정과, 후속 조치 방안을 조사하면서 들었던 여러 생각을 정리해 보았습니다.

Bitnami를 사용해 왔던 이유

Bitnami를 사용해 온 가장 큰 이유는 다음 3가지였습니다.

1. 편의성
   • Bitnami에는 기본적으로 설정된 보안 옵션이 많습니다.
     대표적으로 UID가 Dockerfile에 1000번대로 하드코딩되어 있어 루트 계정을 사용하지 않으며, existingSecret을 사용하여 비밀 정보를 values.yaml에 직접 주입하지 않고 사용하는 옵션도 대부분 서비스에서 지원합니다.
   • 일반적인 사용을 위해서는 기본 values.yaml 파일을 사용해도 될 정도로 구성이 잘 되어 있습니다.
2. 꾸준한 업데이트
   • Bitnami의 이미지와 Helm chart는 커뮤니티에 의해 꾸준히 관리되어 왔습니다.
   • 버전 업데이트도 꾸준히 이루어지기 때문에 최신 상태로 유지하기도 용이합니다.
3. 딱히 없는 대체재
   • Bitnami 정도의 완성도를 가진 대체재를 찾기 쉽지 않습니다.
   • 심지어 공식 Helm chart는 없는데 Bitnami에는 Helm chart가 있는 경우도 있습니다.

그래서 어떤 도구를 K8s 환경에 설치해야 할 때 검색해 보면 Bitnami 차트를 사용하는 케이스를 많이 볼 수 있었고, 때로는 신뢰도가 있는 유일한 선택지인 경우도 있었습니다.

유료화에 따른 대응

하지만 위에서 설명한 것처럼 Bitnami 이미지가 유료화가 진행되었기 때문에, 이제 같은 주소로 이미지를 사용하려 할 경우 Pull을 하지 못해 에러가 발생합니다. bitnamilegacy로 주소가 변경되었기 때문에, 이런 식으로 변경이 필요합니다.
(Helm chart마다 적용 방법이 다를 수 있습니다.)

global:
  security:
    allowInsecureImages: true

image:
  repository: bitnamilegacy/thanos

주의할 점은 initContainer 또는 하위 컴포넌트에서 Bitnami 이미지를 사용하는 경우 그 설정도 바꿔 주어야 한다는 것입니다.

예를 들어, Harbor 차트는 PostgresQL 등의 의존성을 사용하는 경우가 있는데, 이때 의존성 차트도 Bitnami이기 때문에 확인이 필요합니다. 또한, 여러 Bitnami 차트에서 볼륨 권한 변경이나 각종 설정을 변경하는 os-shell도 Bitnami 이미지를 기본으로 사용하기 때문에 주의해야 합니다.

추가 대응 방안

1. 기존 사용 리소스 백업

가장 우선순위가 높은 작업입니다.
당장은 bitnamilegacy로 주소를 변경함으로써 해결이 가능하지만, 이것도 계속 유지된다는 확신이 없습니다. 따라서 현재 사용하는 이미지를 (+ 가능하면 Helm chart도) 자체적으로 백업해 두어야 합니다.

2. Bitnami 차트 + 공식 이미지 조합

Bitnami 차트만 사용하고, 이미지를 공식 이미지 등으로 교체하는 방법입니다. 상대적으로 가벼운 Redis의 경우 단순 이미지만 변경해도 돌아간다는 의견을 꽤 찾아볼 수 있었고, Thanos도 이미지를 교체하여 돌아간다는 제보를 찾을 수 있었습니다.¹

하지만 Bitnami Helm chart가 자체 이미지에 많이 맞추어져 있어 작동하지 않는 경우가 더 많고, 이제 Helm chart도 더 이상 유지보수되지 않기 때문에 영구적인 해결법이라 볼 수는 없습니다.

3. 공식 Helm chart, Operator, 또는 대체재 활용

다행히도 자체 Helm chart나 Operator, 또는 오픈소스 프로젝트를 찾을 수 있는 경우도 많습니다:

• MongoDB: 공식 Kubernetes Operator
• Elasticsearch: 공식 Helm chart (Elastic Cloud on Kubernetes)
• Kafka: Strimzi Kafka Operator
  • Strimzi는 CNCF Incubating Project입니다.

이런 대체재를 사용하면서, 문제가 있다면 커뮤니티를 통해 기여하면서 고쳐나갈 수도 있습니다. 하지만 여전히 대체재가 아예 없는 경우도 있기 때문에, 최악의 경우 임시로 Bitnami 차트를 사용하거나 Custom 차트를 구성해야 할 수도 있습니다.

개인적인 생각

단기 조치를 끝내고 팀 내에서 회의를 가졌는데, 우선은 현재 사용하는 리소스를 백업해 두고 추후 상황을 지켜보자는 결정을 내렸습니다. 당장 이 부분에 많은 리소스를 할당하기 힘들고, 새로운 Helm chart를 위한 커뮤니티가 생기면서 대체재가 나올 수도 있기 때문입니다.

하지만 반드시 그럴 것이라는 보장은 없고, 만약 등장하더라도 꽤 시간이 걸릴 것으로 보입니다.

이번 일을 계기로 DevOps Engineer의 기본적인 보안 역량이 더 중요해질 것이라는 생각이 들었습니다.
물론 개인의 역량으로 커뮤니티를 따라가는 것은 힘든 일이지만, 기본적으로 많이 설정하게 되는 권한 설정(securityContext), 네트워크 정책(NetworkPolicy) 등의 Kubernetes 설정을 잘 알아두고 적재적소에 활용할 수 있어야 할 것 같습니다. 복잡한 보안 설정을 위해서는 더 알아야 할 것이 많겠지만, 반대로 기본부터 시작해도 많은 보안 문제를 방지할 수 있고 고급 보안의 토대가 될 수 있습니다.

또한 오픈소스라고 해서 언제나 안심할 수는 없다는 것을 다시 한번 깨달았습니다. 비슷한 사례 중 제가 개발자 커리어에서 가장 먼저 접했던 사례는 Elasticsearch의 기업화였습니다. 물론 지금은 거기에서 파생된 OpenSearch가 있지만, 2~3년 차에 진행했던 프로젝트에서 ELK 스택을 고도화시켜야 하는데 오픈소스 버전은 상한선이 있고, OpenSearch는 생태계가 안정화되지 않았다고 판단되어 혼선이 있었던 기억이 있습니다. 그 외에도 다른 오픈소스 프로젝트에서도 기업화를 시도하거나 라이선스를 변경하는 경우를 종종 볼 수 있는데, 이러한 가능성을 꾸준히 대비할 필요가 있을 것 같습니다.

개인적으로 바퀴를 새로 발명하지는 않는다는 생각이지만, 그래도 기본을 알아 두고 경계심을 유지하는 것이 항상 중요한 것 같습니다. 개인 작업물부터 회사 업무까지 하나하나 돌아보는 시간을 가져야 할 것 같네요.