I am implementing a microservices architecture, I have an oauth2 service that does the authentication and generates a token for me.
I am using Treafik as an API-Gateway
How do I validate that a token has expired and that the token signature is valid?
I am testing with those tags in my docker-compose but it seems to ignore it
labels:
- "traefik.http.middlewares.test-jwtAuth.plugin.jwtAuth.source=jwtSource"
- "traefik.http.middlewares.test-jwtAuth.plugin.jwtAuth.forwardHeaders.Group=grp"
- "traefik.http.middlewares.test-jwtAuth.plugin.jwtAuth.forwardHeaders.Expires-At=exp"
- "traefik.http.middlewares.test-jwtAuth.plugin.jwtAuth.claims: Equals(`grp`, `admin`)"
Related
Hello with Nginx you are able to set the following with annotations:
nginx.ingress.kubernetes.io/auth-url: https://$host/oauth2/auth nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2/start?rd=https://$host$request_uri
What would be the equivalent of this but for istio?
I'm expecting the logs of OAuth to look like this
GET - "/oauth2/auth" HTTP/1.1
and not this
GET - "/"
I'm getting a 404 on my pages when using Oauth2 GitHub.
What I have:
HCP Vault in Development mode
Simple Spring Client using Spring Cloud Vault
CLI Client
Desried Outcome:
Inject data into a variable using HCP Vault
What is working:
Run Vault locally (in dev mode) and inject data into the variable
Get the data from the HCP Vault using vault CLI
Notes:
I'm generating the admin token to avoid the use of policies
The secrets in HCP Vault and my local Vault are identical
This is my application.yml file:
spring.application.name: my-spring-boot-app
spring.cloud.vault:
host: vault-cluster-public-vault-fjkdsahfdjksa.hfjksdfhdsajk.hashicorp.cloud
port: 8200
scheme: https
authentication: TOKEN
token: hvs.fdsjfhdsakjfhdasjkfhdasjkfhdasjkfhdasjkfhdasjkfhdasjkfhdsakj
spring.config.import: vault://
logging.level.org: INFO
logging.level.com: INFO
The problem was that I was missing the namespace header.
spring.cloud.vault:
host: vault-cluster-public-vault-fjkdsahfdjksa.hfjksdfhdsajk.hashicorp.cloud
port: 8200
scheme: https
namespace: admin
authentication: TOKEN
token: ${VAULT_TOKEN}
spring.config.import: vault://
Good day,
could you help me to fix a little issue with integration Keycloak SSO with Kubernetes Dashboard?
I’m trying to do the following steps:
Keycloak configurations:
create a new Realm - Kubernetes
create client ID with internal sing in, generate Client ID - Kubernetes
create mapper group in Client
created user and group
Keycloak-gatekeeper (Proxy):
--discovery-url={{ .Values.keycloakProxy.serverHost }}
--redirection-url=https://{{ .Values.ingress.host.name }}
--upstream-url=https://{{ .Release.Name }}.{{ .Values.namespace }}.svc.cluster.local
--client-secret={{ .Values.keycloakProxy.clientSecret }}
--client-id=kubernetes
--listen=0.0.0.0:3000
--enable-refresh-tokens=false
--skip-upstream-tls-verify
--skip-openid-provider-tls-verify
--enable-logging=true
--enable-json-logging=true
--resources=uri=/*
--secure-cookie=false
--verbose
Kubernetes RBAC:
created the RBAC role name with the same name as in Keycloak
After that I’m trying to authenticate to k8s dashboard using and get the following problem:
After secseessfull authorization, Kubernetes Dashboard sends me 401 as an Unauthorised User.
I have a sample application (web-app, backend-1, backend-2) deployed on minikube all under a JWT policy, and they all have proper destination rules, Istio sidecar and MTLS enabled in order to secure the east-west traffic.
apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
name: oidc
spec:
targets:
- name: web-app
- name: backend-1
- name: backend-2
peers:
- mtls: {}
origins:
- jwt:
issuer: "http://myurl/auth/realms/test"
jwksUri: "http://myurl/auth/realms/test/protocol/openid-connect/certs"
principalBinding: USE_ORIGIN
When I run the following command I receive a 401 unauthorized response when requesting the data from the backend, which is due to $TOKEN not being forwarded to backend-1 and backend-2 headers during the http request.
$> curl http://minikubeip/api "Authorization: Bearer $TOKEN"
Is there a way to forward http headers to backend-1 and backend-2 using native kubernetes/istio? Am I forced to make application code changes to accomplish this?
Edit:
This is the error I get after applying my oidc policy. When I curl web-app with the auth token I get
{"errors":[{"code":"APP_ERROR_CODE","message":"401 Unauthorized"}
Note that when I curl backend-1 or backend-2 with the same auth-token I get the appropriate data. Also, there is no other destination rule/policy applied to these services currently, policy enforcement is on, and my istio version is 1.1.15.
This is the policy I am applying:
apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
name: default
namespace: default
spec:
# peers:
# - mtls: {}
origins:
- jwt:
issuer: "http://10.148.199.140:8080/auth/realms/test"
jwksUri: "http://10.148.199.140:8080/auth/realms/test/protocol/openid-connect/certs"
principalBinding: USE_ORIGIN
should the token be propagated to backend-1 and backend-2 without any other changes?
Yes, policy should transfer token to both backend-1 and backend-2
There is a github issue , where users had same issue like You
A few informations from there:
The JWT is verified by an Envoy filter, so you'll have to check the Envoy logs. For the code, see https://github.com/istio/proxy/tree/master/src/envoy/http/jwt_auth
Pilot retrieves the JWKS to be used by the filter (it is inlined into the Envoy config), you can find the code for that in pilot/pkg/security
And another problem with that in stackoverflow
where accepted answer is:
The problem was resolved with two options: 1. Replace Service Name and port by external server ip and external port (for issuer and jwksUri) 2. Disable the usage of mTLS and its policy (Known issue: https://github.com/istio/istio/issues/10062).
From istio documentation
For each service, Istio applies the narrowest matching policy. The order is: service-specific > namespace-wide > mesh-wide. If more than one service-specific policy matches a service, Istio selects one of them at random. Operators must avoid such conflicts when configuring their policies.
To enforce uniqueness for mesh-wide and namespace-wide policies, Istio accepts only one authentication policy per mesh and one authentication policy per namespace. Istio also requires mesh-wide and namespace-wide policies to have the specific name default.
If a service has no matching policies, both transport authentication and origin authentication are disabled.
Istio supports header propagation. Probably didn't support when this thread was created.
You can allow the original header to be forwarded by using forwardOriginalToken: true in JWTRules or forward a valid JWT payload using outputPayloadToHeader in JWTRules.
Reference: ISTIO JWTRule documentation
I'm using Keycloak (latest) for Auth 2.0, to validate authentication, provide a token (JWT) and with the token provided, allows the access to the application URLs, based in the permissions.
Keycloak is currently running in Kubernates, with Istio as Gateway. For Keycloak, this is the policy being used:
apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
name: application-auth-policy
spec:
targets:
- name: notification
origins:
- jwt:
issuer: http://<service_name>http.<namespace>.svc.cluster.local:8080/auth/realms/istio
jwksUri: http://<service_name>http.<namespace>.svc.cluster.local:8080/auth/realms/istio/protocol/openid-connect/certs
principalBinding: USE_ORIGIN
An client was registered in this Keycloak and a RSA created for it.
The issuer can generates a token normally and the policy was applied successfully.
Problem:
Even with everything set, the token provided by Keycloak has the signature invalid according to JWT Validator.
This token doesn't allow any access for the URLs, as it should be, with 401 code.
Anyone else had a similar issue?
The problem was resolved with two options:
1. Replace Service Name and port by external server ip and external port (for issuer and jwksUri)
2. Disable the usage of mTLS and its policy (Known issue: https://github.com/istio/istio/issues/10062).