LDAP is not working for Bigbang Apps behind the istio

Description

I have deployed Bigbang Release 1.25.1. I have a LDAP server (FreeIPA) outside of the kubernetes cluster. I am trying to setup LDAP integration for Bigbang apps. Istio does not seem to support LDAP protocol. I get unable to open LDAP connection error from the pods. Are there any docs on how to setup LDAP integration for Bigbang Apps or if LDAP is supported option?

Below are the logs from Bigbang Sonarqube pod. Keycloak integration works as it is over https

INFO  web[][o.s.a.l.LdapContextFactory] Test LDAP connection: FAIL
ERROR web[][o.s.s.p.Platform] Background initialization failed. Stopping SonarQube
org.sonar.api.utils.SonarException: Security realm fails to start: Unable to open LDAP connection
	at org.sonar.server.user.SecurityRealmFactory.start(SecurityRealmFactory.java:93)
	at org.sonar.core.platform.StartableCloseableSafeLifecyleStrategy.start(StartableCloseableSafeLifecyleStrategy.java:40)
	at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.start(AbstractInjectionFactory.java:84)
	at org.picocontainer.behaviors.AbstractBehavior.start(AbstractBehavior.java:169)
	at org.picocontainer.behaviors.Stored$RealComponentLifecycle.start(Stored.java:132)
	at org.picocontainer.behaviors.Stored.start(Stored.java:110)
	at org.picocontainer.DefaultPicoContainer.potentiallyStartAdapter(DefaultPicoContainer.java:1016)
	at org.picocontainer.DefaultPicoContainer.startAdapters(DefaultPicoContainer.java:1009)
	at org.picocontainer.DefaultPicoContainer.start(DefaultPicoContainer.java:767)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
	at org.sonar.server.platform.platformlevel.PlatformLevel.start(PlatformLevel.java:90)
	at org.sonar.server.platform.platformlevel.PlatformLevel4.start(PlatformLevel4.java:581)
	at org.sonar.server.platform.PlatformImpl.start(PlatformImpl.java:213)
	at org.sonar.server.platform.PlatformImpl.startLevel34Containers(PlatformImpl.java:187)
	at org.sonar.server.platform.PlatformImpl.access$500(PlatformImpl.java:46)
	at org.sonar.server.platform.PlatformImpl$1.lambda$doRun$0(PlatformImpl.java:120)
	at org.sonar.server.platform.PlatformImpl$AutoStarterRunnable.runIfNotAborted(PlatformImpl.java:370)
	at org.sonar.server.platform.PlatformImpl$1.doRun(PlatformImpl.java:120)
	at org.sonar.server.platform.PlatformImpl$AutoStarterRunnable.run(PlatformImpl.java:354)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.sonar.auth.ldap.LdapException: Unable to open LDAP connection
	at org.sonar.auth.ldap.LdapContextFactory.testConnection(LdapContextFactory.java:214)
	at org.sonar.auth.ldap.LdapRealm.init(LdapRealm.java:63)
	at org.sonar.server.user.SecurityRealmFactory.start(SecurityRealmFactory.java:87)
	... 19 common frames omitted
Caused by: javax.naming.CommunicationException: simple bind failed: freeipa.dummy.io:636
	at java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
	at java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2895)
	at java.naming/com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:348)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxFromUrl(LdapCtxFactory.java:262)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:226)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:280)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:185)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:115)
	at java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:730)
	at java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
	at java.naming/javax.naming.InitialContext.init(InitialContext.java:236)
	at java.naming/javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
	at org.sonar.auth.ldap.LdapContextFactory.createInitialDirContext(LdapContextFactory.java:137)
	at org.sonar.auth.ldap.LdapContextFactory.createBindContext(LdapContextFactory.java:95)
	at org.sonar.auth.ldap.LdapContextFactory.testConnection(LdapContextFactory.java:210)
	... 21 common frames omitted
Caused by: java.net.SocketException: Connection or outbound has closed
	at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:1217)
	at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
	at java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
	at java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:414)
	at java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:387)
	at java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
	at java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
	... 35 common frames omitted

changed the description

changed the description

changed the description

@ryan.j.garcia I would appreciate any insight on this issue.

Hello @sipvw5 BigBang only officially supports SSO via OIDC and SAML as authentication mechanisms by default, that is why connections to port 636 for LDAP are not working as expected.

To facilitate this you would need to disable the networkPolicy toggle for BigBang or just the sonarqube package itself: networkPolicies.enabled=false.

If you do not want to toggle off all BigBang provided NetworkPolicy templates you can utilize Flux's Kustomization PostRenderer feature to alter a sonarqube networkPolicy to also allow 636 egress like so:

addons:
  sonarqube:
    postRenderers:
      - kustomize:
          patchesStrategicMerge:
            - kind: NetworkPolicy
              apiVersion: networking.k8s.io/v1
              metadata:
                name: allow-https-egress
                namespace: sonarqube
              spec:
                egress:
                - ports:
                  - port: 443
                    protocol: TCP
                - ports:
                  - port: 636
                    protocol: TCP

You can also stand up Keycloak in your cluster and it can be backed by an LDAP connection to import/sync users and groups and then use built in functionality to point apps to this Keycloak server via Single Sign On.

Thank you so much for the clarification. I appreciate it

I had another question regarding using LoadBalancer type service. Our external-ip field for the service is stuck on pending. is there a workaround for this as well? I have looked at the mutiple ingress docs which recommended us to use --cloud-provider flag

@sipvw5 which cloud-provider are you deploying within, and what distro is your cluster?

@ryan.j.garcia We are using AWS and running vanilla kubernetes cluster(v1.20.14+rke2r2) with ranchers(v2.5.3).

@ryan.j.garcia any update on this?

mentioned in issue #1140 (closed)

closed