I am wondering to encrypt the password for ssl setup of kafka cluster.
my current setup:
listeners=SSL://:9095, PLAINTEXT://:9094
ssl.keystore.location=keystore.jks
ssl.keystore.password=password
ssl.key.password=phoenix
ssl.truststore.location=keystore.jks
ssl.truststore.password=password
security.inter.broker.protocol=SSL
but I dont want to have a plain password , expecting the encrypted this password
I don't think kafka provides any option for storing encrypted password. This doc specifically says Since we are storing passwords in the broker config, it is important to restrict access via file system permissions.
The following worked for me:
Updating Password Configs Dynamically
Password config values that are dynamically updated are encrypted before storing in ZooKeeper. The broker config password.encoder.secret must be configured in server.properties to enable dynamic update of password configs. The secret may be different on different brokers.
Source: http://kafka.apache.org/documentation/#dynamicbrokerconfigs
Related
Is it possible to use Kafka with SSL encryption but with no server verification nor client authentication?
I know that by default the latter is disabled, but is it possible to also disable the former?
I encountered the similar problem. Since kafka is a java process, it will load the default jdk certs when running, which is under /usr/local/jdk/jre/lib/security/cacerts. if your server is trusted there, (in my scenario, my kakfa server is MSK, and is trusted already), then you don't have to config all the keys and certs.
So all in all, I only added kafka config of security.protocol=SSL and it worked.
I am using Redis to store the access token. I want to know if I need to encrypt the token before saving to redis. If yes then please explain why.I am using C# and Stackexchange.Redis library.
As it is stated in the security section of redis documentation
Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.
So it is better to secure the instance instead of every individual data in it. Redis doesn't support encryption, as you mentioned you need to handle in application layer. You need to wrap the commands by encrypt/decrypt methods.
For extra security, i think you must use authentication by setting password at configuration file. It can be a long one and will be saved in the configuration file so every command will require auth as a prerequisite.
If your concern is security of the instances communicating with redis, that's another topic. auth will not help just like encryption secret. Since both secrets are in the hand of attacker, he can retrieve the original data.
I'm working in a setting where storing plain-text passwords is not acceptable, neither in files nor in databases. The Corda Enterprise guide, section 7.6.3 on RPC security, states that passwords can be encrypted using Apache Shiro, by setting passwordEncryption = SHIRO_1_CRYPT. Is this setting applied to all passwords in node.conf, or just to the RPC passwords? If it applies only to RPC passwords, how can other passwords be secured? Other types of passwords include DBMS and keystore passwords.
You correctly identified that you need the following setting in your node configuration.
passwordEncryption = SHIRO_1_CRYPT
Take a look at this page, it outlines how to specify security configuration for your node password. You simply specify it for each node and then you should be all set.
https://docs.corda.net/docs/corda-enterprise/4.4/node/operating/clientrpc.html#password-encryption
I am working on an application where we need to create user with passwords within Open LDAP. The problem is i don't have a relevant certificate which i can add to the truststore. I will get this certificate in some time but i can't wait for that.
I know that in Active Directory if i want to do such a thing i must have a 128 bit SSL connection between client and server and i have to use unicodePwd attribute but i am guessing that for open ldap i don't need any ssl connection and the password would be saved in the attribute userPassword so i can add the user with password over port 389. Are my assumptions correct?
Can anybody please point me to setup openldap on windows environment as well as this will just be used for my own tests. Thanks
I am guessing that for open ldap i don't need any ssl connection and the password would be saved in the attribute userPassword so i can add the user with password over port 389. Are my assumptions correct?
Yes, you can do it, but it isn't advisable, as you will be transmitting passwords in plaintext. You should really go the extra yard and set it up for SSL as well, on port 636, or with the STARTTLS option on port 389 if port conservation is an issue.
Can anybody please point me to setup openldap on windows environment as well as this will just be used for my own tests.
It's all documented at http://openldap.org. Windows-specific instructions will depend partly on which Windows port of OpenLDAP you're using. I'm aware of at least three.
Our current infrastructure uses ssh keys for passwordless login to our Linux servers.
As our infrastructure grows, managing these authorised keys is getting harder.
As we also have an Active Directory (AD) server, I would like to authenticate the users over ssh using this mechanism, but maintain the passwordless nature of ssh keys.
Is it possible to authenticate the users over ssh without password, using some AD mechanism?
This is usually done via SSH key certificates in order to keep the password-less nature and at the same time have a Central Authority that can be trusted to generate new certificates for each account.
LDAP/Active directory use on login is not advised - apart from having to use passwords, it also becomes a single point of failure for access to any system it manages.
See RedHat documentation on how to do this and also Facebook's good write up on their use of certificate authentication with SSH.
Option 1
This is a good article explaining how to do this.
Storing SSH keys in Active Directory for easy deployment
Basically, it will allow people to post their public keys to your Active Directory and then you can set up a cron script on your servers to fetch a copy of the public keys every 5 minutes or so.
Option 2
You could also use a file server that has all your keys and get each server to fetch from there using a cron script. Obviously, you need a way to verify each key's authenticity especially if you are using FTP or some other insecure protocol. This could be achieved using GPG. You could have a company master GPG key that signs all the employee keys.
Personally, I like option 2 the best because I think it is more secure, but either method should work. Hope this helps!
My approach would be to reduce the problem to an already solved one by
Use active directory to authenticate without password and establish an HTTPS connection using Kerberos. The Dzone Tutorial Configuring Tomcat 7 Single Sign-on with SPNEGO might be a good starting point for that approach.
Wrap SSH into the https-protocol like, see section Wrapping SSH in HTTP(S) at https://unix.stackexchange.com/questions/190490/how-to-use-ssh-over-http-or-https