하나의 OTP로 Wi-Fi, VPN, 레지스트리를 감당할 수 없는 이유

통합 로그인은 하나의 신원과 더 적은 프롬프트를 약속하지만, 그 약속은 세 번째 프로토콜에서 깨집니다. 함정은 한 번의 성공한 인증이 다른 모든 프로토콜이 제시할 수 있는 토큰을 만든다고 가정하는 것입니다. Wi-Fi 입장, VPN 진입, 컨테이너 레지스트리는 각각 다른 교환을 수행하며, 대상과 수명이 다릅니다. 계정 공유는 디렉터리의 결정이고, 자격 증명 공유는 프로토콜의 결정이며, 프로토콜들은 좀처럼 합의하지 않습니다.

세 가지 교환, 세 명의 소유자

엔터프라이즈 Wi-Fi는 802.1X 안에서 EAP 방식을 실행하고, 보통 사용자나 기기에 대한 자체 시각을 가진 RADIUS 서비스가 이를 종료합니다. VPN 게이트웨이는 자체 지원 흐름으로 인증한 뒤 자체 재인증 타이머를 가진 세션을 유지합니다. 레지스트리는 인증되지 않은 요청에 토큰 서비스, 대상, 범위를 지목하는 챌린지로 응답하고, 클라이언트는 자격 증명을 단명 토큰과 교환합니다.

이것은 한 세션의 세 가지 관점이 아닙니다. 각각 고유한 검증자와 고유한 수명, 고유한 폐기 경로를 가지므로 디렉터리에서 비밀번호를 바꾸면 하나는 계속 작동하고 다른 하나는 깨질 수 있습니다. 이들을 우연히 사용자 디렉터리를 공유하는 세 가지 통합으로 다루십시오.

브라우저 SSO가 나르는 것과 나르지 않는 것

ID 공급자에서의 브라우저 세션은 그곳으로 리디렉션하는 애플리케이션이 사용자가 이미 마친 로그인을 물려받는다는 점에서 정말 유용합니다. 그것이 작동하는 이유는 그 애플리케이션들이 같은 리디렉션 및 토큰 프로토콜을 말하고 같은 대상을 받아들이기 때문입니다. EAP를 말하는 서플리컨트에는 따라갈 리디렉션이 없고, 레지스트리 챌린지를 받는 Docker 클라이언트는 OIDC ID 토큰을 요구하지 않습니다. ID 공급자는 자신이 말하도록 만들어진 프로토콜만 보증할 수 있습니다.

어디를 봐야 할지 알면 로그에서 실패를 쉽게 볼 수 있습니다. ID 공급자는 로그인 성공을 보고하지만 Wi-Fi 연결은 여전히 실패하거나, 브라우저가 본 적 없는 토큰 교환 뒤에 레지스트리가 401을 반환합니다. 두 번의 성공과 한 번의 실패는 모순이 아니라 세 개의 별개 인증입니다.

인증서가 반복되는 코드를 대신하는 지점

관리되는 기기에서는 인증서 기반 EAP가 신원을 없애지 않고 사람의 단계를 없앱니다. 기기가 인증서를 제시하고 RADIUS 서비스가 발급 기관에 대해 이를 검증하며 폐기는 공유 비밀이 아니라 그 기관에서 일어나므로, 그 대가는 만료 전에 갱신해야 하는 인증서의 수명주기 작업입니다.

레지스트리에도 상응하는 분할이 있습니다. 대화형 사용자는 한 번 로그인해 자격 증명 도우미가 결과 토큰을 저장하게 할 수 있고, 자동화는 범위를 좁힌 서비스 자격 증명이나 워크로드 신원을 사용해야 합니다. 어느 쪽도 사람의 일회용 코드를 파이프라인에 복사한 것이어서는 안 됩니다. 도우미는 특정 레지스트리 대상용 토큰을 저장하므로 구성 파일을 편집해 VPN 게이트웨이로 돌려놓을 수 없습니다.

docker login registry.example.com

프롬프트 수가 아니라 유지 비용을 비교하십시오

공유 자격 증명은 실패할 때까지 작업이 보이지 않기 때문에 싸 보입니다. 대신 등록, 갱신, 폐기, 유출의 영향 반경, 그리고 누군가 떠날 때 건드리는 시스템 수라는 항목으로 각 선택이 일 년 동안 무엇을 치르는지 세어 보십시오. 인증서 함대는 구축에 더 들고 규모에서 운영에는 덜 들지만, 복사한 코드는 시작에 아무것도 들지 않고 풀어내는 데 모든 것을 씁니다.

그런 다음 전역이 아니라 구간별로 선택하십시오. Wi-Fi는 인증서로 옮길 수 있고, VPN은 MFA가 붙은 지원 SSO를 유지할 수 있으며, 레지스트리는 명시적 범위를 가진 토큰을 쓸 수 있습니다. 각각의 소유자, 대상, 범위, 만료, 폐기 경로를 기록하면 프롬프트는 한꺼번에 모든 곳이 아니라 있어야 할 곳에 떨어집니다. 그 기록은 감사자가 어느 시스템이 아직 비밀번호를 신뢰하는지 물을 때의 답이기도 합니다.