Question on JWT token and the JHipster Spring Cloud Config Service
The documentation (http://jhipster.github.io/microservices-architecture/) is little vague on how / what to copy for JWT tokens.
It says:
the JHipster Spring Config server makes sure that the config/JWT tokens are available and services authenticated. I have deployed the JHipster Config Server, Gaeway and one Microservice with an Entity.
When I try to call through the Gateway a backend microservice/with Entity (to create Author/Book) it tells me Access denied.
I believe once you register your microservice and gateway with the Config Server, the tokens are copied over to the Config Server and it should work without copying any tokens around.
Any idea how this is supposed to work?.
You should share the key by copying it into the registry's environment repository as jhipster.security.authentication.jwt.secret property in global application-dev.yml and application-prod.yml. Use different keys for prod and dev.
These shared yml files are the ones in your native environment repository (by default jhipster-registry/central-config) or git-based environment repository not in the src/main/resources/config folder of the registry itself.
jhipster:
security:
authentication:
jwt:
secret: "***********************"
Related
I want to add the ability to microservices to allow configuring endpoints and permissions for RBAC via Cloud Config Server. So if there is a service called mordor, then if I add following properties in its application.yml at Cloud Config Server's repo
rbac:
- endpoint: /v1/test1
method: GET
scopes: ["rest-write:all", "read-write:product"]
- endpoint: /v1/test2
method: POST
scopes: ["read-write:product"]
the endpoints mentioned above should be configured for RBAC. As of now, I am passing the scopes and permissions via Auth0 JWT and using it for authentication. But with this, I will be able to add RBAC also based on the permissions I configure in Auth0's dashboard.
What is the best way to proceed with this?
I am able to get the rbac endpoints from Cloud Config Server but the problem is how to add them to Spring Security. I already have a class OAuth2SecurityConfiguerer where httpSecurity is configured but I haven't been able to add endpoints to Spring Security because it might require iterating over the endpoints obtained from Cloud Config Server
I'm working with spring cloud config server, and my need is to create a configuration file for each stage prod test and dev, I already created 4 yml file application.yml for the default profile, application-{profiles} for each profile, so my question is how to load the specific configuration through the environment variable and run the config server on each profile configuration and port , I already created a bootstrap.yml but I can't solve the issue.
I will be very thankful if someone can guide throught the steps to achieve my need.
You don't need to start Spring Cloud Config Server with different profiles and on different port per environment. You can have one Config Server that manages the configurations for all environments. In your client's bootstrap.yml you will need to provide the URL of your Config Server as follows:
spring:
cloud:
config:
uri: http://your-config-server
When you run your client application with a particular profile (e.g. via an environment variable spring_profiles_active=dev), Spring Cloud Config Client will fetch the configuration properties from Config Server for the targeted profile.
I recommend to review at least the Quick Start section of the Spring Cloud Config documentation and try the examples provides there.
I have a vault server hosted in Openshift and I have to access secrets from the Vault into my spring application.
My bootstrap.yml looks like this :
spring:
application:
name: application-name
profiles: dev
cloud:
vault:
fail-fast: true
host: HOST
port: 443
scheme: https
token: MY_TOKEN
authentication: TOKEN
kv:
enabled: true
backend: secret
profile-separator: '/'
application-name: application-name
I checked vault logs and able to make connection from spring application to vault.
I can access the secret using Value Property Source.
However, I want to populate the secret's value into application.properties to update properties like spring.datasource.username and spring.datasource.password.
Is there any way to access the secret directly from application.properties?
TL; DR: Yes, you can use Vault properties in application.(properties|yml). It's not recommended to use these in bootstrap.(properties.yml).
Spring Cloud comes with a Bootstrap context where configuration libraries (such as Spring Cloud Consul, Spring Cloud Config and Spring Cloud Vault) are initialized. These integrations fetch configuration and provide these as a parent PropertySources to your application. Spring Boot considers these (you have options to use these PropertySources with the highest/lowest priority) during property binding and when you resolve a property value using Environment.
When bootstrapping an application, then typically one of the first things that happen is property binding in #ConfigurationProperties objects. At the time when bootstrap.(properties|yml) is loaded, typically Spring Cloud Config integrations didn't run yet so at that time you don't see properties contributed by these libraries. Therefore, there's the split between bootstrap context and the actual application context.
We are right now storing passwords and other configuration related data in git and filesystem(local) based on profile. This is working fine based on profiles local/dev etc. using SPring cloud config approach.
But to enhance security we have been suggested to use sensitive data in Vault
So i am not clear on how can this be achieved. Whether we will have a single Cloud Config server hosting some properties from Vault and some from Git.
A Config Client will locate the config server based on CONFIGSERVER_URI so we can not have separate instances running
How to achieve this requirement.
Thanks.
It is possible to access Git for some properties and Vault for others using the same config server. Access to Vault locations is granted to individual client through the use of a Vault token. The Vault token is passed automatically to the config server as a header at runtime. You would need to configure your config server with the Vault dependencies and add properties to access both Git and Vault something like this (not the 'vault' profile):-
server:
port: 8888
spring:
profiles:
active: git, vault
application:
name: my-domain-configuration-server
cloud:
config:
server:
git:
uri: https://mygit/my-domain-configuration
order: 1
vault:
order: 2
host: vault.mydomain.com
port: 8200
scheme: https
On your client you need to configure the authorization token supplied by Vault. Note the example below illustrates the property. You can put it into your application yaml files, because it is a per application/per environment token. However I prefer to inject it into the environment during deployment.
spring:
cloud:
config:
uri: https://configserver:8888/
token: <secret token>
You should consult the Vault documentation to understand how to authorize your token to access specific locations but the rules may look something like this:-
{
path "secret/myapp-app" {
policy = "read"
}
path "secret/myapp-app/*" {
policy = "read"
}
path "secret/application" {
policy = "read"
}
path "secret/application/*" {
policy = "read"
}"
}
Finally, it is also possible to access your Git through config server and access Vault directly from your client instead of configuring config server to access both. In this case you need to add the Vault dependencies to the client and configure the client properties to access Vault. You still need the authorization token in the client.
Instead of giving an AppRole or Static Token for Spring Cloud Config Server to access ALL secrets across ALL applications, is it possible to configure Spring Cloud Vault Config to utilize a given token on the request for the configuration?
This communication would be over 2-way SSL with the token in the headers. Not ideal to send such a token outward but seems the proper solution in this scenario.
Keep in mind this is a Spring Cloud Config Server using Git + Vault as backends in order to resolve secrets, variables, etc, into the desired configurations. This would not only be used for Spring Configurations but other files delivered to an ephemeral environment, such as an httpd.conf for Apache (bad example to shove secrets into)
Goal here is to limit access where possible and keeping it limited to the end-application requesting the configuration. Also nice to not duplicate RBAC efforts with AuthZ on Spring Config AND Vault policies.
You can configure each Spring Boot application that talks to Config Server to send its' own unique token to Config Server which is then passed through to Vault.
Vault will allow access to the requested resource based on the policies that define access to that resource and the permissions granted to the token.
Step 1: Define a policy.
cat ./rules/application-a.hcl <<EOF
path "secret/application" {
capabilities = ["read", "list"]
}
path "secret/application-a" {
capabilities = ["read", "list"]
}
EOF
Step 2: Write the policy to Vault.
vault write sys/policy/policy-application-a rules=#./rules/application-a.hcl
Step 3: Create a token using the defined policy.
vault token-create -display-name="My Application A" -policy="policy-application-a"
Step 4: Write some data to Vault
vault write secret/application-a #application-a-config.json
Step 5: Configure the Spring Boot application to use its' token.
Use the token created in Step 3 above. Set the following up in the application's bootstrap.yml file. You could also pass this through at run-time if you're running in a containerized environment.
spring:
cloud:
config:
uri: https://configserver:8888/
token: <secret token>
Spring handles the transfer of token from the client application to Config Server and then onto Vault.
For any other application, you can set the token in the header of a HTTP request.
From the Vault documentation:
https://www.vaultproject.io/intro/getting-started/apis.html
curl -X GET -H "X-Vault-Token:$VAULT_TOKEN" http://127.0.0.1:8200/v1/secret/application-a
I hope this helps you.