I am using the latest confluent images (5.1.0) and externalized OracleDB passwords for Connect configurations in vault. I am able to successfully register the custom config provider for vault with following configuration.
"connection.password": "${vault:vault_path:vault_db_password_key}"
When I do a GET connector request, the connection.password in the response is the resolved password and it is shown as such and was not hidden. But in logs, I could see it as
connection.password = [hidden]
Please let me know if this issue is handled as part of KIP-297 or if I am missing something?
Not sure if this answers your question, but there is no such Credential provider for vault:, by default, there is only file:, so unless you've written your own (or found one elsewhere), then that won't work.
Related
After successfully setting up a cloud config server and confirming that all works as expected I ran into this issue but I'm not sure if it's supported or the best way to go.
We follow the database-per-service pattern so as an experiment I committed a dev and staging file containing the db connection details of each service so that if we needed to make changes to the server address and credentials we only needed to do it in the config repo.
I have set this up correctly and I confirm that the changes are indeed being propagated from the config server to the clients.
It was only after doing all of this did I notice that even though the services got the updated database details it DID NOT switch its connection.
Is this possible? The only way I could do this was if I restarted the service and that kinda defeats the purpose of having all of this in place. I tried toying with the connection timeouts but it didn't help. The service was still connected to the previous connection.
So it appears a simple addition of the #RefreshScope to my controller did the trick. Thanks to Spring's David Syer for the insight.
Basic username/password authentication for ELK, i was able to achieve using searchguard on windows platform.
Now i am trying to establish secure communication. I have performed the following changes,
In elasticsearch.yml
searchguard.ssl.http.enabled: true
searchguard.ssl.http.keystore_filepath: D:\Softwares\ELK\elasticsearch-5.4.0\elasticsearch-5.4.0\config\CN=localhost-keystore.jks
searchguard.ssl.http.keystore_password: 221749a2add117cf889f
searchguard.ssl.http.truststore_filepath: D:\Softwares\ELK\elasticsearch-5.4.0\elasticsearch-5.4.0\config\truststore.jks
searchguard.ssl.http.truststore_password: 6d6cf1cc017dc874960b
searchguard.authcz.admin_dn:
- CN=sgadmin
searchguard.ssl.transport.keystore_filepath: D:\Softwares\ELK\elasticsearch-5.4.0\elasticsearch-5.4.0\config\CN=localhost-keystore.jks
searchguard.ssl.transport.keystore_password: 221749a2add117cf889f
searchguard.ssl.transport.truststore_filepath: D:\Softwares\ELK\elasticsearch-5.4.0\elasticsearch-5.4.0\config\truststore.jks
searchguard.ssl.transport.truststore_password: 6d6cf1cc017dc874960b
In Kibana.yml
elasticsearch.url: "https://localhost:9200"
elasticsearch.username: "admin"
elasticsearch.password: "admin"
If i login to kibana, using http://localhost:5601, it asks for username and password. I dont know what credentails to enter here. i tried admin/admin. Its not working. Before i gave searchguard.ssl.http.... configurations, admin/admin was working fine.
After i added all the searchguard.ssl.http related configuration, the credentails are not working.
I am sure there is some other configuration in kibana.yml w.r.t searchguard configuration. I am not able to find it online. Can any one please help me here on what is missing.
Enabling TLS on the REST layer does not have any impact on user authentication/authorisation. The only difference is:
If you enable TLS on REST layer, only HTTPS access is allowed. You will see an error message if you try to access ES with HTTP
If you disable TLS on REST layer, only HTTP access is allowed. You will see an error message if you try to access ES with HTTPS.
Search Guard will authenticate the credentials against the configured authentication backend in sg_config.yml. If you use the default configuration that ships with Search Guard, it will use the internal user database and the users defined in internal_users.yml. The default "admin" user has full access to all indices and types, so you should be able to use this user to log into Kibana. If you need a user with limited access, the corresponding demo user is "kibanaro". Please refer to internal_users.yml to see all demo users.
Since ES 5.0.2, you need to install the Search Guard Kibana plugin for full authentication and session support. You can find the plugin on the corresponding GitHub repository. You install it like any other Kibana plugin, for example:
bin/kibana-plugin install https://github.com/floragunncom/search-guard-kibana-plugin/releases/download/v5.4.3-3/searchguard-kibana-5.4.3-3.zip
If you do not need advanced stuff like multi-tenancy or JWT Single Sign-on, it should start and work out of the box.
If this does not help, please post the output of your Elasticsearch log files when trying to log in.
Disclaimer: I work for floragunn, makers of Search Guard.
I have an existing Datastax Cassandra setup that is working. We just added authentication to the system and now we can log in with our AD accounts. This is very nice and certainly works. However applications need to use a hard-coded username/password in order to connect.
In SQL Server we were able to setup a user to run the service as and then it would connect and work through AD. However in Cassandra it is not the same.
If I don't want to include usernames and especially passwords in my app.config files what are my options?
You can use authentication via LDAP with DSE (Datastax Enterprise), so the authentication stage is done with LDAP instead of the internal authentication in DSE which you're using at the moment. Note that my comments here apply to DSE5.0 onwards but you can use LDAP auth with earlier versions of DSE from 4.6 onwards.
The documentation (link below) covers this. The basic steps are as follows:
Configure your authenticator in the cassandra.yaml to use the DSE authenticator
authenticator: com.datastax.bdp.cassandra.auth.DseAuthenticator
Create an internal role in cassandra to map to the LDAP group(s) in your LDAP server using the CREATE ROLE command
Ensure all the users you need to use map to the relevant LDAP group (part of your LDAP config)
Configure your dse.yaml to have the correct settings for your LDAP server
Restart the DSE process for the settings to take effect
The following documentation gives some good examples and background information:
https://docs.datastax.com/en/latest-dse/datastax_enterprise/unifiedAuth/unifiedAuthConfig.html
https://docs.datastax.com/en/latest-dse/datastax_enterprise/sec/authLdapConfig.html
Note: when configuring the dse.yaml note the comment in the docs regarding user_search_filter:
When using Active Directory set the filter to (sAMAccountName={0})
I am trying to start an application in Websphere 8, and keep on getting the following error.
From the message, it means we are missing the bindPassword, but we never have to define in WAS 6.1
Currently we are using Standalone LDAP registry. Does anyone have any idea where I should start looking to fix this error?
UserManagemen E com.ibm.ws.wim.management.UserManagementProcess handleNo
tification CWWIM6004E Initialization of the dynamic reload manager failed.
com.ibm.websphere.wim.exception.MissingInitPropertyException: CWWIM0004E The initialization property 'bindPassword' is missing from the configuration.
at com.ibm.ws.wim.adapter.ldap.LdapConnection.initializeEnvironmentProperties(LdapConnection.java:194
7)
at com.ibm.ws.wim.adapter.ldap.LdapConnection.initializeServers(LdapConnection.java:1904)
at com.ibm.ws.wim.adapter.ldap.LdapConnection.initialize(LdapConnection.java:1832)
at com.ibm.ws.wim.adapter.ldap.LdapAdapter.initialize(LdapAdapter.java:235)
at com.ibm.ws.wim.RepositoryManager.initialize(RepositoryManager.java:610)
at com.ibm.ws.wim.RepositoryManager.<init>(RepositoryManager.java:131)
In regards to ".... never have to define in WAS 6.1"
The requirement for a LDAP bind password is enforced by the LDAP server, this is not a WAS requirement
If in fact you didn't define it in WAS v6.1, the LDAP server in use for WAS V6.1 didn't require it.
Based on the error, you've either changed LDAP servers or the LDAP server configuration has changed (or both)
As mentioned in the other post, you can troubleshoot this using a tool like ldapsearch
The technote at http://www-01.ibm.com/support/docview.wss?uid=swg21470063 discusses obtaining "must gather" and troubleshooting these types of issues (refer to the "collecting data manually" section)
You must check your ldap connection to the ldap server
User IBM WebSphere Console, Security settings, LDAP and take note about the LDAP connection settings.
Use a tool like ldapsearch in order to check the connection via shell command line.
It is possible that these bind password is not correct.
If you are using un Novell eDirectory Server you must take special attention in the bind user creation ( field password )
I have a standalone application that needs to connect to a Sybase database via a datasource, I'm trying to connect using getConnection() and get the connection from this Sybase datasource which is hosted in WAS 6.1, sadly I'm getting an error JZ004 -> Sybase(R) jConnect for JDBC(TM) Programmer's Reference: SQL Exception and Warning Messages
JZ004 error message is:
User name property missing in DriverManager.getConnection(..., Properties)
Action: Provide the required user property.
As you can see, this is not a connectivity (so we can discard JNDI or lookup problems), but rather a configuration problem. For my Sybase datasource in WAS 6.1 I have set up the proper authentication alias (Component-managed Authentication Alias), and I know the credentials are alright, "Test Connection" is successful for this datasource. Somebody had a similar problem and was because of the authentication alias-> http://forum.springsource.org/showthread.php?t=39915
Next, I tried calling getConnection() but now I provided the credentials like getConnection(user, password)... and this time it worked!!! So I suspect that somehow WAS 6.1 is not picking or taking the authentication info I set in the datasource as mentioned before.
If you think that maybe getConnection(user, password) should be OK for my case, well, that's not the case since I have a requirement to keep the credentials in the server, the standalone application only needs to know the JNDI information to lookup the datasource.
Please let me know if have faced a similar problem, or what would you suggest me to do.
Thanks.
In order to use the configured resource, you need to look it up rather than using DriverManager directly:
new InitialContext().lookup("myDS");
In another thread -> Call to DataSource.getConnection not returning the expected connection, I got an answer that also solved this issue, basically the answer is that an authentication alias won't work for external clients according to the J2C documentation. The workaround is to provide the user and password as custom properties instead of being provided as an authentication alias.