Context :
ElastAlert v0.1.29 included in Container Docker on OpenShift Orchestrator
Elasticsearch 2.4.4 exposed by Openshift agregate_logging (with Oauth2)
Hello,
From Elastalert, i want to connect to Elasticsearch.
The authenticate of Elastic use oauth2.
The oauth2 requires the X-Proxy-Remote-User and the token in the header of the requests :
Ex:
curl -k -H "Authorization: Bearer $token" -H "X-Proxy-Remote-User: $(oc whoami)" -H "X-Forwarded-For: 127.0.0.1" https://es.example.test/_cat/indices
I believe that ElastAlert doesn't support the authenticate Oauth2 by token. Can you confirm?
Effectively, i don't think that client_key and client_cert tls options they are compatible ?
Thanks for your help
Regards
Loïc
From what I've read of the code, no, it only supports basic auth. This would be a nice feature if someone had the time to contribute.
Related
I need to get information about a VM using curl with REST calls. I have this information where 1701 is the VM ID
GET /api/v1/vms/1701 HTTP/1.1
Host: vmlam.ral.sf.com
Authorization: Token token=4210
I tried this in cygwin but it did not work
c:/curl-7.69.0-win64-mingw/bin/curl -X GET -d '{Authorization: Token token=4210}' 'https:/vmlam.ral.sf.com//api/v1/vms/1701'
curl: (60) SSL certificate problem: unable to get local issuer
certificate More details here: curl.haxx.se/docs/sslcerts.html curl
failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this
situation and how to fix it, please visit the web page mentioned
above.
That seems like a certificate issue, you can skip the check with the option -k (or --insecure)
From curl documentation (man curl):
-k, --insecure
(TLS) By default, every SSL connection curl makes is verified to be secure. This option allows curl to proceed and operate even for server connections other‐
wise considered insecure.
The server connection is verified by making sure the server's certificate contains the right name and verifies successfully using the cert store.
See this online resource for further details:
https://curl.haxx.se/docs/sslcerts.html
See also --proxy-insecure and --cacert.
I have read the documentation on Kafka security here: https://kafka.apache.org/documentation/#security_authz_cli
and I was wondering something about the ports they use. For the authentication portion, under 7.2 Encryption and authentication using SSL, they have the statement:
kafka-console-producer.sh --broker-list localhost:9093 --topic test --producer.config client-ssl.properties
kafka-console-consumer.sh --bootstrap-server localhost:9093 --topic test --consumer.config client-ssl.properties
for the use cases of the console consumer and producer.
For the authorization portion, under 7.4 Authorizations and ACL, when showing on how to add to ACLs different permissions for different users, they have the phase:
bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add --allow-principal User:Bob --allow-principal User:Alice --allow-host 198.51.100.0 --allow-host 198.51.100.1 --operation Read --operation Write --topic Test-topic
So my question is, for the "broker-list" and "bootstrap-server" variable in the authentication portion and the "zookeeper.connect" variable in authorization, does the port and localhost have the be the same? It isn't in the examples given and I'm trying to combine the authentication and authorization parts using SSL. Is they need to be the same or do not need to be the same, why? Any documentation / tutorial on how to do this using purely console only is appreciated. I don't want to use Kerebos.
I want to use Cloudify 3.1 with my Openstack in my company.
Unfortunately, I had the prolem that the keystone authentication failed.
When I see the log,it says,"SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"
I think it is HTTPS that make it failed. I see the curl below.
curl -i 'https://identity.example.com/v2.0/tokens' -X POST -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-novaclient" -d '{"auth": {"tenantName": "xxxx", "passwordCredentials": {"username": "xxxx", "password": "xxxxx"}}}'
HTTP/1.0 200 Connection Established
Proxy-agent: Apache
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
How can I make the curl succeed without using -k or --insecure?
OR IF ANYONE HAS THE EXPERIENCE TO DO WITH openstack THAT KEYSTONE IS USING HTTPS WHEN INSTALLING Cloudify?
Using Openstack services with insecure SSL certificates is not possible in Cloudify 3.1. However, in Cloudify 3.2 it's possible to pass the --insecure (or ca_cert) flags directly to be used by the Openstack clients.
You can read the documentation for this feature here:
http://getcloudify.org/guide/3.2/plugin-openstack.html#openstack-configuration
So, for example, to use Nova service with insecure certificate, your Openstack configuration could look something like this:
openstack_config:
...
custom_configuration:
nova_client:
insecure: true
Hope this helps.
The SSL certificate could be invalid for a number of reasons. I've even seen where people forgot to reload the web server after updating the certificate. But, it is telling you what the overall problem is - you need a valid SSL certificate that is installed correctly.
Using curl -k or curl --insecure is perfectly fine in a development environment. For production, you can use an SSL Checker to test the SSL certificate and find out why it is being reported as invalid.
Recently,I look the github of cloudify.
They are resolving my problem,the problem linkenter link description here
the work is on progressing.
I've got problems connecting secure (SSL) to an IBM LDAP server using an openLDAP client.
A connection like the following, which is not using SSL works fine:
ldapsearch -h <LDAP server host name> -D <bind dn> -w ? -b <base dn> <filter>
But when I add the -Z option to use a secure LDAP connection (SSL) like shown in the following ldapsearch an error occours:
ldapsearch -h <LDAP server host name> -Z -D <bind dn> -w ? -b <base dn> <filter>
The error says:
ldap_simple_bind: Can't contact LDAP server
Attempted communication over SSL.
The extended error is 116.
Here I found out that I have to add ssl start_tls to the clients configuration file (ldap.conf) to enable SSL in openLDAP: http://www.openldap.org/faq/data/cache/185.html
After reading the description above I'm not sure if the author is dealing with an openLDAP client and an openLDAP server and if this is the only change that have to be made to make the connection work.
Does anybody here know if it is possible to connect from an openLDAP client to an IBM LDAP server using an SSL connection?
Does anybody have experience with this topic?
Thanks a lot!
As far as I know, OpenSSL no longer provides CA signer certificates in its trust store (i.e., CA cert file). Therefore, you will have to configure OpenLDAP's ldapsearch through the file .ldaprc or ldap.conf to specify the location of the trust store that has the signer certificates for your LDAP server. Something like this:
TLS_CACERT /usr/ssl/certs/my.ldapserver.certs.pem
# TLS_CACERTDIR /usr/ssl/certs/
TLS_REQCERT never|allow||try|demand|hard
See
http://www.openldap.org/software/man.cgi?query=ldap.conf&format=html
http://www.openldap.org/faq/data/cache/185.html
for more details.
IBM's website has a discussion of this error.
A number of possibilities, mostly server side, about keys not being in the keystore, expired, or not using port 636. So you can look at this and see if it helps you.
I recently updated restlet to version 2.1 and I'm no longer able to get the client certificate. I'm using the new way to get client certificate
List<Certificate> r = getRequest().getClientInfo().getCertificates();
I'm using CURL to send my authentication info
curl -k -E admin.pem https://localhost:8111/profile -v
Any idea why this doesn't work in restlet 2.1 ?
You should upgrade to version 2.2 which changed the internal HTTP connector and should restore this property.