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
Related
I am working on creating a flow where I get JSON data from a rest api authenticating with the managed identity of my ADF instance and copy the data to a Kusto cluster. To do this, I am following the instructions here: https://learn.microsoft.com/en-us/azure/data-factory/connector-http?tabs=data-factory
However, when I go to create a linked service I do not see any way to authenticate against the API using my managed identity: http linked service auth options
I was expecting something like the options given in the Web task in ADF, where I am allowed to selected managed identities:web task auth options
HTTP connector supports only Anonymous, Basic, Digest, Windows, and ClientCertificate as authentication types. To use Managed Identity authentication type, you can use Rest linked service.
Search for REST in the available list of linked service and select REST connector.
You can select Managed Identity as auth type.
Reference: MS doc on Data Fcatory - REST connector.
I’m currently experimenting on Metaflow. I followed the documentation and was able to deploy an aws setup with the given cloud formation template.
My question is why is that I’m always getting a:
message: "Missing Authentication Token"
when I access METAFLOW_SERVICE_URL in the browser, even if I made sure that the APIBasicAuth was set to false during the creation of cloudformation?
Shouldn’t this setting make the metadata/metaflow service accessible without the authentication/api key?
How can I resolve this? Or is this expected? That is, I cannot really view the metadata/metaflow service url via browser?
Thanks in advance
This was resolved under this github issue.
You still need to set the x-api-key header if you are trying to access the service url via the browser. To get the api-key you can go to the aws console
Api Gateway -> Api Keys -> show api key
Alternatively you can use the metaflow client in the sagemaker notebook which should be automatically setup for you via the template.
Also worth mentioning that there are two sets of endpoints: The one provided by the api gateway (which you seem to be hitting) and the one provided by the service itself. The api gateway forwards the requests the the service endpoints but needs the x-api-key to be set in the header. You can probably try hitting the service endpoints directly since you disabled auth.
I've deployed buildbot in cloud vms, docker, and such. I've been able to setup authentication, but could not disable anonymous access.
It so happens that, I really can't allow anonymous access since it is a private owned resource, worst of all in many logs from build steps, passwords and other sensitive information show up.
buildbot version: 0.9.8
Documentation is scarse/nonexistant on this subject.
Thanks in advance.
Buildbot itself only allows to disable access to REST API. So anonymous users will see 'empty' web interface with no builds, logs etc. Access to the web interface can be disabled only by external web server settings.
Example authz config:
c['www']['authz'] = util.Authz(
allowRules=[
util.AnyEndpointMatcher(role='admins', defaultDeny=False),
util.AnyControlEndpointMatcher(role='admins', defaultDeny=False),
util.AnyEndpointMatcher(role='anonymous')
],
2.5.12.5. Authorization rules
One can implement the default deny policy by putting an AnyEndpointMatcher with nonexistent role in the end of the list. Please note that this will deny all REST apis, and most of the UI do not implement proper access denied message in case of such error.
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'
We are considering to use the keycloak as our SSO framework.
According to the keycloak documentation for multi-tenancy support the application server should hold all the keycloak.json authentication files, the way to acquire those files is from the keycloak admin, is there a way to get them dynamically via API ? or at least to get the realm public key ? we would like to avoid to manually add this file for each realm to the application server (to avoid downtime, etc).
Another multi-tenancy related question - according to the documentation the same clients should be created for each realm, so if I have 100 realms and 10 clients, I should define the same 10 clients 100 times ? is there an alternative ?
One of our flows is backend micro-service that should be authenticated against an application (defined as keycloak client), we would like to avoid keeping user/psw on the server for security reasons, is there a way that an admin can acquire a token and place it manually on the server file system for that micro service ? is there a option to generate this token in the keycloak UI ?
Thanks in advance.
All Keycloak functionality is available via the admin REST API, so you can automate this. The realm's public key is available via http://localhost:8080/auth/realms/{realm}/
A realm for each tenant will give a tenant-specific login page. Therefore this is the way to go - 10 clients registered 100 times. See more in the chapter Client Registration of the Keycloak documentation. If you don't need specific themes, you can opt to put everything in one realm, but you will lose a lot of flexibility on that path.
If your backend micro service should appear like one (technical) user, you can issue an offline token that doesn't expire. This is the online documentation for offline tokens. Currently there is no admin functionality to retrieve an offline token for a user by an admin. You'll need to build this yourself. An admin can later revoke offline tokens using the given admin API.