{"id":"IL-0234","org":"IONOS Cloud","date":"2026-05-08","docs":[],"title":{"en":"An onboarding operator deployed without its scope file installed dev applications on other IONOS Kubernetes clusters","ko":"내부 배포 자동화가 개발용 애플리케이션을 고객의 Managed Kubernetes 클러스터들에 잘못 설치해 컨트롤 플레인 연결과 쿠버네티스 기능에 문제가 났다"},"domain":["kubernetes"],"impact":{"scope":"Additional Managed Kubernetes clusters were modified and received applications meant for a development cluster; some customers had control plane connection problems and degraded Kubernetes functionality, and cleanup ran until 15 May 2026","users":"Some Managed Kubernetes customers","region":"DE/TXL, DE/FRA and DE/FRA/2"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"IONOS treats the unintended change to cluster configurations as a failure of the controls that should keep internal operations from affecting customer environments.","ko":"클러스터 구성이 의도하지 않게 바뀐 것은 내부 작업이 고객 환경에 영향을 주지 못하게 막아야 할 통제가 실패했기 때문이다. 정리 작업 동안 영향을 받은 고객에게 진행 상황을 제대로 알리지 않아 불확실성이 더 커졌다."},"related":[],"sources":[{"url":"https://status.ionos.cloud/incidents/4y4f2kgqhkgk","kind":"official-status","archived":"https://web.archive.org/web/20260610053048/https://status.ionos.cloud/incidents/4y4f2kgqhkgk"}],"summary":{"en":"IONOS Cloud's onboarding operator, part of its platform framework, registers clusters with the deployment system and relies on a scoping configuration file to limit itself to a defined set of target clusters. For the onboarding of a new development cluster this file was to be propagated automatically to the deployment branch, but the propagation failed silently on a merge conflict; the cherry-pick failure was logged but did not stop the pipeline. A second change removed the operator from the exclusion list and triggered an immediate deployment. The deployment system did not halt the sync when configuration was missing, so the operator ran without any scope, treated further cluster-api based clusters as valid onboarding targets, modified them and installed the development cluster's applications on them. IONOS names a bug in the onboarding operator and, as the root cause, a gap in the CI/CD pipeline that let a deployment proceed without checking that all required configuration files had reached the target branch.\n\nIONOS identified a defect in a configuration filtering mechanism by 15:52 UTC, corrected the onboarding operator and hardened the deployment system configuration, audited the affected resources and rolled back the identified changes by 20:42 UTC on 8 May. A recovery script, tested through a full staging cycle first, then removed all unintended installations and updates from the affected production clusters, finishing on 15 May 2026. Customers were not kept properly informed about this cleanup, which added to their uncertainty.","ko":"2026-05-08 UTC+2 기준 15:22 에서 16:12 사이에, 새 Managed Kubernetes 개발 클러스터를 등록하는 정기 내부 작업 때문에 배포 자동화 시스템이 다른 클러스터들까지 대상으로 삼았다. 자동화는 그 클러스터들의 구성을 바꾸고 개발 클러스터용 애플리케이션을 설치했다. 일부 고객은 컨트롤 플레인 연결 문제와 쿠버네티스 기능 저하를 겪었고, 영향은 DE/TXL, DE/FRA, DE/FRA/2 의 Managed Kubernetes 에 미쳤다. 설치된 애플리케이션은 필요한 image pull secret 이 없어 실행되지 못했다.\n\nonboarding operator 는 클러스터를 배포 시스템에 등록하는 일을 하며, 범위 설정 파일로 작업 대상을 정해진 클러스터로 제한한다. 이번 등록 작업에서 이 파일은 배포 브랜치로 자동 전파되어야 했다. 하지만 병합 충돌로 전파가 아무 경고 없이 실패했다. cherry-pick 실패는 로그에 남았지만 파이프라인을 막지 않았다. 같은 때 다른 변경이 onboarding operator 를 제외 목록에서 뺐고, 곧바로 배포가 시작되었다. 배포 시스템은 설정이 빠졌을 때 동기화를 멈추도록 구성되어 있지 않아, operator 가 범위 제한 없이 배포되었다. 제한이 없는 operator 는 cluster-api 기반의 다른 클러스터들도 등록 대상으로 여겼다. IONOS 는 원인으로 두 가지를 들었다. 하나는 operator 의 소프트웨어 버그였다. 다른 하나는 필요한 설정 파일이 대상 브랜치에 다 들어갔는지 배포 전에 확인하는 장치가 파이프라인에 없었다는 점이었다. 배포를 지켜보던 팀에게는 모든 것이 정상으로 보였다.\n\n팀은 원인을 찾은 뒤 operator 를 고치고 배포 시스템 설정을 강화했다. 영향을 받은 리소스의 변경을 되돌리는 롤백을 5월 8일 저녁에 마쳤고, 5월 11일에 장애를 해결로 표시했다. 복구 스크립트를 만들어 스테이징에서 검증한 뒤 운영의 모든 영향 클러스터에 돌렸고, 5월 15일까지 의도하지 않은 설치와 변경을 모두 지웠다."},"trigger":{"en":"A routine internal operation onboarded a new Managed Kubernetes development cluster. The scoping configuration file for the onboarding operator failed to reach the deployment branch because of a merge conflict, and at the same time a second change removed the operator from the exclusion list, which deployed it at once.","ko":"새 Managed Kubernetes 개발 클러스터를 등록하는 정기 내부 작업에서 onboarding operator 를 제외 목록에서 빼는 변경이 들어가자 곧바로 배포가 시작되었다. 이때 operator 의 대상 범위를 정하는 설정 파일은 병합 충돌로 배포 브랜치에 들어가지 못한 상태였다."},"severity":"unknown","symptoms":["control-plane-unresponsive","image-pull-failures"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":null,"components":["ci-system","registry"],"root_cause":"deploy-rollout","remediation":[{"text":{"en":"Corrected the onboarding operator so it needs an explicit namespace configuration before acting on any cluster","ko":"onboarding operator 를 고쳐, 네임스페이스 설정이 명시되어 있어야만 클러스터에 작업하게 했다. 이제 operator 는 기본 설정만으로는 cluster-api 기반 클러스터에서 범위 없이 돌지 못한다."}},{"text":{"en":"Reconfigured the deployment system to fail deployments when required configuration files are missing","ko":"필요한 설정 파일이 없으면 배포가 실패하도록 배포 시스템을 다시 구성했다. 전에는 설정이 덜 갖춰져도 배포가 조용히 진행되었다."}},{"text":{"en":"Rolled back the identified changes on the affected resources","ko":"영향을 받은 리소스에서 찾아낸 변경을 되돌리는 롤백을 마쳤고, 남은 불일치가 있는지 리소스를 점검했다."}},{"text":{"en":"Ran a recovery script, validated in staging, that removed all unintended installations and updates from the affected clusters","ko":"복구 스크립트를 만들어 스테이징에서 검증한 뒤 운영의 모든 영향 클러스터에 돌렸고, 2026-05-15 까지 의도하지 않은 설치와 변경을 모두 지웠다."}}],"action_items":[{"text":{"en":"Add a mandatory CI/CD step that confirms all required configuration files reached the target branch before any deployment starts","ko":"배포를 시작하기 전에 필요한 설정 파일이 모두 대상 브랜치에 전파되었는지 확인하는 필수 검증 단계를 CI/CD 파이프라인에 넣는다. 목표는 2026년 3분기다."}},{"text":{"en":"Require additional peer review and change management approval for every deployment that touches production, whatever its size","ko":"운영 시스템을 건드리는 모든 배포는 변경 크기와 상관없이 추가 동료 검토와 변경 관리 승인을 반드시 받게 한다. 이 절차는 기존 Change Approval Board 검토에 더해진다. 목표는 2026년 3분기다."}},{"text":{"en":"Give teams a way to inform each affected customer in time about the status of post-incident cleanup","ko":"장애 뒤 복구 작업의 진행 상황을 영향을 받은 고객마다 제때 알릴 수 있도록 장애 커뮤니케이션 절차를 고친다. 목표는 2026년 3분기다."}}],"contributing":["no-config-tests","blast-radius-too-wide","review-missed"],"recurrence_of":null,"symptoms_text":{"en":"On 8 May 2026 IONOS Cloud reported \"K8s Control Planes not available\": some Managed Kubernetes customers in DE/TXL, DE/FRA and DE/FRA/2 had trouble connecting to the control plane and saw degraded Kubernetes functionality. Between 15:22 and 16:12 (UTC+2) applications meant for a new internal development cluster were installed on other customer clusters, which were also modified.\n\nThe applications installed on the affected clusters could not run, because the image pull secrets they needed did not exist there, so no image could be pulled. The unscoped deployment looked normal to the team watching the rollout.","ko":"2026-05-08 15:15 UTC 에 상태 페이지에 공지가 올라왔다. 일부 고객이 컨트롤 플레인에 연결하지 못하고 쿠버네티스 기능이 떨어질 수 있다는 내용이었다. 영향을 받은 곳은 DE/TXL, DE/FRA, DE/FRA/2 의 Managed Kubernetes 였다.\n\n영향을 받은 클러스터에는 개발 클러스터용 애플리케이션이 설치되고 클러스터 구성이 바뀌어 있었다. 이 애플리케이션들은 그 환경에 필요한 image pull secret 이 없어 이미지를 받지도 실행하지도 못했다.\n\n15:52 UTC 에 쿠버네티스 엔지니어링 팀이 구성 필터링 방식의 결함을 원인으로 찾았다고 알렸다. 그 뒤 팀은 영향을 받은 리소스를 점검해 남은 잘못된 구성 변경이 모두 되돌려졌는지 확인했다."},"updated_at":"2026-11-14T05:53:45.307886Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0234","org_slug":"ionos-cloud"}