이제 이전 단계에서 생성한 관리 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 역할 또는 사용자 트레이트(trait)에서 필요하므로 기억해 두세요:

$ 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를 할당할 수 있습니다. Application Service를 위한 관리 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 CLI에 접근하도록 활성화#

다음 단계는 Teleport 사용자가 Azure 자격 증명을 assume하고 Teleport를 통해 Azure CLI 명령을 실행하도록 권한을 부여하는 것입니다. Teleport의 RBAC 시스템을 사용하여 이 자격 증명에 대한 액세스를 보호하며, 사용자의 역할이 액세스할 수 있는 Azure 관리형 자격 증명(있는 경우)을 결정합니다.

사용자에게 Azure 자격 증명에 대한 액세스 권한을 부여하는 데는 두 가지 접근 방식이 있습니다.

Dynamic identities#

dynamic 접근 방식을 사용하는 경우, 선택하는 방식은 Teleport 사용자가 로컬 사용자인지 SSO 사용자인지에 따라 달라집니다:

Local Users

다음 내용으로 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 Service는 사용자에게 할당한 Azure 자격 증명으로 {{internal.azure_identities}} 템플릿 변수를 채웁니다.

다음 명령을 실행하여 Teleport 사용자에게 teleport-azure 자격 증명을 할당합니다. teleport-user를 Teleport 사용자 이름으로 지정하고 앞서 복사한 Azure 자격 증명의 URI를 azure-identity-uri 값으로 붙여넣습니다:

$ tctl users update teleport-user \
--set-azure-identities azure-identity-uri

이 명령은 --set-azure-identities 플래그를 사용하여 사용자에게 Azure 자격 증명을 추가합니다. --set-azure-identities에는 쉼표로 구분된 여러 자격 증명 URI를 할당할 수 있습니다.

자격 증명 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

SAML/OIDC Connectors

ID 공급자에서 azure_identities라는 사용자 지정 SAML 속성 또는 OIDC 클레임을 정의합니다. 각 사용자의 azure_identities 속성 또는 클레임은 다음 형식을 사용하는 Azure 자격 증명 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 Service는 사용자에게 할당한 Azure 자격 증명으로 {{external.azure_identities}} 템플릿 변수를 채웁니다.

역할을 생성합니다:

$ tctl create -f azure-cli-access.yaml

Static identities#

static 자격 증명을 사용하는 경우, 특정 Azure 자격 증명에 대한 액세스 권한을 가진 역할을 정의합니다. 이는 이 역할을 assume하는 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

azure_identities 필드의 자격 증명 URI를 Step 1에서 복사한 것과 일치하도록 편집합니다.

이 역할은 사용자에게 앞서 정의한 azure-cli 애플리케이션과 같이 Teleport에 등록된 모든 애플리케이션에 대한 액세스 권한을 부여하고, 해당 사용자가 앞서 생성한 teleport-azure 자격 증명을 assume할 수 있도록 허용합니다.

역할을 생성합니다:

$ tctl create -f azure-cli-access.yaml

kind: role
version: v5
metadata:
  name: "no-azure-identities"
spec:
  allow:
    app_labels:
      '*': '*'
  deny:
    azure_identities:
      - '*'

인증 공급자에 맞는 적절한 명령을 실행하여 azure-cli-access 역할을 your Teleport user에게 할당하십시오:

Local User

1. 로컬 사용자의 역할을 쉼표로 구분된 목록으로 가져옵니다:

   $ ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")')
   

2. 로컬 사용자를 편집하여 새 역할을 추가합니다:

   $ tctl users update $(tsh status -f json | jq -r '.active.username') \
     --set-roles "${ROLES?},azure-cli-access"
   

3. Teleport 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

GitHub

1. 텍스트 편집기에서 github 인증 커넥터를 엽니다:

   $ tctl edit github/github
   

2. github 커넥터를 편집하여 teams_to_roles 섹션에 azure-cli-access을 추가합니다.

   이 역할에 매핑해야 할 팀은 조직의 역할 기반 액세스 제어(RBAC)를 어떻게 설계했는지에 따라 달라집니다. 다만, 해당 팀은 여러분의 사용자 계정을 포함해야 하며 조직 내에서 가능한 한 가장 작은 팀이어야 합니다.

   다음은 예시입니다:

     teams_to_roles:
       - organization: octocats
         team: admins
         roles:
           - access
   +       - azure-cli-access
   

