변경사항을 프로덕션으로 프로모션하기 전에 자동화를 사용하여 인증 프록시 버전을 업데이트하고 비프로덕션 환경에서 새 버전을 테스트합니다.
인증 프록시 클라이언트를 영구 서비스 또는 사이드카로 실행
프로덕션에서는 인증 프록시 클라이언트를 영구 서비스 또는 사이드카로 실행해야 합니다.
인증 프록시 클라이언트 프로세스가 중지되면 이를 통한 기존 연결이 모두 끊어지고 애플리케이션에서 AlloyDB 인증 프록시를 사용하여 AlloyDB 인스턴스로의 연결을 더 이상 만들 수 없게 됩니다. 이를 방지하려면 인증 프록시 클라이언트를 영구 서비스로 실행하여 어떤 이유로든 인증 프록시 클라이언트가 종료되어도 자동으로 다시 시작되도록 합니다.
클라이언트를 실행하는 위치에 따라 다음 옵션을 사용합니다.
Linux VM에서 실행되는 인증 프록시 클라이언트의 경우 systemd, upstart 또는 supervisor와 같은 서비스를 사용합니다.
Windows 워크로드의 경우 인증 프록시 클라이언트를 Windows 서비스로 실행합니다. 자세한 내용은 Windows 서비스 가이드를 참고하세요.
Kubernetes 설정의 경우 인증 프록시 클라이언트를 사이드카로 실행합니다.
워크로드와 동일한 머신에서 인증 프록시 클라이언트 실행
인증 프록시 클라이언트는 워크로드와 동일한 머신에서 실행된다고 가정합니다.
인증 프록시로 전송되는 모든 클라이언트 트래픽은 암호화되지 않습니다. 인증 프록시에서 AlloyDB로 전송되는 트래픽은 mTLS를 사용하여 암호화됩니다.
암호화되지 않은 트래픽이 머신에서 나가지 않도록 인증 프록시의 모든 클라이언트가 동일한 머신에 있는지 확인합니다. AlloyDB 인증 프록시는 AlloyDB 인스턴스에 액세스하려는 클라이언트와 함께 배치되어야 합니다.
워크로드마다 고유한 서비스 계정 사용
AlloyDB 인증 프록시는 환경의 IAM 사용자를 사용하여 AlloyDB 인스턴스로 연결되는 보안 터널을 만듭니다. 최소 권한의 원칙을 따르려면 웹 앱 또는 백엔드 데이터 처리 앱과 같은 각 워크로드가 고유한 서비스 계정을 사용해야 합니다. 고유한 서비스 계정을 사용하면 각 워크로드의 권한을 별도로 관리 (또는 취소)할 수 있습니다.
AlloyDB 인증 프록시를 병목 현상으로 배포하지 않음
공유 VM에 AlloyDB 인증 프록시를 배포하고 이를 사용하여 여러 워크로드의 모든 트래픽을 AlloyDB 인스턴스로 라우팅하는 것이 좋을 수 있습니다.
그러나 이 접근 방식은 안전하지 않으며 단일 장애점을 만듭니다.
여러 클라이언트가 Auth Proxy에서 사용하는 것과 동일한 IAM 주 구성원을 사용하게 되므로 AlloyDB 인스턴스에 실제로 액세스하는 워크로드를 식별하기가 어려워져 이 접근 방식은 안전하지 않습니다.
이 접근 방식은 단일 장애점을 만듭니다. AlloyDB 인증 프록시가 트래픽 급증으로 인해 과부하되면 모든 클라이언트 연결에 부정적인 영향을 미치기 때문입니다.
대신 보안 연결이 필요한 각 머신에 Auth Proxy 클라이언트를 영구 서비스의 사이드카로 배포합니다.
프로덕션 배포의 AlloyDB 인증 프록시 로그 출력 줄이기
AlloyDB 인증 프록시 로그의 크기를 제한해야 하는 경우 AlloyDB 인증 프록시를 시작할 때 --verbose=false 옵션을 설정합니다. 이 옵션을 사용하면 연결 문제를 진단할 때 AlloyDB 인증 프록시 출력의 적합성이 떨어집니다.
AlloyDB 인증 프록시 도움말 메시지 읽기
AlloyDB 인증 프록시에는 많은 추가 기능이 포함되어 있으며 세부정보가 포함된 광범위한 도움말 메시지가 포함되어 있습니다. ./alloydb-auth-proxy --help 명령어를 실행하여 추가 구성 옵션을 확인합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eKeep the AlloyDB Auth Proxy client updated by automating the update process and testing new versions in non-production environments before deploying to production.\u003c/p\u003e\n"],["\u003cp\u003eRun the Auth Proxy client as a persistent service or sidecar to prevent connection drops and ensure automatic restarts in case of failure.\u003c/p\u003e\n"],["\u003cp\u003eDeploy the Auth Proxy client on the same machine as the workload to maintain security and prevent unencrypted traffic from leaving the machine.\u003c/p\u003e\n"],["\u003cp\u003eUse a distinct service account for each workload to adhere to the principle of least privilege and enable granular permission management.\u003c/p\u003e\n"],["\u003cp\u003eAvoid deploying the Auth Proxy as a bottleneck by deploying an Auth Proxy client on each machine requiring a secure connection, preventing a single point of failure and insecurity.\u003c/p\u003e\n"]]],[],null,["# Best practices for using the AlloyDB Auth Proxy\n\nThis page lists some best practices for using the AlloyDB Auth Proxy.\n\nKeep the Auth Proxy client up-to-date\n-------------------------------------\n\nGoogle releases new versions of the Auth Proxy monthly. You can find\nthe current version by checking the [AlloyDB Auth Proxy GitHub releases\npage](https://github.com/GoogleCloudPlatform/alloydb-auth-proxy/releases).\n\nUse automation to update the Auth Proxy version and test the new\nversion in non-production environments before promoting the change to\nproduction.\n\nRun the Auth Proxy client as a persistent service or sidecar\n------------------------------------------------------------\n\nIn production, you should run the Auth Proxy client as a persistent service\nor sidecar.\n\nIf the Auth Proxy client process is stopped,then all existing connections\nthrough it are dropped, and your application cannot create any more connections\nto the AlloyDB instance with the AlloyDB Auth Proxy. To prevent this\nscenario, run the Auth Proxy client as a persistent service, so that if the\nAuth Proxy client exits for any reason, it is automatically restarted.\n\nBased on where you are running the client, use the following options:\n\n- For Auth Proxy client running on Linux VMs, use a service such as `systemd`, `upstart`, or `supervisor`.\n- For Windows workloads, run the Auth Proxy client as a Windows Service. See the [Windows Service Guide](https://github.com/GoogleCloudPlatform/alloydb-auth-proxy/blob/main/windows-service-guide.md) for more information.\n- For Kubernetes setups, run the Auth Proxy client as a sidecar.\n\nRun the Auth Proxy client on the same machine as your workload\n--------------------------------------------------------------\n\nThe Auth Proxy client assumes it runs on the same machine as the workload.\nAny client traffic to the Auth Proxy will be unencrypted. Traffic from\nthe Auth Proxy to the AlloyDB is encrypted using mTLS.\n\nMake sure any client of the Auth Proxy is\nlocated on the same machine so that no unencrypted traffic leaves the\nmachine. The AlloyDB Auth Proxy should be co-located with a client\nthat wants to access your AlloyDB instance.\n\nUse a distinct service account for each workload\n------------------------------------------------\n\nThe AlloyDB Auth Proxy uses the environment's IAM principal to create a secure\ntunnel to an AlloyDB instance. To follow the principle of least\nprivilege, each workload, such as a web app or a backend data processing app,\nmust use a distinct service account. The use of distinct service account ensures\nthat each workload's permissions can be managed (or revoked) separately.\n\nDon't deploy the AlloyDB Auth Proxy as a bottleneck\n---------------------------------------------------\n\nIt may be tempting to deploy the AlloyDB Auth Proxy on a shared VM and use it to\nroute all traffic from a number of workloads to your AlloyDB instance.\nHowever, this approach is insecure and creates a single point of failure.\n\nAs multiple clients end up using the same IAM principal that\nAuth Proxy uses, identifying the workload that is actually accessing\nyour AlloyDB instance becomes difficult, making this approach\ninsecure.\n\nThis approach creates a single point of failure because if the AlloyDB Auth Proxy is\noverloaded with a burst of traffic, all client connections will be negatively\naffected.\n\nInstead, deploy an Auth Proxy client on each machine that needs a\nsecure connection either as a sidecar of persistent service.\n\nReduce AlloyDB Auth Proxy log output for production deployments\n---------------------------------------------------------------\n\nIf you need to limit the size of the AlloyDB Auth Proxy logs, then set the\n`--verbose=false` option when you start the AlloyDB Auth Proxy. Note that using this\noption reduces the effectiveness of the AlloyDB Auth Proxy output in diagnosing\nconnection issues.\n\nRead the AlloyDB Auth Proxy help message\n----------------------------------------\n\nThe AlloyDB Auth Proxy includes many additional features and includes an extensive\nhelp message with details. Run the `./alloydb-auth-proxy --help` command to\ndiscover additional configuration options.\n\nEngage with the development team on GitHub\n------------------------------------------\n\nIf you believe you have found a bug or have a feature request, then you may\nengage with the development team on [AlloyDB Auth Proxy's GitHub\nrepository](https://github.com/GoogleCloudPlatform/alloydb-auth-proxy)."]]
