Alibaba Cloud Service Mesh:Integre um serviço de autorização HTTP personalizado

Pré-requisitos

O cluster foi adicionado à instância do ASM..

Etapa 1: Implante um serviço de autorização personalizado

Implante um serviço de autorização personalizado no cluster ACK. Esse serviço deve estar em conformidade com a especificação da API do Istio para serviços de autorização personalizados e suportar os protocolos HTTP e gRPC para implementar a lógica de autorização personalizada. O serviço de exemplo usado neste tópico exige que a solicitação inclua o cabeçalho x-ext-authz: allow para passar na verificação de autorização.

1. Conecte-se ao cluster usando kubectl e crie um arquivo chamado ext-authz.yaml com o seguinte conteúdo.

   Para mais informações sobre como se conectar a um cluster usando kubectl, consulte Obter o KubeConfig de um cluster e usar kubectl para se conectar ao cluster.

   ext-authz.yaml

   # Copyright Istio Authors
   #
   #   Licensed under the Apache License, Version 2.0 (the "License");
   #   you may not use this file except in compliance with the License.
   #   You may obtain a copy of the License at
   #
   #       http://www.apache.org/licenses/LICENSE-2.0
   #
   #   Unless required by applicable law or agreed to in writing, software
   #   distributed under the License is distributed on an "AS IS" BASIS,
   #   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   #   See the License for the specific language governing permissions and
   #   limitations under the License.
   
   # Example configurations for deploying ext-authz server separately in the mesh.
   
   apiVersion: v1
   kind: Service
   metadata:
     name: ext-authz
     labels:
       app: ext-authz
   spec:
     ports:
     - name: http
       port: 8000
       targetPort: 8000
     - name: grpc
       port: 9000
       targetPort: 9000
     selector:
       app: ext-authz
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: ext-authz
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: ext-authz
     template:
       metadata:
         labels:
           app: ext-authz
       spec:
         containers:
         - image: istio/ext-authz:0.6
           imagePullPolicy: IfNotPresent
           name: ext-authz
           ports:
           - containerPort: 8000
           - containerPort: 9000
   ---

2. Execute o comando a seguir para implantar o serviço de autorização personalizado.

   kubectl apply -f ext-authz.yaml

3. Execute o comando a seguir para verificar o status de implantação do pod.

   kubectl get pod

   Saída esperada:

   NAME                         READY   STATUS    RESTARTS   AGE
   ext-authz-6b5db88f86-2m7c6   2/2     Running   0          79m

4. Execute o comando a seguir para verificar se a aplicação está funcionando.

   kubectl logs "$(kubectl get pod -l app=ext-authz -n default -o jsonpath={.items..metadata.name})" -n default -c ext-authz

   Saída esperada:

   2023/12/20 08:15:39 Starting gRPC server at [::]:9000
   2023/12/20 08:15:39 Starting HTTP server at [::]:8000

   Essa saída indica que a aplicação está funcionando e que o serviço de autorização personalizado foi implantado.

5. Obtenha a porta HTTP do serviço ext-authz.

   1. Faça login no ACK console. No painel de navegação à esquerda, clique em Clusters.

   2. Na página Clusters, clique no nome do cluster. No painel de navegação à esquerda, clique em Network > Services.

   3. Na página Services, clique em ext-authz.

      Na seção Endpoint, observe que a porta HTTP é 8000. O endereço de acesso deste serviço é ext-authz.default.svc.cluster.local:8000.

Etapa 2: Implante as aplicações de exemplo

