When a request is denied the reply back is:
HTTP 403
RBAC: access denied
Is there any way of customising this error to have a different status code and reply body?
It is currently not possible with Istio API, however there is a feature request for that on Github.
There is also a workaround using an envoy filter to customize that response.
Note, however, that Envoy filters are low-level constructs compared to Istio API and Istio doc says:
This feature must be used with care, as incorrect configurations could potentially destabilize the entire mesh.
Related
I have an application that already works using Kinesis. The application uses AWS Session Credentials but we are switching to using either AWS Session Credentials or Web Identity Token (software.amazon.awssdk.auth.credentials.WebIdentityTokenFileCredentialsProvider) depending on the deployment environment.
When I add in the code to use WebIdentityTokenFileCredentialsProvider I get the stacktrace below. I can't provide the code but rest assured I'm setting an HTTP client for Kinesis. But if you look at the stacktrace it shows that a default HTTP client is being configured via the Provider deep within the AWS SDK code. I have no influence over the Credentials Provider setting the HTTP client as the WebIdentityTokenFileCredentialsProvider doesn't give me a way to tell it that I don't need a default HTTP client being set.
I know one option is to create my own implementation of the WebIdentityTokenFileCredentialsProvider but I'd rather not do that.
Question: What else can I do to work around this?
Caused by: software.amazon.awssdk.core.exception.SdkClientException: Multiple HTTP implementations were found on the classpath. To avoid non-deterministic loading implementations, please explicitly provide an HTTP client via the client builders, set the software.amazon.awssdk.http.service.impl system property with the FQCN of the HTTP service to use as the default, or remove all but one HTTP implementation from the classpath
at software.amazon.awssdk.core.exception.SdkClientException$BuilderImpl.build(SdkClientException.java:102)
at software.amazon.awssdk.core.internal.http.loader.ClasspathSdkHttpServiceProvider.loadService(ClasspathSdkHttpServiceProvider.java:62)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at java.base/java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:1002)
at java.base/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:129)
at java.base/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:527)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:513)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at java.base/java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:150)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:647)
at software.amazon.awssdk.core.internal.http.loader.SdkHttpServiceProviderChain.loadService(SdkHttpServiceProviderChain.java:44)
at software.amazon.awssdk.core.internal.http.loader.CachingSdkHttpServiceProvider.loadService(CachingSdkHttpServiceProvider.java:46)
at software.amazon.awssdk.core.internal.http.loader.DefaultSdkHttpClientBuilder.buildWithDefaults(DefaultSdkHttpClientBuilder.java:40)
at software.amazon.awssdk.core.client.builder.SdkDefaultClientBuilder.lambda$resolveSyncHttpClient$7(SdkDefaultClientBuilder.java:343)
at java.base/java.util.Optional.orElseGet(Optional.java:364)
at software.amazon.awssdk.core.client.builder.SdkDefaultClientBuilder.resolveSyncHttpClient(SdkDefaultClientBuilder.java:343)
at software.amazon.awssdk.core.client.builder.SdkDefaultClientBuilder.finalizeSyncConfiguration(SdkDefaultClientBuilder.java:282)
at software.amazon.awssdk.core.client.builder.SdkDefaultClientBuilder.syncClientConfiguration(SdkDefaultClientBuilder.java:178)
at software.amazon.awssdk.services.sts.DefaultStsClientBuilder.buildClient(DefaultStsClientBuilder.java:27)
at software.amazon.awssdk.services.sts.DefaultStsClientBuilder.buildClient(DefaultStsClientBuilder.java:22)
at software.amazon.awssdk.core.client.builder.SdkDefaultClientBuilder.build(SdkDefaultClientBuilder.java:145)
at software.amazon.awssdk.services.sts.internal.StsWebIdentityCredentialsProviderFactory$StsWebIdentityCredentialsProvider.<init>(StsWebIdentityCredentialsProviderFactory.java:71)
at software.amazon.awssdk.services.sts.internal.StsWebIdentityCredentialsProviderFactory$StsWebIdentityCredentialsProvider.<init>(StsWebIdentityCredentialsProviderFactory.java:55)
at software.amazon.awssdk.services.sts.internal.StsWebIdentityCredentialsProviderFactory.create(StsWebIdentityCredentialsProviderFactory.java:47)
at software.amazon.awssdk.auth.credentials.WebIdentityTokenFileCredentialsProvider.<init>(WebIdentityTokenFileCredentialsProvider.java:86)
at software.amazon.awssdk.auth.credentials.WebIdentityTokenFileCredentialsProvider.<init>(WebIdentityTokenFileCredentialsProvider.java:46)
at software.amazon.awssdk.auth.credentials.WebIdentityTokenFileCredentialsProvider$BuilderImpl.build(WebIdentityTokenFileCredentialsProvider.java:200)
I have a soap service deployed on wso2 apim 4.0.0. While working with the api I randomly (rarely) get an error - "Content is not allowed in prolog". Is there any component of the configuration to be tuned to overcome this issue? Another version of the cause of this error, I found out in the article, this might be caused by a consumer that is not able to properly invoke the api. Any hint to find out the root of the problem is appreciated.
Enable wire logs[1] and check whether the backend is sending a corrupted response while you are reproducing the issue.
A corrupted response means such as a chunked response but, the Content-Length header is available in the response.
You can compare the wire logs for both the happy path and the issue scenario.
[1] https://apim.docs.wso2.com/en/latest/integrate/develop/using-wire-logs/
So I had a working mTLS service mesh until one of the services got updated with some header manipulation logic. This logic was getting the headers from the request the service got, and then adding those headers to the request this service was making to another one.
With this logic in place, mTLS was broken between this service and the next one, and if I activate PERMISSIVE mode, connection works as usual.
So then I went to this service’s container and did a curl request to the next service but without the Host Header and the request came through.
So, same request, just that without Host header mtls works, and with host header it doesn’t.
I would like to know the reason why this happens. Is it related with mTLS and how both services are trusting each other?
Thanks
I think that the best way to approach this issue would be to analyze the differences between services' versions before and after the header manipulation logic.
In order to dump headers' request you can use the helper httbin server from Istio official doc here.
You can find more info regarding how to use it here.
Please let me know if that helped.
I am trying to test OAuth2 authentication using Django 1.11.4 and Django OAuth Toolkit. After following the tutorial (like, literally verbatim) the consumer application on heroku refuses to exchange the code generated in order to grant me an authentication token with a non-specific error.
After much fiddling, I found out that even on DEBUG configuration the OAuth framework would through an insecure transport protocol exception (as it was through local Django server which uses http not https). Thus I ported the web application to an apache instance which was SSL enabled but still the consumer app throws me an unspecified error.
Please do note that I am following verbatim the tutorial outlined here and the heroku application when I have my secret key and everything setup as shown in the docs. Although the authorization link (and database entry) is generated when I go back to exchange the code for a token things fail, with a non-specific error. The result looks like this (the full server address is omitted due to obvious reasons).
Any idea on what might be wrong?
I have a similar error when using http for localhost, and I suspect that it is the same issue. I am using Chrome, and in the Network tab I can see that the POST to /o/token throws a CORS error. Looking into the JavaScript Console
Access to XMLHttpRequest at 'http://localhost:8000/o/token/' from origin 'http://django-oauth-toolkit.herokuapp.com' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `local`.
POST http://localhost:8000/o/token/ net::ERR_FAILED
This is a Chrome security setting:
Block insecure private network requests.
Prevents non-secure contexts from making subresource requests to
more-private IP addresses. See also:
https://developer.chrome.com/blog/private-network-access-update/
This blocks http sites from accessing localhost. To remove that block (for testing purposes), open a browser tab with chrome://flags/#block-insecure-private-network-requests and disable the flag.
Interestingly enough the Heroku app supports https, which would solve the issue, but it incorrectly hardcodes the redirect url to http: http://django-oauth-toolkit.herokuapp.com/consumer/exchange/
I am trying to make a call to Riak cluster using a web service. I have observed that Riak web console is using http://localhost:8098/admin/cluster to make calls to the Riak.
The problem is that when I try to execute a PUT command from Postman to http://localhost:8098/admin/cluster I have a 403 error message.
Does anybody confronted with this issue ?
You are not supposed to use the REST APIs used by Riak console. I've already answered your other question about it. HTTP error 403 Forbidden means you are not properly authenticated (and not authorized to call the API), i.e. you are not passing the right HTTP header. I believe Riak console uses a cookie to ensure the APIs are invoked from the console's context. Looking at Riak console requests, I can see that X-Csrf-Token is being passed.