I'm facing this issue since some days ago, and is the following:
I'm trying to start my kubernetes master using hypercube,
but the documentation is missing how to pass the etcd credentials to kubernetes in order to use a given user.
In the api-server configuration I have something like this:
- --etcd-servers=http://root:toor#etcd2-0.server:2379,http://root:toor#etcd2-1.server:2379,http://root:toor#etcd2-2.server:
Which is the only possible way to set the basic auth parameters of etcd.
(This works great for both etcdctl and etcd REST API.)
But I'm getting the following error:
F0915 17:25:35.579278 1 controller.go:86] Unable to perform initial IP allocation check: unable to persist the updated service IP allocations: 110: The request requires user authentication (Insufficient credentials) [0]
My etcd is refusing to write into /registry (which is the default folder), but root:toor are the right credentials.
I couldn't find any other configuration parameters for this, and I REALLY, REALLY need to secure my etcd with roles/users.
Please, I need some ideas / solutions if possible.
Related
We are having some difficulty when adding basic authentication to Solr 8.6.1. We are following this document, and we have created security.json file, which is successful (since Solr instance will ask userId and password when it starts.) Our difficulty happens when trying to enable the global authentication settings: we did pass the -Dsolr.httpclient.builder.factory=org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory system property,and we also set the -Dbasicauth=username:password property as follows:
// the following is the last time of our Solr Dockerfile:
CMD ["solr-foreground", "-Dsolr.httpclient.builder.factory=org.apache.solr.client.solrj.impl.PreemptiveBasicAuthClientBuilderFactory", "-Dbasicauth=username:secret"]
However, the calls to retrieve data from Solr all come back with Error 401 require authentication.
Could someone please kindly let us know what did we miss?
You'll have to set the correct options on the client - not on the server. This is a setting that affects how the client that connects to Solr authenticates.
So when running your application, give the parameter to the java command (or configure it to be the default parameter through ant/maven/gradle/etc.
Setting it on the docker container will not do anything useful.
I have Data Virt running via the standalone.sh script, and can log in with my username and password. My next task is configuring it so that it automatically runs whenever the instance is up and running (without having to execute standalone.sh), and uses SSL (port 443) rather than my username and password to log me in. I added the vault.keystore, dv_keystore.jks, and dv_truststore.jks files, and modified both standalone.sh and standalone.xml, according to the JBoss and other online documentation, to account for using these files. I start the standalone.sh script, which runs without any errors. When I browse to:
http://<IP>:8443/dashboard
after starting standalone.sh, I get the following error:
This page can't be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://:8443 again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4, which is not considered secure. Please contact your site administrator.
The settings Use TLS-1.0-ON, Use TLS-1.1-ON, and Use TLS-1.2-ON are all checked in the Browser properties.
By contrast, when I browse to
http://<IP>:8443/dashboard
when standalone.sh is not running, I get the following:
This page can't be displayed
- Make sure the web address https://:8443 is correct.
- Look for the page with your search engine.
- Refresh the page in a few minutes.
It appears the browser is sensing something going on when standalone.sh is running, but something is not allowing the browser to access the dashboard.
What am I missing here?
Have you validated any other ssl access? Is it just an issue with the dashboard application?
I tried posting this on ask.openstack but it has been stuck in the moderator for 5 days now. I thought I'd try here.
I was trying to debug a Nova issue and wanted to decode the SSL / TLS packets being exchanged using Wireshark. Part of the changes I was making was setting Nova up to use SSL / TLS and I wanted to be sure that part of it I had set correctly. I eventually figure out my issues from the various log files but I'm somewhat assuming that being able to watch the network traffic may help in some very difficult cases.
The exchange uses TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 at one point. According to this security stackexchannge question, there is a "pre-master secret" or various other terms. I've wrestled with this before in a previous life doing IPSec. Usually you can set debug in the application and it will spew out the secret into the log file. I tried "debug = true" under Default in nova.conf and got lots of debug but no secret. There was two items that looked interesting that were reported as **** in the log: keystone_authtoken.memcache_secret_key and neutron.metadata_proxy_shared_secret. I wasn't sure if those were the secrets I was looking for or not. In this case, I'm looking at the nova-api traffic going to port 8774.
Also, since all of openstack is Python and uses the same "request" and "certifi" packages, it may be possible to generalize this to all of the openstack components.
nova --version report 9.1.1
I am trying to do a xdmp:http-post to a third party URL using the Marklogic (v7.0) query console. The URL is a https:// url and I was able to install the necessary certificate from the admin console. When I run the post, I am receiving the following error:
[1.0-ml] SVC-SOCCONN: xdmp:http-post("https://xxxxx.............", ()) -- Socket connect error: SSL_connect XXX.XXX.XXX.XX:60855-XX.XX.X.XX:443: key size too small (0x0506706e); DH lib (0x14098005)
Can you please assist me here as to what I might be doing wrong? Do I need to follow any additional steps apart from installing the certificate?
Please let me know if I need to supply additional information.
The server's certificate is using a key size that is too small, and therefore considered to be insecure. Since the host name suggests it's a dev machine, the best thing would be to have them use a longer key if you can.
If that's not possible, you can disable FIPS mode on your MarkLogic server. That can be done through the Admin UI by navigating to http://your.host.name:8001/cluster-admin.xqy?section=cluster&local-cluster=true and setting "ssl fips enabled" to false. Be aware that if you do this, the server will allow you to use ciphers and key lengths that are considered weak.
I have been trying to make an application which needs to bind to LDAP server using GSSAPI using the ticket provided by the Kerberos server. I am using Novell's JLDAP library for this purpose.
I am able to get a ticket from the authentication server but when I try to bind to the Service Server(LDAP in my case ), I get GSSException: Major Status: (589824, Invalid token was supplied), Minor Status: (0, Unknown error)
and the bind fails.
The AS(Authentication Server) and SS(Service Server(LDAP server)), both are behind a single proxy.
In this case, do they need mutual authentication?
I not sure but it seems my java code is not able to get/recognize/decrypt the token recieved from the AS(Authentication Server).
I am providing the mechanism name as "GSSAPI" in the SASL bind method of Novell's LDAPConnection.java
Did anyone face this kind of trouble? What would be the cause and probable solutions for this? Please explain.
Have you configured eDirectory to support GSSAPI?
Errors for GSAPPI show in the ndsd.log file on the eDirectory server.
You can also enable +LDAP and +NMAS trace in ndstrace to see all communications for GSAPPI.
This may also be helpful.