https://www.gooddata.com/ logo
Join Slack
Powered by
I was able to create the org but getting error lik...
# gooddata-cn
n
I was able to create the org but getting error like below when try to bring up the organization url ( ingress url masked)
Copy code
Unregistered redirect_uri ("<http://k8s-ingressn-ingressn-888888888888888.elb.us-east-2.amazonaws.com/login/oauth2/code/k8s-ingressn-ingressn-888888888888888.elb.us-east-2.amazonaws.com>").
j
Hello Neeraj, There is an article published HERE about how to resolve this error. Could you please give this a try and let us know how you get on?
n
Thanks. I will try that
I have exactly this config mentioned in above article when I got the error.
Copy code
# helm-charts/helmfile-values/values-ingress.yaml
controller:
  allowSnippetAnnotations: true
  config:
    # This resolves possible issue with big headers
    proxy-buffer-size: '16k'
    # Improve performance of requests with large body
    client-body-buffer-size: '1m'
    # use X-Forwarded-* received from ELB - important for proper propagation
    # of LoadBalancer host, port, and schema
    use-forwarded-headers: 'true'
I got that from here. https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/cloud-native/considerations/ingress-aws/
r
Hi Neeraj, Radek from the GoodData Technical team here, checking into this now and will keep you updated!
r
Hi, let's summarize how you configuration looks like: • you have ELB that terminates SSL traffic, with valid SSL certificate stored in ACM, HTTPS protocol exposed on port 443. • Ingress-nginx controller with settings as described in our docs, especially 
use-forwarded-headers
set to 
'true'
• Created organization with hostname matching your SSL certificate, resolvable to IP address(es) of your ELB. • You kept default value in gooddata-cn helm chart 
deployDexIdP: true
), so you're using Dex as identity provider • You configured dex.ingress.authHost in values to something like 
<http://auth.example.com|auth.example.com>
When you navigate to your ogranization url (e.g. 
<https://organization-1.example.com/>
), you get redirected to 
<https://auth.example.com/dex/auth/local/login>
but error occurs "Unregistered redirect_uri" mentioning the loadbalancer hostname and http:// schema (not https://), instead of being redirected to 
<https://organization-1.example.com/login/oauth2/code/organization-1.example.com>
Is that correct?
n
Every thing correct except I did not mention 
deployDexIdP: true
since it was mentioned in docs that default is true for internal OIDC. https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/cloud-native/considerations/oidc/#OIDCProviderSetup-Usin[…]nalOIDCIdentityProvider
I redeployed gooddata-cn after setting 
deployDexIdP: true
. still the same error. However one thing I have been noticing since yesterday that when I enter the host url, it redirects to auth url.. but in the redirection url , if I edit the url in browser bar, to https, I get login page ( though login does not work.. I get 401 error). see the example of the URL that gives direct uri error ( I have masked the url for our company/env part)
Copy code
<https://gooddata-test-auth.myenv.mycompany.net/dex/auth/local?client_id=9d5c4d19-df5c-4735-abf0-04f6d608a0d2&nonce=kk5shN0reDjSruylmUydQ8fQ90yW9qSYCK36QnoeVp0&redirect_uri=http%3A%2F%2Fgooddata-test.myenv.mycompany.net%2Flogin%2Foauth2%2Fcode%2Fgooddata-test.myenv.mycompany.net&response_type=code&scope=openid+profile&state=eB10R9uwXOUkjhJ1pFFcvffsQQ_p9_IvsUeOPcL2PFQf>
But below one gives me login page
Copy code
<https://gooddata-test-auth.myenv.mycompany.net/dex/auth/local?client_id=9d5c4d19-df5c-4735-abf0-04f6d608a0d2&nonce=kk5shN0reDjSruylmUydQ8fQ90yW9qSYCK36QnoeVp0&redirect_uri=https%3A%2F%2Fgooddata-test.myenv.mycompany.net%2Flogin%2Foauth2%2Fcode%2Fgooddata-test.myenv.mycompany.net&response_type=code&scope=openid+profile&state=eB10R9uwXOUkjhJ1pFFcvffsQQ_p9_IvsUeOPcL2PFQf>
Notice the diffrence in above uri for this part 
redirect_uri=https
r
Yes, 
deployDexIdP: true
is the default value in our helm chart. You don't need to set it explicitly. I just wanted to make sure you didn't disable it.
redirect_uri
is generated by Spring framework library based on information received in the incoming request. In this particular case, header "X-Forwarded-Proto" is not set to "https" or is not set at all. It's LoadBalancer's or Ingress controller's responsibility to set this header. As you have SSL terminated on ELB, Load balancer should set this header (along with other 
X-Forwarded-*
headers) when passing your request donwstream to ingress controller. Controller's setting "use-forwarded-headers" guarantees these headers are sent unmodified to internal services. Can you please check the headers are properly set when leaving your load balancer?
there might also be issue in nginx-ingress configuration. Can you please collect diagnostics information as described in https://community.gooddata.com/administration-kb-articles-49/gooddata-cn-collecting-diagnostics-support-bundle-363 and share the result with me via DM? I will review your setup to see if there are some issues that might cause the redirect_uri to be generated with wrong URL schema.
n
Thanks. Let me take a look and get back to you
Regarding setting the X-Forwarded-Proto on nginx contoller, I took a look at the file which I have following this doc https://www.gooddata.com/docs/cloud-native/3.3/deploy-and-install/cloud-native/considerations/ingress-aws/, I do not have X-Forwarded-Proto set up. is there anyway I can set that up in that yaml file or do I need to do it separately ?
I was able to make it work by totally deleting the LB and nginx controller .. previously it created the NLB..and this time ELB ( not ALB) and that made it work
One question though.. why ingress-conroller install created ELB ( elb v1) and not ALB ( elb v2)..is there anyway to switch to ALB by adding some option in that helm file
Getting different error now while creating the dashboard.. I will DM you with log file
r
It's possible to reconfigure nginx ingress controller so it will work with Network Load Balancer (NLB) instead of ELB. Since NLB operates on Layer 4 of ISO/OSI model, you'll need to terminate SSL in k8s cluster (on ingress controller). Simply create Secret with SSL certificate and key and use this secret in ingresses you create. Organizations can also refer to ssl secrets, as described in docs. Also, install "AWS LoadBalancer controller" that will install the NLB based on annotations assigned to ingress-controller Service. ALB is not supported, because ALB doesn't support URL rewrites based on regex rules. Theoretically, it is possible to run ALB in front of Nginx ingress controller, but such setup is rather uncommon. Example configuration can be found on the Internet.
2 Views
Open in Slack
PreviousNext
Powered by