1. Crie um arquivo chamado httpbin.yaml com o seguinte conteúdo.

   httpbin.yaml

   # Copyright Istio Authors
   #
   #   Licensed under the Apache License, Version 2.0 (the "License");
   #   you may not use this file except in compliance with the License.
   #   You may obtain a copy of the License at
   #
   #       http://www.apache.org/licenses/LICENSE-2.0
   #
   #   Unless required by applicable law or agreed to in writing, software
   #   distributed under the License is distributed on an "AS IS" BASIS,
   #   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   #   See the License for the specific language governing permissions and
   #   limitations under the License.
   ##################################################################################################
   # httpbin service
   ##################################################################################################
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: httpbin
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: httpbin
     labels:
       app: httpbin
       service: httpbin
   spec:
     ports:
     - name: http
       port: 8000
       targetPort: 80
     selector:
       app: httpbin
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: httpbin
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: httpbin
         version: v1
     template:
       metadata:
         labels:
           app: httpbin
           version: v1
       spec:
         serviceAccountName: httpbin
         containers:
         - image: docker.io/kennethreitz/httpbin
           imagePullPolicy: IfNotPresent
           name: httpbin
           ports:
           - containerPort: 80
                           

2. Execute o comando a seguir para implantar a aplicação httpbin.

   kubectl apply -f httpbin.yaml

3. Crie um arquivo chamado sleep.yaml com o seguinte conteúdo.

   sleep.yaml

   # Copyright Istio Authors
   #
   #   Licensed under the Apache License, Version 2.0 (the "License");
   #   you may not use this file except in compliance with the License.
   #   You may obtain a copy of the License at
   #
   #       http://www.apache.org/licenses/LICENSE-2.0
   #
   #   Unless required by applicable law or agreed to in writing, software
   #   distributed under the License is distributed on an "AS IS" BASIS,
   #   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   #   See the License for the specific language governing permissions and
   #   limitations under the License.
   ##################################################################################################
   # Sleep service
   ##################################################################################################
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: sleep
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: sleep
     labels:
       app: sleep
       service: sleep
   spec:
     ports:
     - port: 80
       name: http
     selector:
       app: sleep
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: sleep
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: sleep
     template:
       metadata:
         labels:
           app: sleep
       spec:
         terminationGracePeriodSeconds: 0
         serviceAccountName: sleep
         containers:
         - name: sleep
           image: curlimages/curl
           command: ["/bin/sleep", "3650d"]
           imagePullPolicy: IfNotPresent
           volumeMounts:
           - mountPath: /etc/sleep/tls
             name: secret-volume
         volumes:
         - name: secret-volume
           secret:
             secretName: sleep-secret
             optional: true
   ---
                           

4. Execute o comando a seguir para implantar a aplicação sleep.

   kubectl apply -f sleep.yaml

Etapa 3: Registre o serviço de autorização personalizado

Declare o serviço implantado na Etapa 1 no Service Mesh para que ele possa usar o serviço para autenticação.

1. Faça login no ASM console. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

2. Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação à esquerda, escolha Mesh Security Center > Custom Authorization Service. Na página exibida, clique em Define Custom Authorization Service.

