How do I override per-instance settings in Spring Boot Admin when using Kubernetes discovery - kubernetes

I'm running a Spring Boot Admin server (2.2.2) and using Spring Cloud Kubernetes discovery (with specific service labels to filter) to detect my client apps. None of my client apps are using the explicit Spring Boot Admin Client dependency mechanism.
One of my client apps has a non-standard actuator URL and uses different security credentials to access those endpoints. I understand that I could use static spring cloud discovery with instance metadata to achieve this, but I'd rather use the kubernetes discovery process for all my client apps.
I think by using a custom ServiceInstanceConverter I might be able to override the management context path, but I couldn't see a way to inject custom security credentials via that route.
Is there a better way to customise this kubernetes-driven discovery process? (e.g. can I declare instance metadata somewhere in the client app so that it's picked up even though I'm using Kubernetes discovery - I got the sense from the Spring Boot Admin docs that setting admin properties in clients applied only to the "push registration from client to server" case rather than the "server discovers" case.)
As a related general question, Spring Boot Admin is presumably using some default credential values for accessing actuator endpoints - where are they set up?
Thanks in advance
Alan

I think I figured this out for myself, but in case it's useful to anyone else here is what I did:
Declared custom values for the instance metadata management.context-path, user.name and user.password under the annotations section of the Kubernetes service for my client application.
e.g.
kind: Service
apiVersion: v1
metadata:
name: foo-service
annotations:
# The following are used to support monitoring and administration
user.name: mySpecialUsername
user.password: mySpecialPassword
management.context-path: /foo/manage
From observation it seems that the default credentials assumed by a Spring Boot Administration server are admin/admin.

I don't think it is advisable to put passwords into a service manifest.
The SBA refdoc documents some properties to configure default or per service usernames/passwords.
If this is not an option, you can always add some custom headers to the requests that are sent to the clients:
#Bean
public HttpHeadersProvider customHttpHeadersProvider() {
return (instance) -> {
HttpHeaders httpHeaders = new HttpHeaders();
httpHeaders.add("Authorization", "Basic bXlTcGVjaWFsVXNlcm5hbWU6bXlTcGVjaWFsUGFzc3dvcmQ=");
return httpHeaders;
};
}

Related

Close proxy API access

Close proxy API access
Hi community,
Grafana 8.2.5
We have a Grafana system 8.2.5. He had a security audit, where the API access is criticized.
We have enabled an anonymous acess for users without login.
[auth.anonymous]
enabled =true
org_name = IT.NRW
org_role = Viewer
When I try to access the Grafana like:
curl http://<fqdn>:3000/api/datasources -> {"message":"Permission denied"}
curl http://admin:<password>#<fqdn>:3000/api/datasources -> a valid json object with the datasource etc....
But the security audit found also the access to the datasource proxy? API.
curl http://<fqdn>:3000/api/datasources/proxy/3/query?db=<db>\&q=SELECT+*+FROM+<ts>\&epoch=ms
So I can query with or without credentials ALWAYS the API.
Security audit: a Denial of Service (DoS) is possible, maybe some SQL injection.
I don't want discuss this topic here.
I have to close the access through the API. At least from other network segments.
Any hints?
Thanks in advance.
I'm a grafana beginner!
I do not complain, the security audit listed the two topics (DoS/SQL injection).
I didn't found any configuration possibilities (grafana.ini) about closing the proxy API interface (only data_source_whitelist-ing).
So, I added some rules into the NGIX config in front of the grafana server to
forbid the proxy API access -> throw 40x error.
Now the web UI is not able anymore to fetch and render the data in the UI.
My conclusion:
the grafana architecture define: the proxy API will be used by the web UIs.
with or without credentials: a user can fire a query (DoS) using the proxy API
with or without credentials: the query is pass through the proxy API to the datasource, potential sql injection is possible

Sending client security username and password to Spring Boot Admin via Spring Cloud Kubernetes Service Discovery

I am able to discover all services in my namespace and display them on spring boot admin but some of the clients have username/pass protection on some of the actuator endpoints. How can I get this information to spring boot admin via the kubernetes service discovery?
I was able to pass the client username and password by adding a tag in kubernetes service discovery of user.name and user.password for each client.
This isn't secure though because anyone with read access can read the metadata.
Is there a way to set a global user name and password for all clients?
This configuration will define a default user for the actuator. This default user and password is passed to each actuator call:
spring:
boot:
admin:
# AdminServerProperties used by basicAuthHttpHeadersProvider
instance-auth:
default-user-name: myactuatoruser
default-password: myactuatorpw
Remark:
You need at least spring-boot-admin:2.2.3. Check for the appearance of these properties the ConfigurationClass AdminServerProperties.
Otherwise you might define your own HttpHeaderProvider.
This is a copy of the 2.2.3 spring-boot-admin Code:
#Bean
#ConditionalOnMissingBean
public BasicAuthHttpHeaderProvider basicAuthHttpHeadersProvider(AdminServerProperties adminServerProperties) {
AdminServerProperties.InstanceAuthProperties instanceAuth = adminServerProperties.getInstanceAuth();
if (instanceAuth.isEnabled()) {
return new BasicAuthHttpHeaderProvider(instanceAuth.getDefaultUserName(),
instanceAuth.getDefaultPassword(), instanceAuth.getServiceMap());
}
else {
return new BasicAuthHttpHeaderProvider();
}
}

What is the difference between an Endpoints service and AppEngine service when they have the same URL?

