I am trying to setup an enterprise level Spring Config Server which will be used by multiple config client applications across the company. As the encrypt.key should be common across multiple clients, is it possible to protect sensitive information of a client application from other client applications. Am I missing something? Please help me.
That is one way to set things up. You can also let the config server handle decryption so the clients only get decrypted values and secure the connection from client to server using spring security.
Related
Background
We have almost a hundred Eureka clients (spring cloud apps) being registered to an Eureka discovery server. One client can depend as many as more than 10 other clients. Traditionally, we have to run all the dependencies (along with discovery and config server) on local dev environment when developing against one client. Sometimes, to avoid bring up so many projects, I just connect the single client I am working on to our integration test environment which has all clients running. This way, it is very convenient for myself, but having a critical issue: my local client can be discovered by other clients, meaning someone else's testing might be effected by my instance. I know there are ways to mock or proxy the client dependencies. But they are not always good for every scenario, also the setup takes additional time.
Question
Is there a practically quick and easy way to register a client without being discovered by other clients. Besides, I can not issuePUT /eureka/v2/apps/appID/instanceID/status?value=OUT_OF_SERVICEor other discovery server side command. I can only configure my local project.
The easiest way to achieve that is adding the below property only in your local profile.
eureka:
client:
registerWithEureka: false
If so, your application still can look up other instances from Eureka, but your application will not register itself into Eureka.
The REST API for Kafka Connect is not secured and authenticated.
Since its not authenticated, the configuration for a connector or Tasks are easily accessible by anyone. Since these configurations may contain about how to access the Source System [in case of SourceConnector] and destination system [in case of SinkConnector], Is there a standard way to restrict access to these APIs?
In Kafka 2.1.0, there is possibility to configure http basic authentication for REST interface of Kafka Connect without writing any custom code.
This became real due to implementation of REST extensions mechanism (see KIP-285).
Shortly, configuration procedure as follows:
Add extension class to worker configuration file:
rest.extension.classes = org.apache.kafka.connect.rest.basic.auth.extension.BasicAuthSecurityRestExtension
Create JAAS config file (i.e. connect_jaas.conf) for application name 'KafkaConnect':
KafkaConnect {
org.apache.kafka.connect.rest.basic.auth.extension.PropertyFileLoginModule required
file="/your/path/rest-credentials.properties";
};
Create rest-credentials.properties file in above-mentioned directory:
user=password
Finally, inform java about you JAAS config file, for example, by adding command-line property to java:
-Djava.security.auth.login.config=/your/path/connect_jaas.conf
After restarting Kafka Connect, you will be unable to use REST API without basic authentication.
Please keep in mind that used classes are rather examples than production-ready features.
Links:
Connect configuratin
BasicAuthSecurityRestExtension
JaasBasicAuthFilter
PropertyFileLoginModule
This is a known area in need of improvement in the future but for now you should use a firewall on the Kafka Connect machines and either an API Management tool (Apigee, etc) or a Reverse proxy (haproxy, nginx, etc.) to ensure that HTTPS is terminated at an endpoint that you can configure access control rules on and then have the firewall only accept connections from the secure proxy. With some products the firewall, access control, and SSL/TLS termination functions can be all done in a fewer number of products.
As of Kafka 1.1.0, you can set up SSL and SSL client authentication for the Kafka Connect REST API. See KIP-208 for the details.
Now you are able to enable certificate based authentication for client access to the REST API of Kafka Connect.
An example here https://github.com/sudar-path/kc-rest-mtls
I have an application running on Wildfly 10 in a domain setup with more than 10 machines. Clients consume REST webservices using SSL authentication, in this scenario we will be adding clients on a daily basis so it is important to be able to propagate changes on the Truststore to the whole server group.
It's not an option to centralize the truststore in one machine due to concurrency levels.
I would like to know if there is a way to achieve this using the CLI or any other alternatives.
Thanks in advance!
Given that Wildfly does not support reloading the truststore at runtime (see https://access.redhat.com/solutions/482133), you would copy the truststore file to all servers (by hand, by script, by Puppet/Ansible/your DevOps tool), and use CLI to restart the affected server groups in the domain.
See also https://github.com/wildfly/quickstart/tree/10.x/helloworld-war-ssl for an example to implemet SSL auth. Basically all clients get a certificate from your own CA, which you add to the truststore once. Then use RBAC for the authorization.
I've been reading security articles for several days, but have no formal training in the field. I am developing a configuration and management application for an IoT device. It is meant to be run either on an internal network, or accessed over the web.
My application will be used by IT admins, managers, and factory-floor workers. Depending on the installation, there will be varying levels of infrastructure in place. It could run on a laptop on the floor itself, on a server, or hosted in the cloud. For this reason, we can not assume that our clients will have the kind of infrastructure you might find at a datacenter or in the cloud, for example CAS or NTP.
Our application provides a REST API for client applications to gather data. We'd like to use roles to restrict what data users can access. I've gathered that a common solution for authentication is to encode the username/pass in the REST Header. However, this is completely insecure unless sent over a secure channel.
As I understand it, SSL Certification Authorities grant certs for a specific domain. Our application will have no set domain, and a different IP depending on the installation. Many web applications do not trust self-signed certs. It's not clear to me whether a self-signed application is good enough for a typical application-developer who will be consuming our interface.
With this being the case:
1) What are my options to set up a secure channel, internally or via the web?
2) Am I making assumptions about how our product will be used that damage our users' security unnecessarily?
Well you can use custom encryption to encrypt the data being sent to the applications.
You can also use JSON web tokens to secure your REST API. https://en.wikipedia.org/wiki/JSON_Web_Token. The JSON tokens could be generated by a centralized authentication server and included in all requests sent by the client applications to the server
My web application is currently configured to connect to LDAP for user validation without relying on application server settings. In other words, my applications utilizes naming params to connect to LDAP hence its agnostic to application server ie. JBoss or Websphere.
Naming params used are as follows:
ldapURL
ldapPrincipal (bind user)
ldapCredentials (bind user's password)
ldapAuthentication
ldapSearchBase
The requirement now is to allow encrypted password in the ldapCredentials naming param. I have a way out of this situation is using custom SecurityLoginModule to encrypt password and supply it to application using naming param. My application would then decrypt it and then proceed with LDAP user validation. However, this results into additional application installation step.
So I was wondering if there is a way to use application server security domain (or some other way) to store the user credentials in secured fashion on application server and later application would pick it up at the time of user validation with LDAP without writing server specific code in my application. I know that we can use security domain to perform data source connection without writing server specific code. But if I do this for LDAP then I make server talk to LDAP which is not what am looking. Basically may still continue to use Federated users instead of LDAP.
Any decent application server (including JBoss and WebSphere) have server provided LDAP registry, which you can configure and use without any application specific code, and I'd strongly suggest to utilize that instead of writing your own ldap connection code.
Regarding encryption:
for WebSphere traditional, you can plug in your own class into server infrastructure to encrypt passwords see - Plug point for custom password encryption
for WebSphere Liberty - you have out of the box support for aes and hash.
for JBoss first link in Google showed me this How do I encrypt the bindCredential password in Wildfly, but maybe JBoss experts will guide you to something different.