3. Na página Register External Authorization Service, clique na aba Custom authorization service (HTTP or gRPC protocol) implemented based on envoy.ext_authz, configure os parâmetros e clique em Create.

   Tipo	Parâmetro	Descrição
   Parâmetros obrigatórios	Protocol	Selecione o protocolo do serviço de autorização personalizado. Neste exemplo, selecione HTTP.
   	Name	Nome do serviço de autorização personalizado. Neste exemplo, insira test4http.
   	Service Address	Insira o endereço do serviço da aplicação de autorização personalizada. O endereço deve ser um nome de domínio totalmente qualificado no formato <Nome da Aplicação>.<Namespace>.svc.<Domínio do Cluster>. Para este exemplo, insira ext-authz.default.svc.cluster.local.
   	Port(1 - 65535)	Insira a porta do serviço da aplicação de autorização personalizada. Neste exemplo, insira 8000.
   	Timeout(second)	Se a aplicação de autorização não responder dentro desse período, o serviço será considerado indisponível. Neste exemplo, defina o tempo limite como 10 segundos.
   Parâmetros opcionais	Skip authentication while authorization service is unavailable	Quando ativado, as solicitações são permitidas se o serviço de autorização estiver indisponível. Esta opção está desativada neste exemplo.
   	Error code returned by asm proxy while Auth-Service is not available	Esta opção está disponível apenas quando Skip authentication while authorization service is unavailable está desativado. Se você ativar esta opção, deverá inserir um código de erro. Esse código é retornado ao cliente quando o serviço de autorização está indisponível. Neste exemplo, esta opção está desativada.
   	Carry origin header within auth request [includeRequestHeadersInCheck]	Quando ativado, especifique as chaves de cabeçalho a serem incluídas. Os cabeçalhos correspondentes são incluídos na solicitação enviada ao serviço de autorização personalizado. Para este exemplo, consulte a configuração em Incluir cabeçalhos na solicitação de autorização. Nota Este parâmetro só pode ser configurado quando Protocol estiver definido como HTTP.
   	Add a header in the authentication request (if a header with the same name already exists, the original value will be overwritten) [includeAdditionalHeadersInCheck]	Quando ativado, especifique as chaves e valores de cabeçalho a serem adicionados à solicitação de autorização. Se já existir um cabeçalho com o mesmo nome, seu valor será sobrescrito. Neste exemplo, esta opção está desativada. Nota Este parâmetro só pode ser configurado quando Protocol estiver definido como HTTP.
   	Overwrite Header when authentication passes (overwrite Header in the request to the target service by using Header in the authentication request Response) [headersToUpstreamOnAllow]	Se ativado, especifique quais chaves de cabeçalho devem ser sobrescritas. Em caso de autorização bem-sucedida, os cabeçalhos correspondentes da resposta de autorização sobrescrevem os cabeçalhos equivalentes na solicitação para o serviço de destino. Para este exemplo, consulte a configuração em Sobrescrever cabeçalhos em autorização bem-sucedida. Nota Este parâmetro só pode ser configurado quando Protocol estiver definido como HTTP.
   	Overwrite Header when authentication fails (overwrite Header in Response using Header in authentication request Response) [headersToDownstreamOnDeny]	Se ativado, especifique quais chaves de cabeçalho devem ser sobrescritas. Em caso de falha na autorização, os cabeçalhos correspondentes da resposta de autorização sobrescrevem os cabeçalhos equivalentes na resposta para o serviço chamador. Para este exemplo, consulte a configuração em Sobrescrever cabeçalhos em falha de autorização. Nota Este parâmetro só pode ser configurado quando Protocol estiver definido como HTTP.
   	Carry origin request body within auth request	Se ativado, especifique o tamanho máximo do corpo da solicitação a ser incluído na verificação de autorização. Se você também ativar Allow send incomplete message to Auth-Service(HTTP 413 will be returned if request body size beyond limitation and this option is disabled), os corpos que excederem o limite serão truncados e enviados. Caso contrário, solicitações com corpos excessivamente grandes serão rejeitadas com um erro HTTP 413.

   Figura 1. Incluir cabeçalhos na solicitação de autorização

   Nota

   A última entrada é o x-ext-authz recém-adicionado.

   Os cabeçalhos a serem incluídos são: cookie, x-forwarded-access-token, x-forwarded-user, x-forwarded-email, authorization, x-forwarded-proto, proxy-authorization, user-agent, x-forwarded-host, from, x-forwarded-for, accept e x-ext-authz.

   Figura 2. Sobrescrever cabeçalhos em autorização bem-sucedida

   Nota

   A última entrada é o x-ext-authz-check-result recém-adicionado.

   Esta lista também inclui os cinco campos existentes: authorization, cookie, path, x-auth-request-access-token e x-forwarded-access-token.

   Figura 3. Sobrescrever cabeçalhos em falha de autorização

   Nota

   A última entrada é o x-ext-authz-check-result recém-adicionado.

   A lista de cabeçalhos a serem sobrescritos já contém content-type e set-cookie. O novo x-ext-authz-check-result é adicionado ao final da lista.

Etapa 4: Defina uma política de autorização

Crie uma política de autorização para especificar quais operações exigem autorização.

1. Faça login no ASM console. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

2. Na página Mesh Management, clique no nome da instância do ASM. No painel de navegação à esquerda, escolha Mesh Security Center > AuthorizationPolicy. Na página exibida, clique em Create.