I have two services in Endpoints in GCP to host two APIs
They are
Service A
and
Service B
Service A's host is
projectid.appspot.com
Service B's host is
test-dot-projectid.appspot.com
When I deploy my app using gcloud app deploy Service A's test service in
appengine my app.yaml looks like this
runtime: go
env: flex
service: test
endpoints_api_service:
name: projectid.appspot.com
rollout_strategy: managed
handlers:
- url: .* #mandatory
secure: always #deprecated in flex environment
redirect_http_response_code: 301 #optional
script: _go_app #mandatory
From my understanding, the app has been deployed to Service A's URL
projectid.appspot.com but with the subdomain test so test-dot-projectid.appspot.com
However is this now not technically deploying to Service B on a default service i.e.
test-dot-projectid.appspot.com
Is this not interfering with deploying on service A with service test? What is the difference?
My understanding is: if service A is "projectid.appspot.com". Only "projectid.appspot.com" will be routed to A, not "test.projectid.appspot.com". So you can safely deploy sevice B with "test.projectid.appspot.com". But I am not sure. Have you tried it?
When having an application with multiple services, the service names must be configured and must be unique.
The default project is not required to have a service name. This is true when a single service for an application exists.
When having multiple services (Service A, Service B), the application must be first deployed to the default service. After which, each service must have their own app.yaml file.
It is recommended for each service to be configured with a unique service name to prevent miscommunication. If a unique service name is not configured for each service, by default, it will deploy to the default service’s URL. In your case, since the default service URL and Service A’s service URL are the same, it is causing a conflict.
To deploy to a specific services’ service name, you will need to specify the service name and its app.yaml file.
For more information, please refer to:
Planning your directory structure and app.yaml naming:
https://cloud.google.com/appengine/docs/flexible/go/configuration-files#directory_structure
How to deploy to multiple or specific service in a multi-service environment:
https://cloud.google.com/appengine/docs/flexible/go/testing-and-deploying-your-app#deploying_multiple_services
App Engine is made up of application resources that are made up of one or more services (previously known as modules). Each service is code independent and can run different runtimes and you deploy versions of that service. The URL is how your application is accessed either via a user request or an API call to the service.
For more information, please see https://cloud.google.com/appengine/docs/standard/python/microservices-on-app-engine#app_engine_services_as_microservices
Endpoints are part of the Cloud Endpoints Framework service offered by Google Cloud to manage, deploy, maintain and secure your API. In App Engine, Endpoint framework is only supported on Python 2.7 and Java runtime environments. It is a tool that allows you to generate REST API and client libraries for your application.
For more information, please see
https://cloud.google.com/endpoints/docs/frameworks/about-cloud-endpoints-frameworks

API Management Service : How to import Service Fabric Cluster APIs?

We have created two APIs and deployed them to a Service Fabric Cluster, which exposes them as https://[clusterurl]:8100 and https://[ClusterURL]>:8101.
Now we want to expose these APIs via API Management Service, and we couldn't find any easy way to do so. There is one article at https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-tutorial-deploy-api-management, but it's really very hard to understand and relate it with this SDK.
We managed to create an API Management Service instance and also to create a blank API (or import through Swagger) using the SDK. But we don't know how to import the Service Fabric API.
And we could create an API Management BackEnd pointing to the Service Fabric app, but then we couldn't find any way to bind this BackEnd to any API created in the API Management Service.
Any help, sample, and/or pointing in right direction is greatly appreciated.
For service fabric integration to work you need:
VNET that includes both your SF cluster and APIM instance.
Backend entity: https://learn.microsoft.com/en-us/rest/api/apimanagement/backend/createorupdate it will let APIM know where your cluster is and provide it with necessary credentials to make calls.
set-backend-service policy: https://learn.microsoft.com/en-us/azure/api-management/api-management-transformation-policies#SetBackendService It's usually placed in inbound section of API that needs to talk to SF. You should omit "base-url" attribute, use "backend-id" to specify id of backend entity created in previous point, and other "sf-*" to configure how exactly call should be made.

spring cloud consul discovery acl for catalog services

I have ACL on for Consul, and have tried many ways to specify the token to use for service discovery. The config ACL token works fine, and the discovery ACL token works for registration (I can see my services in the Consul UI). I see the code for AgentConsulClient.agentServiceRegister() supports the token with this:
UrlParameters tokenParam = token != null ? new SingleUrlParameters("token", token) : null;
Nothing similar is supported in CatalogConsulClient, as far as I can tell. When called from Spring Cloud's ConsulDiscoveryClient, no token is passed, regardless of how it is set. Logs show the call being made without the token, and getting back a valid response with none of the registered services listed. I don't see how to have ACL on for registration but off for discovery. What am I missing? Is nobody actually using ACL if using discovery? (It works fine in the development environment with no ACL). Do I need to edit the source to add the token support from the agent service to the catalog service? Has anybody had success doing that?
BTW, could not tag this with spring-cloud-consul. Add it if you can.
ACL support for Consul catalog services is in consul-api v1.1.11 and will be (I hope) part of spring-cloud-consul 1.0.3.RELEASE. The 1.0.2.RELEASE version still uses consul-api-1.1.10. Update: confirmed to be in Camden.SR3.
Gradle:
'com.ecwid.consul:consul-api:1.1.11',
'org.springframework.cloud:spring-cloud-consul-dependencies:1.0.3.RELEASE'