당신은 Teleport를 사용하여 Azure의 CLI 도구에 대한 액세스를 관리할 수 있습니다. 이를 통해 인프라 자체를 보호하는 데 사용하는 것과 동일한 RBAC 시스템을 사용하여 인프라의 관리 API에 대한 액세스를 제어할 수 있습니다.
이 가이드에서는 다음을 수행합니다:
- 애플리케이션 서비스에 대한 Azure 관리 ID를 생성하고 이를 Kubernetes 서비스 계정의 기본 Workload ID로 설정합니다.
- 사용자 액세스를 위한 Azure 관리 ID를 생성하고 이를 동일한 Kubernetes 서비스 계정에 연결합니다.
- Teleport 클러스터에서 Azure 앱과 함께 Teleport 애플리케이션 서비스를 배포합니다.
- 관리 ID를 가정하고
az
명령어를tsh
를 통해 실행합니다.
작동 원리
Teleport Application Service는 in an AKS pod에 설치되어 있으며, Microsoft Entra Workload ID을 사용하여 Azure에서 인증 토큰을 얻습니다. 사용자가 Teleport에 인증하면, Azure CLI 명령을 실행하기 위해 각각의 사용자 할당 관리 ID 중 하나를 수임할 수 있습니다.
어떤 Teleport 사용자 또는 역할이 특정 Azure ID에 접근할 수 있는지를 구성할 수 있으며, 이를 통해 Azure CLI의 다양한 접근 수준에 대한 자격 증명을 얻을 수 있는 사람을 제어할 수 있습니다. Teleport Application Service는 역 터널을 통해 Teleport Proxy Service에 연결되므로, 애플리케이션 서비스를 개인 네트워크에서 실행하고 조직의 Azure ID에 대한 무단 접근을 방지할 수 있습니다.
전제 조건
-
실행 중인 Teleport 클러스터 버전 15.2.4 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.
-
tctl
관리 도구와tsh
클라이언트 도구.tctl
과tsh
다운로드에 대한 지침은 설치를 방문하세요.
- Azure Kubernetes Service (AKS) 클러스터와 클러스터를 관리할 수 있는 관리자 권한이 필요합니다.
- 사용자 할당 Azure 관리 ID, 역할 정책 및 연합 ID 자격 증명을 관리할 수 있는 능력이 필요합니다.
- 작업 공간에
az
CLI 도구가 설치되어 있어야 합니다. AKS 클러스터를 구성하고 관리 ID를 생성하기 위해 Azure 관리자 계정으로 로그인해야 합니다. Teleport의tsh
클라이언트도az
바이너리를 사용하여 명령을 실행합니다.az
CLI를 운영 체제에 설치하는 방법은 Azure 문서를 참조하세요. - AKS 배포를 위한
kubectl
및helm
이 필요합니다. - 당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면,
tsh login
으로 로그인한 다음 현재 자격 증명을 사용하여tctl
명령어를 실행할 수 있는지 확인하십시오. 예를 들어:클러스터에 연결하고tsh login --proxy=teleport.example.com --user=email@example.comtctl status클러스터 teleport.example.com
버전 16.2.0
CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
tctl status
명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속tctl
명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로tctl
명령어를 실행할 수도 있습니다.
1단계/6. Teleport 애플리케이션 서비스용 Azure 관리 ID 생성
Teleport 애플리케이션 서비스는 사용자 액세스를 위한 관리 ID의 클라이언트 ID를 검색할 수 있는 관리 ID가 필요합니다. 이 관리 ID는 Kubernetes 서비스 계정의 기본 ID로 할당됩니다.
아직 Azure 관리자 계정으로 로그인하지 않았다면 az login
명령어를 사용하여 로그인하고, 이후 단계에 필요한 환경 변수를 준비합니다:
export SUBSCRIPTION="$(az account show --query id --output tsv)"export LOCATION="eastus"export RESOURCE_GROUP="myResourceGroup"export AKS_CLUSTER_NAME="myASKCluster"export USER_ASSIGNED_IDENTITY_NAME="teleport-azure-cli-aks-agent"
이제 관리 ID를 생성하고, 나중에 사용할 클라이언트 ID를 기억합니다:
az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -o tsv)"
다음으로 Microsoft.ManagedIdentity/userAssignedIdentities/read
권한을 가진 역할을 생성하고 이를 관리 ID에 할당합니다:
cat > ${USER_ASSIGNED_IDENTITY_NAME}-role.json <<EOF{ "Name": "${USER_ASSIGNED_IDENTITY_NAME}-role", "Description": "AKS에서 Teleport Azure CLI 접근을 위한 역할", "AssignableScopes": [ "/subscriptions/${SUBSCRIPTION}" ], "Actions": [ "Microsoft.ManagedIdentity/userAssignedIdentities/read" ], "notActions": []}EOFaz role definition create --role-definition ./${USER_ASSIGNED_IDENTITY_NAME}-role.jsonaz role assignment create --role "${USER_ASSIGNED_IDENTITY_NAME}-role" --scope "/subscriptions/${SUBSCRIPTION}" --assignee-object-id $(az identity show --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --query principalId --output tsv) --assignee-principal-type ServicePrincipal
2단계/6. Workload ID에 대해 AKS 클러스터 구성
Microsoft Entra Workload ID를 사용하려면 AKS 클러스터에서 OIDC 발급자 및 Workload ID를 활성화해야 합니다.
az aks update -g "${RESOURCE_GROUP}" -n "{AKS_CLUSTER_NAME}" --enable-oidc-issuer --enable-workload-identity
kubectl
를 사용하기 전에 로컬 Kubernetes 구성이 업데이트되어 AKS 클러스터에 대한 액세스가 허용되도록 합니다:
az aks get-credentials -n "${AKS_CLUSTER_NAME}" -g "${RESOURCE_GROUP}"
Kubernetes 서비스 계정을 생성하고 이전 단계에서 생성한 관리 ID의 클라이언트 ID로 주석을 추가합니다:
cat > azure_access_aks_service_account.yaml <<EOFapiVersion: v1kind: ServiceAccountmetadata: annotations: azure.workload.identity/client-id: "${USER_ASSIGNED_CLIENT_ID}" name: "teleport-azure-cli-aks-service-account" namespace: "teleport-ns"EOFkubectl apply -f azure_access_aks_service_account.yaml
이제 이전 단계에서 생성한 관리 ID와 Kubernetes 서비스 계정을 연관시키기 위해 연합 자격 증명을 생성합니다:
export AKS_OIDC_ISSUER="$(az aks show -n "${AKS_CLUSTER_NAME}" -g "${RESOURCE_GROUP}" --query "oidcIssuerProfile.issuerUrl" -o tsv)"az identity federated-credential create --name "federated-${USER_ASSIGNED_IDENTITY_NAME}" --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:teleport-ns:teleport-azure-cli-aks-service-account --audience api://AzureADTokenExchange
3단계/6. 사용자 액세스를 위한 Azure 관리 ID 생성
이번 단계에서는 Teleport 사용자가 나중에 tsh
를 사용해 가정할 수 있는 사용자 할당 관리 ID를 생성하고 이 관리 ID를 Kubernetes 서비스 계정과 연관시킵니다.
사용자 액세스를 위해 사용하려는 다른 관리 ID가 있는 경우, 새로운 ID 생성 단계를 건너뛸 수 있습니다.
Azure 관리 ID 생성
az
를 사용하여 관리 ID를 생성합니다:
az identity create --name "teleport-reader" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"
관리 ID의 리소스 ID URI를 기억해 두십시오. 이는 Teleport 역할 또는 사용자 특성에 필요합니다:
az identity show --name "teleport-reader" -g "${RESOURCE_GROUP}" --query id -o tsv
다음으로 Teleport 사용자에게 부여하고자 하는 원하는 권한을 관리 ID에 할당합니다. 이 예시에서는 "Reader" 역할이 관리 ID에 할당됩니다:
az role assignment create --role "Reader" --scope "/subscriptions/${SUBSCRIPTION}" --assignee-object-id $(az identity show --name "teleport-reader" --resource-group "${RESOURCE_GROUP}" --query principalId --output tsv) --assignee-principal-type ServicePrincipal
관리 ID를 Kubernetes 서비스 계정과 연관시키기
Kubernetes 서비스 계정에는 여러 개의 관리 ID를 할당할 수 있습니다. 이전 단계에서 애플리케이션 서비스용 관리 ID가 서비스 계정에 할당되었습니다. 이제 사용자 액세스용 관리 ID에 대해서도 동일하게 반복합니다:
export AKS_OIDC_ISSUER="$(az aks show -n "${AKS_CLUSTER_NAME}" -g "${RESOURCE_GROUP}" --query "oidcIssuerProfile.issuerUrl" -o tsv)"az identity federated-credential create --name "federated-teleport-reader" --identity-name "teleport-reader" --resource-group "${RESOURCE_GROUP}" --issuer "${AKS_OIDC_ISSUER}" --subject system:serviceaccount:teleport-ns:teleport-azure-cli-aks-service-account --audience api://AzureADTokenExchange
4단계/6. 사용자가 Azure CLIs에 액세스할 수 있도록 설정
다음 단계는 Teleport 사용자가 Azure ID를 가정하고 Teleport를 통해 Azure CLI 명령을 실행할 수 있도록 권한을 부여하는 것입니다. 사용자의 역할이 어떤 Azure 관리 ID에 접근할 수 있는지 결정하는 Teleport의 RBAC 시스템을 사용하여 이 ID에 대한 접근을 보호합니다.
Azure ID에 접근할 수 있도록 사용자를 권한 부여하는 두 가지 접근 방식이 있습니다.
접근 방식 | 설명 | 지원되는 사용자 유형 |
---|---|---|
Dynamic | Teleport 역할에 사용자가 직접 할당된 모든 Azure ID에 접근할 수 있는 템플릿 변수가 포함됩니다. | 로컬 사용자, OIDC, SAML |
Static | Teleport 역할이 사용자가 가정할 수 있는 Azure ID를 명시적으로 지정합니다. | 로컬 사용자, OIDC, SAML, GitHub |
Azure ID를 계정에 추가할 때 잘 확장되는 동적 접근 방식을 사용하는 것이 좋습니다. GitHub SSO를 사용하여 사용자를 인증하도록 Teleport Community Edition 클러스터를 구성한 경우, OAuth 기반 GitHub 애플리케이션이 사용자 지정 클레임을 지원하지 않기 때문에 정적 접근 방식을 사용해야 합니다.
접근 방식
- Dynamic Identities
- Static Identities
azure-cli-access.yaml
이라는 파일을 생성하고 다음 내용을 입력합니다:
kind: role
version: v5
metadata:
name: azure-cli-access
spec:
allow:
app_labels:
'*': '*'
azure_identities:
- '{{internal.azure_identities}}'
azure-cli-access
역할을 가진 사용자가 Teleport를 통해 Azure CLI에 인증하면, Teleport Auth 서비스는 사용자가 할당된 모든 Azure ID로 {{internal.azure_identities}}
템플릿 변수를 채웁니다.
다음 명령어를 실행하여 Teleport 사용자에게 teleport-azure
ID를 할당합니다. 이전에 복사한 Azure ID의 URI를 --set-azure-identities
의 값으로 붙여넣습니다:
tctl users update teleport-user \--set-azure-identities azure-identity-uri
이 명령은 --set-azure-identities
플래그를 사용하여 사용자에게 Azure ID를 추가합니다. 쉼표로 구분하여 여러 ID URI를 --set-azure-identities
에 지정할 수 있습니다.
ID URI는 다음 형식의 Azure 리소스 ID입니다:
/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/RESOURCE_GROUP_NAME/providers/Microsoft.ManagedIdentity/userAssignedIdentities/IDENTITY_NAME
역할을 생성합니다:
tctl create -f azure-cli-access.yaml
신원 제공자에서 azure_identities
라는 사용자 지정 SAML 속성 또는 OIDC 클레임을 정의합니다. 각 사용자의 azure_identities
속성 또는 클레임은 다음 형식을 사용하는 Azure ID URI 목록이어야 합니다:
/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/RESOURCE_GROUP_NAME/providers/Microsoft.ManagedIdentity/userAssignedIdentities/IDENTITY_NAME
azure-cli-access.yaml
이라는 파일을 생성하고 다음 내용을 입력합니다:
kind: role
version: v5
metadata:
name: azure-cli-access
spec:
allow:
app_labels:
'*': '*'
azure_identities:
- '{{external.azure_identities}}'
azure-cli-access
역할을 가진 사용자가 Teleport를 통해 Azure CLI에 인증하면, Teleport Auth 서비스는 사용자가 할당된 모든 Azure ID로 {{external.azure_identities}}
템플릿 변수를 채웁니다.
역할을 생성합니다:
tctl create -f azure-cli-access.yaml
특정 Azure ID에 접근할 수 있는 역할을 정의합니다. 이는 Teleport 사용자가 이 역할을 가정할 수 있으며, 이를 통해 명령을 Azure CLI를 통해 실행할 수 있게 하는 것입니다.
azure-cli-access.yaml
이라는 파일을 생성하고 다음 내용을 입력합니다:
kind: role
version: v5
metadata:
name: azure-cli-access
spec:
allow:
app_labels:
'*': '*'
azure_identities:
- /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/teleport-azure
1단계에서 복사한 ID URI에 맞게 azure_identities
필드를 수정합니다.
이 역할은 사용자가 이전에 정의한 azure-cli
애플리케이션과 같은 Teleport 등록 애플리케이션에 접근할 수 있도록 하며, 사용자가 이전에 생성한 teleport-azure
ID를 가정할 수 있도록 합니다.
역할을 생성합니다:
tctl create -f azure-cli-access.yaml
Azure ID에 대한 접근을 거부하는 Teleport 역할을 정의할 수 있습니다. 그렇게 하려면 role
리소스의 spec.deny
섹션 내에서 azure_identities
필드에 값을 할당합니다.
예를 들어, 이 역할은 사용자가 모든 Azure ID에 접근하는 것을 거부합니다:
kind: role
version: v5
metadata:
name: "no-azure-identities"
spec:
allow:
app_labels:
'*': '*'
deny:
azure_identities:
- '*'
no-azure-identities
역할은 사용자가 모든 등록된 애플리케이션에 접근할 수 있도록 하지만, deny.azure_identities
필드 내에 와일드카드 문자(*
)를 사용하여 사용자가 어떤 Azure ID도 가정하는 것을 방지합니다.
allow.azure_identities
의 값과는 달리, deny.azure_identities
의 값은 특정 Azure ID URI 외에도 와일드카드 표현식을 포함할 수 있습니다.
Teleport Auth 서비스는 사용자의 역할을 평가할 때 deny
규칙을 allow
규칙보다 우선시합니다.
azure-cli-access
역할을 Teleport 사용자에게 할당하려면 인증 제공자에 맞는 적절한 명령어를 실행하세요:
-
로컬 사용자의 역할을 콤마로 구분된 목록으로 가져옵니다:
ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")') -
로컬 사용자를 편집하여 새로운 역할을 추가합니다:
tctl users update $(tsh status -f json | jq -r '.active.username') \ --set-roles "${ROLES?},azure-cli-access" -
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.
-
github
인증 커넥터를 가져옵니다:tctl get github/github --with-secrets > github.yaml--with-secrets
플래그는spec.signing_key_pair.private_key
의 값을github.yaml
파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시github.yaml
파일을 제거해야 합니다. -
github.yaml
을 편집하고teams_to_roles
섹션에azure-cli-access
을 추가합니다.이 역할에 매핑할 팀은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 하지만 팀에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 팀이어야 합니다.
여기에 예시가 있습니다:
teams_to_roles: - organization: octocats team: admins roles: - access + - azure-cli-access
-
변경 사항을 적용합니다:
tctl create -f github.yaml -
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 assum 하기 위해 다시 로그인합니다.
-
saml
구성 리소스를 가져옵니다:tctl get --with-secrets saml/mysaml > saml.yaml--with-secrets
플래그는spec.signing_key_pair.private_key
의 값을saml.yaml
파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시saml.yaml
파일을 제거해야 합니다. -
saml.yaml
을 편집하고attributes_to_roles
섹션에azure-cli-access
을 추가합니다.이 역할에 매핑할 속성은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.
여기에 예시가 있습니다:
attributes_to_roles: - name: "groups" value: "my-group" roles: - access + - azure-cli-access
-
변경 사항을 적용합니다:
tctl create -f saml.yaml -
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.
-
oidc
구성 리소스를 가져옵니다:tctl get oidc/myoidc --with-secrets > oidc.yaml--with-secrets
플래그는spec.signing_key_pair.private_key
의 값을oidc.yaml
파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시oidc.yaml
파일을 제거해야 합니다. -
oidc.yaml
을 편집하고claims_to_roles
섹션에azure-cli-access
을 추가합니다.이 역할에 매핑할 클레임은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.
여기에 예시가 있습니다:
claims_to_roles: - name: "groups" value: "my-group" roles: - access + - azure-cli-access
-
변경 사항을 적용합니다:
tctl create -f oidc.yaml -
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.
5단계/6. Teleport 애플리케이션 서비스 배포
이번 단계에서는 AKS 클러스터에 Teleport 애플리케이션 서비스를 배포합니다.
참여 토큰 가져오기
Teleport 클러스터와 새 애플리케이션 서비스 인스턴스 간에 신뢰를 구축하기 위해 참여 토큰을 생성합니다:
tctl tokens add --type=app --ttl=1h --format=textabcd123-insecure-do-not-use-this
Teleport 애플리케이션 서비스 시작하기
values.yaml
이라는 Helm 값 파일을 생성하여 위에서 가져온 참여 토큰의 값으로 token을 할당하고, Teleport 프록시 서비스의 호스트 및 포트로 example.teleport.sh:443을 할당합니다 (예: teleport.example.com:443
):
cat > azure_access_agent.values.yaml <<EOFauthToken: tokenproxyAddr: example.teleport.sh:443roles: appapps: - name: "azure-cli" cloud: "Azure" uri: "cloud://Azure"serviceAccount: create: false name: teleport-azure-cli-aks-service-account
extraLabels: pod: azure.workload.identity/use: "true"EOF
Teleport 에이전트 서비스에 대한 Helm 차트를 설치합니다, teleport-kube-agent
:
helm -n teleport-ns install teleport-azure-access-agent \ teleport/teleport-kube-agent --values azure_access_agent.values.yaml
Teleport 에이전트 포드가 실행 중인지 확인합니다. 단일 준비 컨테이너가 있는 하나의 teleport-azure-access-agent
포드를 볼 수 있어야 합니다:
kubectl -n teleport-ns get podsNAME READY STATUS RESTARTS AGEteleport-azure-access-agent-0 1/1 Running 0 99s
6단계/6. Teleport로 Azure CLIs 사용하기
이제 Teleport 사용자가 teleport-azure
아이덴티티를 가져올 수 있도록 권한을 부여했으므로, Teleport를 사용하여 Azure의 API에 인증하고 az
CLI를 통해 명령을 실행할 수 있습니다.
Azure CLI 애플리케이션 목록 보기
Teleport 사용자가 이전에 등록한 azure-cli
애플리케이션을 볼 수 있는지 확인하세요:
tsh apps lsApplication Description Type Public Address Labels----------- ----------- ---- ------------------------------ -------------------azure-cli HTTP azure-cli.teleport.example.com teleport.dev/origin
Azure CLI 사용을 위해 로그인하기
애플리케이션에 로그인하고, teleport-azure
아이덴티티를 가져오겠다고 지정하세요:
tsh apps login azure-cli --azure-identity teleport-azure
이 명령은 --azure-identity
플래그의 값을 사용자가 가져올 수 있는 값과 비교하여 유효성을 검사합니다. 플래그의 값은 아이덴티티의 전체 URI(예: 이 가이드에서 이전에 복사한 URI) 또는 아이덴티티의 이름(예: teleport-azure
)일 수 있습니다.
사용자가 단일 Azure 아이덴티티에만 접근할 수 있는 권한이 있는 경우, --azure-identity
플래그를 생략할 수 있지만, 그렇지 않으면 --azure-identity
플래그를 포함하지 않으면 오류가 발생합니다. 명령이 성공하면 다음과 유사한 사용자가 선택한 Azure 아이덴티티에 대한 정보가 표시됩니다:
[
{
"environmentName": "AzureCloud",
"homeTenantId": "00000000-0000-0000-0000-000000000000",
"id": "00000000-0000-0000-0000-000000000000",
"isDefault": true,
"managedByTenants": [],
"name": "Microsoft Azure Sponsorship",
"state": "Enabled",
"tenantId": "00000000-0000-0000-0000-000000000000",
"user": {
"assignedIdentityInfo": "MSIResource-/subscriptions/0000000000000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/teleport-azure",
"name": "userAssignedIdentity",
"type": "servicePrincipal"
}
}
]
Azure 애플리케이션 "azure-cli"에 로그인했습니다.
당신의 아이덴티티: /subscriptions/0000000000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/teleport-azure
예제 Azure CLI 명령: tsh az vm list
Azure CLI 명령 실행하기
이제 Teleport 애플리케이션 서비스를 사용하여 az
명령을 실행할 수 있으며, tsh
로 접두사를 붙여 실행합니다. 예를 들어, Azure 리소스 그룹에서 실행 중인 VM 목록을 보려면 다음 명령을 실행하세요:
tsh az vm list
이 시점에서 예상되는 VM이 보이지 않는 경우, Azure 관리 아이덴티티가 리소스 그룹의 범위에서 "Reader" 역할이 할당되어 있는지 다시 확인하세요.
tsh
없이 Azure CLI 애플리케이션 사용하기
tsh
를 통해 az
명령을 실행하는 것 외에도, Azure API에 대해 명령을 실행하는 모든 CLI 애플리케이션에 안전하게 접근할 수 있습니다.
이를 위해, tsh
를 사용하여 CLI 애플리케이션의 트래픽을 Teleport 애플리케이션 서비스로 포워딩하는 로컬 프록시를 시작합니다. 애플리케이션 서비스는 Azure 관리 아이덴티티를 사용하여 Azure에서 인증 토큰을 가져오고, 이 토큰을 사용하여 CLI 애플리케이션이 Azure API에 인증 요청을 수행합니다.
로컬 프록시를 시작하려면 다음 tsh
명령을 실행하세요:
tsh proxy azure
tsh proxy az
명령은 tsh proxy azure
의 별칭입니다.
이 명령은 로컬 프록시 서버의 주소와 환경 변수를 할당하기 위한 export
명령을 출력합니다. Azure CLI 애플리케이션은 이러한 변수를 읽어 Azure API의 인증 토큰을 요청합니다:
http://127.0.0.1:54321에서 Azure 프록시가 시작되었습니다.
포트 랜덤화를 피하려면 --port 플래그를 사용하여 리스닝 포트를 선택할 수 있습니다.
프록시에 연결하려면 다음 자격 증명 및 HTTPS 프록시 설정을 사용하세요:
export AZURE_CONFIG_DIR=/Users/myuser/.tsh/azure/my.teleport.cluster/azure
export HTTPS_PROXY=http://127.0.0.1:54321
export HTTP_PROXY=http://127.0.0.1:54321
export MSI_ENDPOINT=https://azure-msi.teleport.dev/123456789abcdef01234
export REQUESTS_CA_BUNDLE=/Users/myuser/.tsh/keys/teleport.example.com/myuser-app/teleport.example.com/azure-cli-localca.pem
tsh proxy azure
는 로컬 프록시를 포그라운드에서 실행하므로, 로컬 프록시를 닫을 준비가 될 때까지 명령을 중단하거나 명령을 실행한 터미널을 종료하지 마세요.
export
명령을 복사하여 두 번째 터미널에 붙여넣습니다. 그 터미널에서 이제 선택한 Azure CLI 애플리케이션을 실행할 수 있습니다. 예를 들어, 다음 명령을 실행하여 Azure VM 목록을 나열할 수 있습니다:
az vm list
az
CLI는 이전에 생성한 teleport-azure
아이덴티티를 사용하여 인증 토큰을 요청하고, 해당 아이덴티티가 리소스 그룹의 리소스를 볼 수 있는 권한이 있기 때문에, az vm list
명령은 해당 리소스 그룹의 VM만 나열합니다.
tsh az
를 통해 명령을 실행할 때, tsh
는 로컬 프록시를 백그라운드에서 시작하고 이를 사용하여 명령을 실행합니다.
다음 단계
- Microsoft의 AKS에서 Workload ID 구성하기 가이드를 참조하세요.
- Teleport를 사용하여 Azure CLI 액세스를 보호하는 방법을 알게 되었으므로, Teleport 사용자가 악의적인 공격자가 장악할 수 있는 영구 관리자 역할 없이 Azure 리소스를 일시적으로만 관리할 수 있도록 하세요. 역할 접근 요청 및 접근 요청 플러그인에 대한 문서를 확인하세요.
- Azure 관리 ID에 대한 정보와 사용자 할당 관리 ID 관리 방법에 대한 정보는 Azure 문서를 참조하세요.
- 전체
az
CLI 명령 목록은 Azure 문서를 참조하세요. - 이 가이드 내의 Teleport 역할에 설명된 대로 Teleport가
internal
및external
특성을 채우는 방법에 대한 자세한 내용은 Teleport 접근 제어 참조를 참조하세요.