3. Na página Create, configure os parâmetros e clique em Create.

   Parâmetro	Descrição
   Name	Nome da política de autorização personalizada. Neste exemplo, insira test1.
   Policy Type	Selecione Custom Authorization Service.
   Custom Authorization Service	Selecione httpextauth-test4http(HTTP).
   Namespace	Na aba Workload Scope, selecione o namespace default.
   Effective Scope	Selecione Service.
   Workload	Selecione httpbin.
   Request Matching Rules	Na seção Add Request Target, ative Paths e defina o valor como /headers.

Etapa 5: Verifique a autorização personalizada

1. Execute o comando a seguir para acessar httpbin.default:8000/ip.

   kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- curl "http://httpbin.default:8000/ip" -s -o /dev/null -w "%{http_code}\n"

   Um código de status 200 é retornado, indicando que a autorização não foi acionada. Como o caminho da solicitação /ip não corresponde ao caminho /headers na política de autorização, a política não se aplicou a esta solicitação.

2. Execute o comando a seguir para acessar httpbin.default:8000/headers com o cabeçalho de solicitação x-ext-authz: deny.

   kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -ndefault -- curl "http://httpbin.default:8000/headers" -H "x-ext-authz: deny" -s -i

   Saída esperada:

   HTTP/1.1 403 Forbidden
   x-ext-authz-check-result: denied
   content-length: 76
   content-type: text/plain; charset=utf-8
   date: Wed, 20 Dec 2023 09:53:28 GMT
   server: envoy
   x-envoy-upstream-service-time: 10
   denied by ext_authz for not found header `x-ext-authz: allow` in the request

   A saída mostra que a solicitação foi negada porque acionou a política de autorização. A resposta inclui o cabeçalho x-ext-authz-check-result: denied, conforme configurado para falhas de autorização. A política foi aplicada porque o caminho da solicitação é /headers.

3. Execute o comando a seguir para acessar httpbin.default:8000/headers com o cabeçalho de solicitação x-ext-authz: allow.

   kubectl exec "$(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name})" -c sleep -n default -- curl "http://httpbin.default:8000/headers" -H "x-ext-authz: allow" -s

   Saída esperada:

   {
     "headers": {
       "Accept": "*/*",
       "Host": "httpbin.default:8000",
       "User-Agent": "curl/8.5.0",
       "X-Envoy-Attempt-Count": "1",
       "X-Ext-Authz": "allow",
       "X-Ext-Authz-Check-Result": "allowed",
       "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/default/sa/httpbin;Hash=c3e5364e87add0f4f69e6b0d029f5961b404c8f209bf9004b3d21a82cf67****;Subject=\"\";URI=spiffe://cluster.local/ns/default/sa/sleep"
     }
   }

   A saída mostra que a solicitação foi permitida porque acionou a política de autorização e passou na verificação. A resposta inclui o cabeçalho "X-Ext-Authz-Check-Result": "allowed", conforme configurado para autorização bem-sucedida. A política foi aplicada porque o caminho da solicitação é /headers.

Operações relacionadas

• Para saber como desenvolver um serviço de autorização personalizado baseado em HTTP, consulte Desenvolver um serviço de autorização personalizado baseado em HTTP.

• Para saber como desenvolver um serviço de autorização personalizado baseado em gRPC, consulte Desenvolver um serviço de autorização personalizado baseado em gRPC.

• Para aplicar controle de acesso granular a serviços que se comunicam via gRPC, consulte Integrar um serviço de autorização personalizado gRPC.

• Para controlar o acesso a serviços fora do mesh, consulte Controlar tráfego de saída para sites externos e Controlar tráfego de saída para bancos de dados externos.

• Ative a auditoria de mesh para registrar e rastrear operações de usuários. Configure também alertas de auditoria para operações de recursos do mesh e receba notificações oportunas sobre alterações importantes nos recursos. Para mais informações, consulte Usar auditoria de operações KubeAPI e Configurar alertas de auditoria para operações de recursos do mesh.