I am using Spring Vault and need to connect to two Vault servers, one for secrets and another for transit operations. (My cluster has many more transit operations.) How can I setup Spring Vault (also using Spring Cloud Vault) for this configuration?
You have two options:
Use dedicated VaultTemplate objects that are statically configured pointing each to a Vault endpoint that is intended for the particular use case.
Implement a routing VaultEndpointProvider along with a discriminator (e.g. ThreadLocal-based hostname). Each time you intend to call an action, you're setting the discriminator that is later evaluated by your VaultEndpointProvider to return the appropriate endpoint for your call.
Spring Vault uses a pluggable client model, with an upcoming version you'll be able to control RestTemplate creation and hook into UriTemplateHandler which would be the appropriate class to extend.
Related
Spring cloud vault enables connecting to a namespace with property "spring.cloud.vault.namespace". I have an use-case to read secrets stored in different namespaces. Is this possible with sprint cloud vault? or there any other approaches?
Thanks
The namespace is configured through the client by registering a ClientHttpRequestInterceptor in RestTemplate respective ExchangeFilterFunction in WebClient.
This approach serves the purpose of allowing client authentications to authenticate against the appropriate namespace without making each authentication mechanism aware of its namespace. Later on, VaultTemplate is configured with the namespaced client to avoid downstream namespace configuration in the VaultTemplate.
If you need to use multiple namespaces, then ideally configure individual SessionManager and VaultTemplate objects per namespace.
Depending on your authentication mechanism (i.e. if you use tokens instead of login methods) there are other possible approaches. One could consist of a single SessionManager/VaultTemplate where you store the namespace and token in a ThreadLocal and provide a ClientHttpRequestInterceptor for a single VaultTemplate that communicates with the desired namespace.
In a microservice world, what is the recommended way of configuring the endpoint of a downstream API?
For example, if Service A needs to invoke an endpoint in Service B, we have two options:
a. Make the hostname and port number of Service B's API configurable in Service A (service-b:8080) and append the path URI in your code
or
b. Make the complete endpoint configurable in Service A (http://service-b:8080/somepath)
While I like the idea of making the endpoint configurable, it leaves a lot of room for error because the entire path needs to be specified. It also doesn't fit well when multiple endpoints need to be called from Service A to Service B which may potentially have different paths, requiring us to configure multiple endpoints.
On the other hand, option (a) seems more scalable due to above mentioned reasons.
Most search results online just demonstrated how a service can call another service and uses a hardcoded URL to demo this. It would be good to know how is the community doing this in real world projects.
P.S: We use Spring Webflux and deploy to k8s.
I have seen mostly that teams use option a, where the serviceB "baseUrl" (which is basically https://serviceb-hostname:8080) is injected as environment property (kubernetes configmap) into the application during deployment.
The specific API specific paths are configured in application yaml or in the "proxy config" class itself as constants (eg. ServiceBProxy.java - proxy classes are those which will make rest-calls to the dependent services like service B).
Here is a portion of application yaml from one of the microservices (from one of my projects):
authorizationService:
baseUri: ${authorizationServiceBaseUri}/api
tenantService:
baseUri: ${tenantServiceBaseUri}/api/v1
tenantsUri: ${tenantService.baseUri}/tenants
settingsService:
baseUri: ${settingsServiceBaseUri}
iamService:
fetchBatchSize: 500
baseUri: ${iamServiceBaseUri}
Here the values of iamServiceBaseUri,settingsServiceBaseUri,tenantServiceBaseUri,authorizationServiceBaseUri are all injected during deployment. And each of them contains the clusterIP with port.
How to force implementation url to listen from proxy only in Mulesoft?
Right now proxy can be secured using client_id, client_secret etc. However implementation url is not secure. By chance if anyone knows the implementation url then its potential risky affair.
Is there any way we can force implementation url to listen to proxy only.
(or) Can we add policies to Implementation url.
Mulesoft documentation setting-up-an-api-proxy states that the proxy application is nothing but a mule application mocking the contractual behavior of the actual service implementation and making service calls to the actual API for fulfilling requests. So instead of HTTP, it is recommended to use HTTPS for enhanced security and data integrity. Since Mulesoft suggests using HTTPS protocol for the connection between mule proxy and service implementation, so leveraging the HTTPS protocol, one option would be to try enforcing two way SSL between your proxy and the implementation which will help you accept requests only from legitimate clients.
Check the topic enable-two-way-ssl-in-mule for further implementation details
The second option would be to enable policies on the actual service implementation i.e. enable api-auto-discovery on your service.
Although you can do it but it would be an overhead due to below reasons :
As you would be enforcing policies at two layers and doubling the
calls to API Manager for sync up of policies as the service
implementation would poll the API manager every fixed interval of
time to check/fetch the policies.
To enable the policy application on the service implementation, the
service needs to run on either api-gateway runtime or mule 3.8
onwards runtime as older mule versions do not support policies.
The implementation can be done by having below XML snippet in the API xml.
<api-platform-gw:api apiName="app-${env}" version="${api.version}" flowRef="api-main" create="true" apikitRef="api-config" doc:name="API Autodiscovery" />
apiName would be the API definition created in API Manager from where
you can view and manage the API
version would be same major version of the API
flowRef would map it to the main flow reference
create flag to signify if the definition needs to be created in API Manager in case it does not exist
Conclusion:
Enforce 2 way SSL to enforce client-server certificate based authentication
Add Auto Discovery to service implementation so to apply policies on implementation layer as well
Mulesoft documentation suggests adding VPC . When we tested http was working in VPC but not https.
Since https was a mandatory requirement and we were unable to do it via VPC , we fixed it in a different way.
We added a custom header at proxy code and we validate for that header in implementation .
This was the fix rolled out
I am experimenting with Mule API management these days. What I come to know is we can deploy our API to one of these:
A Mule Runtime
An API Gateway
In the documentation, it is said that we should go with option 1 when we want to separate out the implementation of your API from the orchestration. What does it mean?
Can any one please explain in detail?
Policy management from API Platform and analytics generation can be achieved only by using a correctly configured API Gateway, which is a superset of Mule EE (current version is API Gateway 2.1.0 which contains Mule EE 3.7.2).
Depending on your architecture you may have different solutions.
For example:
Proxy running on API Gateway, implementation API running somewhere
else (eg. Mule EE/CE, Tomcat, cobol server, etc)
Proxy and implementation API running on the same API Gateway
Implementation API
managed directly from API Platform without using the autogenerated
proxies.
HTH :-)
Not exactly sure what they mean there, because on this page: https://developer.mulesoft.com/docs/display/current/API+Gateway they also mention this:
Note that the API Gateway, because it acts as an orchestration layer
for services and APIs implemented elsewhere, is technology-agnostic.
You can proxy non-Mule services or APIs of any kind, as long as they
expose HTTP/HTTPS, VM, Jetty, or APIkit Router endpoints. You can also
proxy APIs that you design and build with API Designer and APIkit to
the API Gateway to separate the orchestration from the implementation
of those APIs.
So both methods technically allow you to separate API from orchestration, as your API gateway application could simply proxy another Mule application elsewhere that performs the orchestration. But my understanding of the two options are:
The API gateway is a limited offering that allows you to use a subset of Mule's connectors, transports and modules such as ApiKit and HTTP, it allows you to expose and API then use http to connect to whatever backend systems you want as a proxy and perform the orchestration in the API layer.
By using the Mule runtime operation, it gives you much more flexibility and allows you to compose as many applications as you want using the full range of connectors etc. and separate out the different aspects of your applications into as many layers as you want as separately deployable entities that you can deploy to on-premise standalone instances or Cloudhub etc.
#Ryan answer is more or less on the mark, however if you do choose the Mule ESB offering you will loose out on the API Management and governance functionality that API gateway provides OOTB.
These include
Lets you enforce runtime policies and collect data for analytics
Applies policies to APIs or endpoints around security, throttling,
rate limiting, and more
Extends PingFederate to serve as identity management and OAuth
provider for your APIs
Lets you require or restrict certain behaviors in a few simple steps
Lets you add or remove policies at runtime with no API downtime
Manages access to your API by issuing contract keys
Monitors the API to confirm it is meeting all contract terms
Ensures compliance with service level agreements (SLAs)
In my opinion go with API Gateway/Manager if your API will be consumed my third party developers with whom you might not have too many interactions (think public API's) else Mule ESB should be good.
You should be able to migrate from Mule ESB to API Manager (and vice versa) also easily if you need to, so I do not think you will get locked into your decision
PS: Content copied from here
I am using Cometd 3.0.1 with jetty 9.2.3 using JSR 356 based websocket implementation (and not jetty's own websocket implementation).
I have added some auth filters which basically ask for authentication headers from request. But as websocket upgrade happen as a part of websocketupgrade filter, is there a way to make authentication work here?
Authenticating via a Filter is the wrong way to accomplish authentication.
Correct Solution:
The servlet spec expects you to setup and configure the the authentication and authorization layers of your application using the servlet techniques of both the container and the application metadata (WEB-INF/web.xml)
This means you setup a the container side security, either using the Jetty container specific LoginService, or using a JAAS spec configuration. Then you reference your security realms in your WEB-INF/web.xml and use them. If you have something custom, then you can hook into the LoginService of your choice (even a custom one) and manage it accordingly.
JAAS and LoginService Authentication and Authorization is applied before all filters and servlets.
In this scenario, you'll have access to the authentication information during the upgrade process, in particular during the ServerEndpointConfig.Configurator.modifyHandshake()
Ugly Hack Solution:
Add the org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter to your WEB-INF/web.xml manually.
This then leaves it up to you to attempt to get your authentication filter to exist before this WebSocketUpgradeFilter in 100% of use cases.
Caution: filter execution ordering is not part of the servlet spec. Be careful with this, as it might seem to be working on your dev machine and then suddenly not work in QA or production. Simply because the Set of filters in the metadata will have a different order in it.
Notes:
Path Spec must be /*
Async Supported must be true
Dispatcher Types must be REQUEST only.
Do not set the contextAttributeKey for that filter
All other WebSocketUpgradeFilter init-params are invalid for JSR-356 use (they are overridden by the various JSR-356 endpoint configurations)