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 Ingress. 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
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 ASM para adicionar um provedor de autorização externa no nível da malha.
Veja o exemplo de sobreposição de autenticação do usuário e atualize-o se houver 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/release-1.0/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml
Siga o ASM de instalação 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:
/install_asm \ --project_id "PROJECT_ID" \ --cluster_name "CLUSTER_NAME" \ --cluster_location "CLUSTER_LOCATION" \ --mode install \ --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
.
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 consentimento 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://localhost:8443/_gcp_anthos_callback
.
Clique em Save.
Além disso, salve a configuração do cliente OIDC para usar mais tarde.
export OIDC_CLIENT_ID='<your-client-id>' export OIDC_CLIENT_SECRET='<your-client-secret>' export OIDC_ISSUER_URI='https://accounts.google.com' # The host where your application is served from, such as https://example.com export OIDC_REDIRECT_HOST='<your-oidc-redirect-host>' export OIDC_REDIRECT_PATH='<your-oidc-redirect-path>'
Acessar os pacotes kpt
Use as etapas a seguir para instalar a configuração recomendada de authservice
do repositório público (em inglês).
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@release-1.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. Uma implantação de produção
não usa certificados autoassinados.
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 istio-system 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.
Depois de gerar as chaves, coloque os dados da chave no mesmo formato:
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 } ] }
cat ./samples/cookie_encryption_key.json { "keys":[ { "kty":"oct", "kid":"key-0", "K":"YOUR_KEY", "useAfter": 1612813735 } ] }
Crie o secret do Kubernetes, que
authservice
montará no próprio sistema de arquivos dele.Para encontrar o valor do rótulo
REVISION
, verifique a Implantação do Istiod.kubectl create namespace asm-user-auth kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite 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 as variáveis
oauth
. O ID e a chave secreta do cliente são armazenados como segredos do Kubernetes, então usamos a Base64 para codificá-los.kpt cfg set pkg anthos.servicemesh.user-auth.oidc.clientID $(echo -n ${OIDC_CLIENT_ID} | base64 -w0) kpt cfg set pkg anthos.servicemesh.user-auth.oidc.clientSecret $(echo -n ${OIDC_CLIENT_SECRET} | base64 -w0) kpt cfg set pkg anthos.servicemesh.user-auth.oidc.issuerURI ${OIDC_ISSUER_URI} kpt cfg set pkg anthos.servicemesh.user-auth.oidc.redirectURIHost ${OIDC_REDIRECT_HOST} kpt cfg set pkg anthos.servicemesh.user-auth.oidc.redirectURIPath ${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. Ele contém os seguintes campos:
cat pkg/user_auth_config.yaml
apiVersion: security.anthos.io/v1beta1
kind: UserAuthConfig
metadata:
name: user-auth-config
namespace: asm-user-auth
spec:
authentication:
oidc:
certificateAuthorityData: ""
oauthCredentialsSecret:
name: "oauth-secret"
namespace: "asm-user-auth"
issuerURI: "https://accounts.google.com"
redirectURIHost: ""
redirectURIPath: "/_gcp_asm/authenticate"
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 o aplicativo de amostra "Online Boutique" 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.
O processo de instalação também cria um gateway do Istio para exibir o tráfego
HTTPS usando o certificado TLS userauth-tls-cert
que você criou acima.
Esta é a configuração pkg/gateway.yaml
.
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
Atualize o aplicativo "Online Boutique" para usar este gateway a fim de exibir tráfego HTTPS e use o encaminhamento de portas para acessá-lo localmente:
kubectl apply -f./samples/boutique-route.yaml -n demo kubectl port-forward service/istio-ingressgateway 8443:443 -n istio-system
O gateway de entrada na porta 8443 será encaminhado para
localhost
para tornar o aplicativo acessível localmente.Verifique se o aplicativo de amostra "Online Boutique" pode ser acessado em
https://localhost:8443/
.
Verificar a autenticação do usuário
Os serviços do aplicativo "Online Boutique" agora exigem que os usuários finais façam login com a conta do Google deles.
Para ver se a página de login do OIDC é exibida, acesse
https://localhost:8443/
.Depois de fazer login, clique em Próximo e verifique se você é redirecionado para a página inicial do "Online Boutique".
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/rctoken-authz.yaml
O arquivo
rctoken-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: RequestAuthentication metadata: name: require-rc-token namespace: istio-system 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 namespace: istio-system 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
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 tokenEndpoint
e authorizationEndpoint
configurados
no CRD UserAuthConfig
têm uma rota configurada em VirtualService
. As
etapas de instalação anteriores definem isso no asm-user-auth/userauth-oidc
VirtualService
.
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.
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 SSL do domínio do servidor de autorização do OIDC. |
authentication.oidc.clientSecret |
Referências do Tsecret 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.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 endpoint onde "authservice" encerrará o fluxo 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, ele 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. |
authentication.oidc.groupsClaim |
Se o "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. |
authentication.outputJWTAudience |
O público-alvo do RCToken gerado por "authservice". Os arquivos secundários podem validar o RCToken de entrada em relação a esse valor de público-alvo. |
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, precisam ser replicadas 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.
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
user-auth.yaml
na linha de comando parainstall_asm
.Quantos recursos devemos provisionar para o
authservice
? E quantas solicitações por segundo ele pode 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 authservice para aumentar a escalabilidade horizontal.