3. 편집기에서 파일을 저장하고 닫아 변경 사항을 적용합니다.

4. Teleport 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

SAML

1. saml 구성 리소스를 가져옵니다:

   $ tctl get --with-secrets saml/mysaml > saml.yaml
   

   --with-secrets 플래그는 spec.signing_key_pair.private_key 값을 saml.yaml 파일에 추가한다는 점에 유의하십시오. 이 키에는 민감한 값이 포함되어 있으므로, 리소스를 업데이트한 직후 saml.yaml 파일을 삭제해야 합니다.

2. saml.yaml을 편집하여 attributes_to_roles 섹션에 azure-cli-access을 추가합니다.

   이 역할에 매핑해야 할 속성은 조직의 역할 기반 액세스 제어(RBAC)를 어떻게 설계했는지에 따라 달라집니다. 다만, 해당 그룹은 여러분의 사용자 계정을 포함해야 하며 조직 내에서 가능한 한 가장 작은 그룹이어야 합니다.

   다음은 예시입니다:

     attributes_to_roles:
       - name: "groups"
         value: "my-group"
         roles:
           - access
   +       - azure-cli-access
   

3. 변경 사항을 적용합니다:

   $ tctl create -f saml.yaml
   

4. Teleport 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

OIDC

1. oidc 구성 리소스를 가져옵니다:

   $ tctl get oidc/myoidc --with-secrets > oidc.yaml
   

   --with-secrets 플래그는 spec.signing_key_pair.private_key 값을 oidc.yaml 파일에 추가한다는 점에 유의하십시오. 이 키에는 민감한 값이 포함되어 있으므로, 리소스를 업데이트한 직후 oidc.yaml 파일을 삭제해야 합니다.

2. oidc.yaml을 편집하여 claims_to_roles 섹션에 azure-cli-access을 추가합니다.

   이 역할에 매핑해야 할 클레임은 조직의 역할 기반 액세스 제어(RBAC)를 어떻게 설계했는지에 따라 달라집니다. 다만, 해당 그룹은 여러분의 사용자 계정을 포함해야 하며 조직 내에서 가능한 한 가장 작은 그룹이어야 합니다.

   다음은 예시입니다:

     claims_to_roles:
       - name: "groups"
         value: "my-group"
         roles:
           - access
   +       - azure-cli-access
   

3. 변경 사항을 적용합니다:

   $ tctl create -f oidc.yaml
   

4. Teleport 클러스터에서 로그아웃한 다음 다시 로그인하여 새 역할을 적용합니다.

5/6단계. Teleport Application Service 배포#

이 단계에서는 AKS 클러스터에서 Teleport Application Service를 실행합니다.

조인 토큰 받기#

조인 토큰을 생성하여 Teleport 클러스터와 새 Application Service 인스턴스 간에 신뢰를 구축합니다:

$ tctl tokens add --type=app --ttl=1h --format=text
(=presets.tokens.first=)

Teleport Application Service 시작#

values.yaml이라는 Helm values 파일을 생성하고, token에 위에서 받은 조인 토큰의 값을, example.teleport.sh:443에 Teleport Proxy Service의 호스트 및 포트(예: teleport.example.com:443)를 지정합니다:

$ cat > azure_access_agent.values.yaml <

$ helm -n teleport-ns install teleport-azure-access-agent \
  teleport/teleport-kube-agent --values azure_access_agent.values.yaml

$ kubectl -n teleport-ns get pods
NAME                            READY   STATUS    RESTARTS   AGE
teleport-azure-access-agent-0   1/1     Running   0          99s

$ tsh apps ls
Application Description Type Public Address                 Labels
----------- ----------- ---- ------------------------------ -------------------
azure-cli               HTTP azure-cli.teleport.example.com teleport.dev/origin

$ tsh apps login azure-cli --azure-identity teleport-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"
    }
  }
]

Logged into Azure app "azure-cli".
Your identity: /subscriptions/0000000000000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/teleport-azure
Example Azure CLI command: tsh az vm list

$ tsh az vm list

$ tsh proxy azure 

Started Azure proxy on http://127.0.0.1:54321.
To avoid port randomization, you can choose the listening port using the --port flag.

Use the following credentials and HTTPS proxy setting to connect to the proxy:

  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

$ az vm list