Como configurar a autenticação do usuário do Anthos Service Mesh
.A autenticação do usuário do Anthos Service Mesh é uma solução integrada para autenticação e controle de acesso do usuário final baseada no navegador para as cargas de trabalho implantadas. Ela permite a integração com provedores de identidade (IDP, na sigla em inglês) existentes para autenticação de usuários, assim como usa APIs do Istio e políticas de autorização para o gerenciamento de acesso. É uma alternativa fácil de usar se comparada à autenticação do JSON Web Token (JWT) do Istio.
Um caso de uso típico é quando uma organização usa o Anthos Service Mesh para hospedar um aplicativo da Web para a equipe de trabalho acessar usando um navegador da Web. Além disso, a organização precisa usar o provedor de identidade existente para gerenciar identidades de usuário. A autenticação do usuário do Anthos Service Mesh facilita a autenticação dos usuários com um fluxo de login e consentimento padrão do OpenID Connect (OIDC) baseado na Web. Quando o usuário é autenticado, o Anthos Service Mesh aplica políticas de autorização do Istio e, quando a autorização acontece, ele transmite a identidade para as cargas de trabalho em um formato de credencial seguro.
Como funciona
A autenticação do usuário do Anthos Service Mesh introduz um novo componente, authservice
.
Este componente integra-se ao Ingress baseado em Envoy como um serviço de
autorização externo que intercepta todas as solicitações recebidas para
autenticação. authservice
implementa o lado do cliente do protocolo OIDC
e permite o acesso de usuários a aplicativos por um navegador, em que os usuários concluem um
fluxo de autenticação e consentimento interativo para estabelecer uma sessão de curta duração.
authservice
implementa protocolos padrão do setor para se integrar a qualquer
provedor de identidade que possa atuar como um servidor de autorização OIDC. Quando o usuário é
autenticado, as informações principais são encapsuladas em um RCToken
no formato
JWT, assinado por authservice
, que o encaminha para a camada de
autorização do Istio no ingresso. Este modelo fornece controle de acesso de perímetro
para o tráfego na malha. Se o usuário estiver autorizado a acessar um recurso, esse RCToken também será
encaminhado aos microsserviços para conseguir informações principais e para aplicar
o controle de acesso detalhado.
O diagrama a seguir mostra o local de authservice
na malha e como ele
se relaciona com as outras partes da malha, como a entrada, as cargas de trabalho, o navegador do
usuário e qualquer IDP existente.
Os administradores podem instalar o authservice
como um complemento em uma instalação do
Anthos Service Mesh. Quando instalado, authservice
lê a configuração do endpoint do
OIDC e outras configurações associadas definidas no recurso
personalizado UserAuth
. O administrador pode usar as APIs ExternalAuthorization
do Anthos Service Mesh
para configurar o auth_server
como um filtro na entrada.
Instalar o serviço de autenticação do usuário
As etapas a seguir explicam como configurar o authservice
.
Pré-requisitos
Siga as etapas em Instalar ferramentas dependentes e validar o cluster para:- Instale as ferramentas necessárias
- Fazer o download de
asmcli
- Conceder permissões de administrador de cluster
- Validar o projeto e o cluster
Certifique-se de que você atende aos pré-requisitos usando as etapas a seguir.
Personalize a instalação usando a sobreposição de autenticação do usuário
Para instalar o serviço de autenticação do usuário, personalize a instalação do Anthos Service Mesh para adicionar um provedor de autorização externo no nível da malha.
Veja o exemplo de sobreposição de autenticação do usuário e atualize-o se houver quaisquer personalizações na malha. É uma prática recomendada para manter esse arquivo de sobreposição no controle de origem.
curl https://raw.githubusercontent.com/GoogleCloudPlatform/asm-user-auth/v1.2.0/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml
Siga instalar o Anthos Service Mesh com sobreposição para usar um script fornecido pelo Google para instalar o Anthos Service Mesh com a sobreposição de autenticação do usuário. Exemplo:
./asmcli install \ --project_id PROJECT_ID \ --cluster_name CLUSTER_NAME \ --cluster_location CLUSTER_LOCATION \ --fleet_id FLEET_PROJECT_ID \ --output_dir DIR_PATH \ --enable_all \ --custom_overlay user-auth-overlay.yaml
Os pacotes
kpt
de autenticação do usuário criam umaAuthorizationPolicy
para referenciar ao provedor de autorização externo especificado porpkg/ext-authz.yaml
.Criar e rotular o namespace
asm-user-auth
.kubectl create namespace asm-user-auth kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite
Para encontrar o valor do rótulo
REVISION
, verifiquekubectl get pod -n istio-system -L istio.io/rev
.Instale o gateway do Istio no namespace
asm-user-auth
.kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway
Preparar a configuração do cliente OIDC
Defina a configuração do cliente OIDC usando as etapas a seguir. Este guia usa o Google como IDP, mas é possível usar qualquer IDP que seja compatível com a autenticação OIDC.
No console do Google Cloud, acesse APIs e serviços > Credenciais.
Acesse Criar credenciais e escolha ID do cliente do OAuth. Se necessário, defina as opções da tela de permissão do OAuth e configure as seguintes opções:
- Defina o Tipo de aplicativo como Aplicativo da Web.
- Defina o URI de redirecionamento autorizado
como
https://REDIRECT_HOST/REDIRECT_PATH
. Por exemplo, para localhost, defina comohttps://localhost:8443/_gcp_asm_authenticate
.
Clique em Save.
Além disso, salve a configuração do cliente OIDC para usar mais tarde.
export OIDC_CLIENT_ID=CLIENT_ID export OIDC_CLIENT_SECRET=CLIENT_SECRET export OIDC_ISSUER_URI=ISSUER_URI export OIDC_REDIRECT_HOST=REDIRECT_HOST export OIDC_REDIRECT_PATH=REDIRECT_PATH
Acessar os pacotes kpt
Use as etapas a seguir para instalar a configuração recomendada de authservice
do
repositório público. Esses
comandos recuperarão o contêiner authservice
mais recente e o iniciarão como um pod no
namespace asm-user-auth
. Ele também configura a entrada para interceptar todas as
solicitações.
Acesse o pacote kpt:
kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.0 .
cd asm-user-auth/
Definir o URL de redirecionamento e o secret do gateway de entrada
O OAuth2
requer um URL de redirecionamento hospedado em um endpoint protegido por HTTPS. Esses
comandos são para fins de exemplo e simplificam a configuração gerando um certificado
autoassinado para o gateway de entrada do Istio.
Gerar um certificado autoassinado:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \ -days 365 -nodes -subj '/CN=localhost'
Crie um secret para o gateway de entrada hospedar o tráfego HTTPS:
kubectl create -n asm-user-auth secret tls userauth-tls-cert --key=key.pem \ --cert=cert.pem
Aplicar as chaves de criptografia e assinatura
O authservice
precisa de dois conjuntos de chaves para operar. A primeira é uma
chave simétrica para criptografia e descriptografia. Ela é usada para criptografar o
estado da sessão antes de defini-lo como um cookie.
O segundo conjunto de chaves é um par de chave pública/privada. Ela é usada para assinar as informações de usuário autenticadas no formato JWT como um RCToken. A chave pública desse par é publicada em um endpoint predefinido que os arquivos secundários podem usar para validar o JWT.
O pacote de autenticação de usuário kpt
contém duas chaves de amostra para uma configuração rápida.
No entanto, é possível usar o sistema de gerenciamento de chaves que você preferir para gerar essas
chaves.
Prepare a chave de criptografia da sessão com o formato a seguir ou use a amostra do pkg, que pode ser visualizado por
cat ./samples/cookie_encryption_key.json
.{ "keys":[ { "kty":"oct", "kid":"key-0", "K":"YOUR_KEY", "useAfter": 1612813735 } ] }
Gere uma chave AES de teste com o seguinte comando:
openssl enc -aes-256-cbc -k mycustomkey -P -md sha1 | grep key
Prepare a chave de assinatura RCToken com o formato a seguir ou use a amostra do pkg, que pode ser visualizado por
cat ./samples/rctoken_signing_key.json
.{ "keys":[ { "kty":"RSA", "kid":"rsa-signing-key", "K":"YOUR_KEY", # k contains a Base64 encoded PEM format RSA signing key. "useAfter": 1612813735 # unix timestamp } ] }
É possível gerar uma chave privada RSA de teste de 256 bits com o seguinte comando:
openssl genpkey -algorithm RSA -out rsa_private.pem -pkeyopt rsa_keygen_bits:256
Crie o secret do Kubernetes, que
authservice
montará no próprio sistema de arquivos dele.kubectl create secret generic secret-key \ --from-file="session_cookie.key"="./samples/cookie_encryption_key.json" \ --from-file="rctoken.key"="./samples/rctoken_signing_key.json" \ --namespace=asm-user-auth
Implantar o serviço de autenticação do usuário
Os comandos a seguir criam o serviço de autenticação do usuário e o implantam no
namespace asm-user-auth
.
Defina os valores necessários para a configuração da autenticação do usuário. O ID e a chave secreta do cliente são armazenados como segredos do Kubernetes, então usamos a Base64 para codificá-los. Acesse o repositório público para ver todos os setters disponíveis.
kpt fn eval pkg --image gcr.io/kpt-fn/apply-setters:v0.2 --truncate-output=false -- \
client-id="$(echo -n ${OIDC_CLIENT_ID} | base64 -w0)" \
client-secret="$(echo -n ${OIDC_CLIENT_SECRET} | base64 -w0)" \
issuer-uri="${OIDC_ISSUER_URI}" \
redirect-host="${OIDC_REDIRECT_HOST}" \
redirect-path="${OIDC_REDIRECT_PATH}"
Aplique o pacote kpt
:
# Remove the potential alpha version CRD if exists.
kubectl delete crd userauthconfigs.security.anthos.io
kubectl apply -f ./pkg/asm_user_auth_config_v1beta1.yaml
kubectl apply -f ./pkg
O authservice
consome a CRD UserAuthConfig
para fornecer autenticação do usuário
final. UserAuthConfig
é configurável no ambiente de execução, e é possível
atualizá-lo para alterar o comportamento de authservice
e configurá-lo com endpoints
para qualquer servidor de autorização OIDC.
Para visualizar o arquivo por cat pkg/user_auth_config.yaml
, ele contém estes campos:
apiVersion: security.anthos.io/v1beta1
kind: UserAuthConfig
metadata:
name: user-auth-config
namespace: asm-user-auth
spec:
authentication:
oidc:
certificateAuthorityData: "" # kpt-set: ${ca-cert}
issuerURI: "<your issuer uri>" # kpt-set: ${issuer-uri}
proxy: "" # kpt-set: ${proxy}
oauthCredentialsSecret:
name: "oauth-secret" # kpt-set: ${secret-name}
namespace: "asm-user-auth" # kpt-set: ${secret-namespace}
redirectURIHost: "" # kpt-set: ${redirect-host}
redirectURIPath: "/_gcp_asm_authenticate" # kpt-set: ${redirect-path}
scopes: "" # kpt-set: ${scopes}
groupsClaim: "" # kpt-set: ${groups}
outputJWTAudience: "test_audience" # kpt-set: ${jwt-audience}
Consulte
detalhes da configuração de autenticação do usuário
para ver descrições detalhadas dos campos user_auth_config.yaml
.
Realizar tarefas pós-instalação
As tarefas a seguir são necessárias depois que você concluir as etapas de instalação anteriores.
Ativar a autenticação de usuários nos aplicativos
Nesta seção, demonstramos como ativar a autenticação do usuário usando
httpbin
como exemplo.
A autenticação de usuário do Anthos Service Mesh usa uma política de autorização tipo
CUSTOM
para acionar o fluxo do OIDC.
Depois de
instalar o gateway do Istio,
configure-o para veicular o tráfego HTTPS usando o certificado TLS userauth-tls-cert
criado acima. Veja abaixo a configuração pkg/gateway.yaml
que acabou de ser
instalada.
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: userauth
namespace: asm-user-auth
spec:
selector:
istio: ingressgateway
servers:
- hosts:
- '*'
port:
name: https
number: 443
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: userauth-tls-cert
---
# This ensures the OIDC endpoint has at least some route defined.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: userauth-oidc
namespace: asm-user-auth
spec:
gateways:
- userauth
hosts:
- '*'
http:
- match:
- uri:
prefix: /status
- uri:
prefix: "your-oidc-redirect-path"
name: user-auth-route
route:
- destination:
host: authservice
port:
number: 10004
Rotule o namespace
default
para ativar a injeção automáticaistio-proxy
para as implantações.kubectl label namespace default istio.io/rev=REVISION --overwrite
Implantar
httpbin
no namespacedefault
.kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml -n default
Atualize
httpbin
para usar esse gateway para exibir tráfego HTTPS e usar encaminhamento de porta para acessar o aplicativo localmente:kubectl apply -f./samples/httpbin-route.yaml -n default kubectl port-forward service/istio-ingressgateway 8443:443 -n asm-user-auth
O gateway de entrada na porta 8443 será encaminhado para
localhost
para tornar o aplicativo acessível localmente.Implante o
samples/rctoken-authz.yaml
para ativar RequestAuthentication e AuthorizationPolicy para verificar o RCToken para as solicitações.kubectl apply -f ./samples/rctoken-authz.yaml -n asm-user-auth
samples/rctoken-authz.yaml
de exemplo:apiVersion: security.istio.io/v1beta1 kind: RequestAuthentication metadata: name: require-rc-token spec: selector: matchLabels: istio: ingressgateway jwtRules: - issuer: "authservice.asm-user-auth.svc.cluster.local" audiences: - "test_audience" jwksUri: "http://authservice.asm-user-auth.svc.cluster.local:10004/_gcp_user_auth/jwks" fromHeaders: - name: X-ASM-RCTOKEN forwardOriginalToken: true --- apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: require-rc-token spec: selector: matchLabels: istio: ingressgateway action: ALLOW rules: - when: - key: request.auth.claims[iss] values: - authservice.asm-user-auth.svc.cluster.local - key: request.auth.claims[aud] values: - test_audience
Verificar a autenticação do usuário
O httpbin
exibe dois caminhos, /ip
é acessível publicamente e /headers
requer que o usuário final faça login por meio do IDP configurado.
Verifique se você pode acessar
/ip
diretamente acessandohttps://localhost:8443/ip
.Para ver se a página de login do OIDC é exibida, acesse
https://localhost:8443/headers
.Depois de fazer login, clique em Próxima e verifique se ele redireciona você para a página
/headers
.
Configurar políticas de autorização
Depois de concluir a configuração nas etapas anteriores, cada usuário será
redirecionado por um fluxo de autenticação baseado na Web. Quando o fluxo for concluído, o
authservice
gerará um RCToken
no formato JWT, usado para
transmitir as informações do usuário autenticado.
Adicione políticas de autorização do Istio na entrada para garantir que uma verificação de autorização seja executada para cada usuário autenticado:
kubectl apply -f ./samples/httpbin-authz.yaml -n asm-user-auth
O arquivo
httpbin-authz.yaml
configura o gateway de entrada para validar o token de RC emitido pelo authservice e autorizar apenas quando o JWT contiver os campos desejados, como públicos-alvo e emissores.Veja o exemplo de política de autorização a seguir:
apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: require-rc-token spec: selector: matchLabels: istio: ingressgateway action: ALLOW rules: - to: - operation: paths: ["/ip"] - to: when: - key: request.auth.claims[iss] values: - authservice.asm-user-auth.svc.cluster.local - key: request.auth.claims[aud] values: - test_audience - key: request.auth.claims[sub] values: - allowed_user_sub_1 # Change this with the "sub" claim in the RC token. Wildcard '*' will match everything.
Definir configurações específicas do ambiente
As etapas anteriores usam localhost
e um certificado HTTPS autoassinado para a configuração
rápida. Para uso real na produção, use seu próprio domínio, como example.com
.
Além disso, verifique se certificateAuthorityData
tem o conteúdo do certificado raiz pretendido. Por exemplo, se o IDP for confiável com os certificados raiz do sistema, você pode
deixá-lo vazio. Se houver um proxy HTTPS encerrando a conexão HTTPS, ele
precisará ser definido como o certificado raiz do proxy.
Gerenciar e fazer rotação de chaves
Há dois conjuntos de chaves usadas por authservice
: É possível fazer a rotação de cada chave de
maneira independente. No entanto, antes de fazer a rotação das chaves, é importante
entender como a rotação funciona.
As duas chaves estão no formato JSON. O campo useAfter
especifica o carimbo de data/hora desde
quando a chave for considerada em uso. Durante uma rotação de chaves,
inclua chaves antigas e novas no JSON. No exemplo a seguir,
new-key
será usada apenas depois do carimbo de data/hora 1712813735
.
{
"keys":[
{
"kty":"RSA",
"kid":"old-key",
"K":"...", # k contains a Base64 encoded PEM format RSA signing key.
"useAfter": 1612813735, # unix timestamp
}
{
"kty":"RSA",
"kid":"new-key",
"K":"...", # k contains a Base64 encoded PEM format RSA signing key.
"useAfter": 1712813735, # unix timestamp
}
]
}
O Anthos Service Mesh usa a chave simétrica para criptografar dados de sessão armazenados em
cookies do navegador. Para garantir a validade de sessões existentes, authservice
tenta
descriptografar com todas as chaves no conjunto de chaves. Na rotação, o authservice
usará a nova chave para criptografar novas sessões e continuará
tentando fazer a descriptografia com as chaves antigas.
O par de chave pública/privada é usado para assinar RCToken
. A chave pública é
transmitida para os arquivos secundários por istiod
para verificação do JWT. É fundamental que
os arquivos secundários recebam a nova chave pública antes que authservice
comece a usar a nova
chave privada para assinar o RCToken
. Para isso, authservice
começa a publicar a
chave pública imediatamente após a adição dela, mas aguarda um tempo significativo
antes de começar a usá-la para assinar o RCToken
.
Para resumir, ao executar a rotação de chaves, recomendamos:
- Faça rotações regulares de chaves ou sob demanda, conforme necessário.
- No formato JSON, inclua as chaves atuais e novas. As novas chaves serão associadas a um carimbo de data/hora no futuro. Recomendamos que você especifique um carimbo de data/hora com pelo menos algumas horas de antecedência.
- Monitore e confirme se os serviços ainda estão íntegros depois que a nova chave está em uso. Aguarde pelo menos um dia depois de a nova chave ser usada antes de passar para a próxima etapa.
- Remova as chaves antigas das entradas JSON. Eles não são mais necessários.
Implantação de vários clusters
A autenticação de usuário do Anthos Service Mesh é compatível com a implantação de vários clusters. É necessário implantar a autenticação do usuário em cada cluster, conforme descrito acima. A configuração de autenticação do usuário, como o recurso personalizado UserAuth, a chave secreta do cliente OIDC, as chaves de criptografia, todos precisam ser replicados em cada cluster.
Por padrão, o gateway de entrada balanceará a carga das solicitações de autenticação
para qualquer uma das instâncias authservice
. É possível usar a regra de destino para configurar
o gateway de entrada para enviar solicitações ao authservice
no mesmo cluster e
fazer failover apenas para o authservice
de outros clusters.
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: authservice-fail-over
namespace: asm-user-auth
spec:
host: authservice.asm-user-auth.svc.cluster.local
trafficPolicy:
loadBalancer:
localityLbSetting:
enabled: true
failover:
- from: us-east
to: us-west
- from: us-west
to: us-east
Assim como outras configurações, isso precisa ser definido em cada cluster.
Mapeamento de declarações personalizadas
Se você quiser configurar o mapeamento de declarações personalizadas, configure o
spec.authentication.oidc.attributeMapping
para definir qualquer mapeamento do IDToken do provedor de identidade original. A chave será o nome da reivindicação
no RCToken, e o valor é uma expressão CEL sobre como analisar a declaração do IDToken.
Use assertion
para fazer referência ao IDToken.
Exemplo:
spec:
authentication:
oidc:
attributeMapping:
aud_copy: assertion.aud
decision: 'assertion.sub.startsWith("123") ? "success" : "fail"'
No RCToken, uma reivindicação aninhada attributes
contém as reivindicações que foram configuradas:
"attributes": {
"aud_copy": "foo.googleusercontent.com",
"decision": "success"
}
Se a expressão CEL não analisar o valor do IDToken, ela vai ignorar a declaração sem falhar no fluxo de autenticação.
Upgrades da autenticação de usuário
Instale os pacotes de autenticação do usuário novamente porque eles contêm o binário atualizado para a nova versão:
kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.0 . cd asm-user-auth/
Salve a configuração do cliente do OIDC:
export OIDC_CLIENT_ID=CLIENT_ID export OIDC_CLIENT_SECRET=CLIENT_SECRET export OIDC_ISSUER_URI=ISSUER_URI export OIDC_REDIRECT_HOST=REDIRECT_HOST export OIDC_REDIRECT_PATH=REDIRECT_PATH
Implante o serviço de autenticação de usuário para fazer upgrade para uma nova versão.
Detalhes da configuração de autenticação do usuário
A tabela a seguir descreve cada campo do CRD:
Nome do campo | Descrição |
---|---|
authentication.oidc |
Nesta seção, mostramos a configuração do endpoint do OIDC e os parâmetros usados no fluxo do OIDC. |
authentication.oidc.certificateAuthorityData |
Este é o certificado raiz SSL do domínio do servidor de autorização OIDC ou do proxy HTTPS, se houver. |
authentication.oidc.oauthCredentialsSecret |
Referências do secret para o secret de tipo opaco do Kubernetes que contém o OAuth2 OIDC client_id e client_secret no payload JSON. |
authentication.oidc.issuerURI |
O URI a ser usado como o emissor na saída RCToken. |
authentication.oidc.proxy |
Servidor proxy para o IdP do OIDC, se aplicável. Com o formato http://user:password@10.10.10.10:8888. |
authentication.oidc.redirectURIHost |
O host a ser usado para o URI de encerramento do OAuth. Se você deixar esse campo vazio, o
host do URL de destino será usado, e o URI de redirecionamento será montado dinamicamente. Esse valor pode ser usado quando uma sessão de SSO de autenticação de usuário é desejada em um domínio de nível mais alto. Por exemplo, para ativar o SSO entre perfil.example.com/ e admin.example.com/, esse valor pode ser definido como example.com. Isso permitirá que uma sessão de autenticação do usuário seja estabelecida em example.com que será compartilhada entre todos os subdomínios. Observação: se vários domínios forem exibidos na mesma malha, example1.com e example2.com, o recurso não poderá ser usado e é recomendado que fique vazio. |
authentication.oidc.redirectURIPath |
O caminho do endpoint onde authservice encerrará o fluxo do OAuth. É
necessário registrar esse caminho de URI mais o host como um URI de redirecionamento autorizado no
servidor de autorização do authentication.oidc.clientID .Além disso, esse URI precisa ser exibido na mesma malha de serviço e entrada em que authservice estiver ativado. |
authentication.oidc.scopes |
O escopo do OAuth que precisa ser solicitado na solicitação de autenticação. Lista de identificadores separados por vírgulas usados para especificar quais privilégios de acesso estão sendo solicitados, além do escopo "openid", por exemplo: "groups,allatclaim". |
authentication.oidc.groupsClaim |
Se idtoken contiver uma declaração de grupos, use este campo para indicar
o nome. Se especificado, o serviço transmitirá os dados dessa
declaração na declaração groups no RCToken de saída. Essa declaração deve conter uma
lista separada por vírgulas, por exemplo, ["grupo1", "grupo2"]. |
authentication.oidc.attributeMapping |
Contém um ou mais mapeamentos de declaração de idtoken seguidos de expressões de CEL. Todas as declarações
precisam ser referenciadas por assertion.X , assertion é referenciada
ao IDToken original, por exemplo, aud_copy: assertion.aud . |
authentication.outputJWTAudience |
O público do RCToken gerado por authservice . Os arquivos secundários podem
validar o RCToken de entrada em relação a esse valor de público. |
Resolver problemas
Acessibilidade da rede para IDP.
Registro possível:
error: TLS handshake failed.
.Verifique executando
curl
do contêineristio-proxy
para o URI do emissor do IDP. Se não conseguir se conectar, o usuário poderá verificar as regras de firewall ou outras configurações de rede do cluster.Certificado de CA raiz
Registro possível:
error: The server's TLS certificate did not match expectations.
ouerror: TLS handshake failed.
.Verifique se o
certificateAuthorityData
contém o certificado de CA raiz correto. Quando não houver nenhum proxy HTTPS encerrando o tráfego HTTPS, será necessário manter o certificado de CA raiz para o IdP. Se houver um, ele deverá manter o do proxy.Redirecione a configuração do caminho.
Possível observação: receba a página de erro 404 durante o fluxo de autenticação do OIDC.
A autenticação do usuário retorna o cabeçalho "Set-Cookie" sem usar o atributo de caminho, que, por padrão, o navegador usa o diretório do URL de solicitação como caminho do cookie (escopo do cookie relacionado ao caminho). Portanto, recomendamos não incluir "/" no caminho de redirecionamento, a menos que seja intencional.
Perguntas frequentes
Como faço upgrade do Anthos Service Mesh com a autenticação de usuário ativada?
Siga o processo de upgrade do Anthos Service Mesh e especifique o arquivo de sobreposição adicionando
--custom_overlay user-auth-overlay.yaml
na linha de comando aasmcli install
.Quantos recursos devemos provisionar para o
authservice
? E quantas solicitações por segundo ele consegue processar?Por padrão,
authservice
é configurado com 2.0 vCPUs, 256 Mi de memória. Nessa configuração,authservice
pode processar 500 solicitações por segundo. Para processar uma quantidade maior de solicitações, provisione mais CPU, que é aproximadamente proporcional à capacidade de processamento de solicitações. Também é possível configurar várias réplicas do serviço de autenticação para aumentar a escalonabilidade horizontal.