We have configured Grafana user and admin roles using Grafana.ini which works great.
Now we want to provide some permission to user to
see specific dashboards, e.g. user X can see 5 dashboard and user Y can see 8 dashboards according to some configurations (permissions).
We were able to keep this config in Grafana UI but if the pod (K8S) is fail the details is deleted, we are using latest prom helm .
My question is how should we
store this data right, even if the pod is restarted?
https://grafana.com/docs/grafana/latest/permissions/dashboard-folder-permissions/
https://github.com/grafana/helm-charts
https://github.com/grafana/helm-charts/blob/main/charts/grafana/values.yaml#L253
Any solution/direction will be helpful as I believe that grafana store this data someware but not sure where ...
I found this link which is talking about the store of the users on database etc
https://grafana.com/docs/grafana/latest/administration/configuration/#database
Not sure what is missing as the data should be kept in k8s volume...
If there is any other solution or a way to solve it please let me know.
You need to deploy your Grafana instance with a persistent storage. Either:
Keep using the built-in sqlite db - just ensure to use PVC to store it's data. The default path can be set using this config property
Use external db, like SQL, and configure Grafana to talk with it. See the database config section for more details.
Grafana persistency will be used to persist other settings as well, and also persist dashboards, alerts etc.
All settings can be set via the grafana.ini helm chart variable
Related
We are storing some user info in production that we don't have to keep and thus need to disable custom logging in application insights immediately. I can't change the code in between production rollouts.
Is there any setting or configuration available in application insights?
One solution which will not require code redeployment:
If using Classic Application Insights resource -> migrate to Workspace-based (no code changes required)
Use Workspace transformation DCR
Using them you can either completely drop data or can erase some fields.
Note, though dropped data doesn't appear in Application Insights, since it was ingested, it still will be partially charged (please refer to documentation).
Note, Workspace schema for Application Insights tables is slightly different. Transformation DCR needs to be written in Workspace schema. For instance, "requests" table name is called "AppRequests" in Workspace. You can explore individual fields by opening this table in Workspace directly.
We have a table in Azure Log Analytics that keeps the logs from many different systems.
For example, our CommonSecurityLog table has the logs from different Firewalls. I have created a custom RBAC role that allows access to this specific table only but would like to go further and limit the access to specific rows only.
I did some research but can't find a way to do this, is it possible?
There's no way to do this natively in Azure - RBAC only supports controlling access at the Table level.
EDIT:
So, as #FidelCasto mentioned, there's also the option of using Custom Logs. This will be helpful in many cases when you need to collect Custom Windows-related, Application-related. This could be a more user-friendly option but obviously there will be other cases where it will not apply, specially when you have devices sending non-standard logs.
If your requirements are not met by the option above, the only other catch-all option is to put a Log Collector between the firewalls and Azure, and use a script to filter the logs before sending them over via the Log Analytics (OpInsights) REST API. You could use a PowerShell script to handle this.
Each Firewall would send their logs to a local/remote Log Collector.
Have a script query/filter through the logs with If/Else based on the Firewall name.
For each Firewall, you would create a new Log-Type based on the Firewall name. Log-Type corresponds to the table name in Log Analytics.
Assign permission based on the newly created custom tables.
It's not as straight-forward but gets the job done!
I have been given a task at work to create an RDS cluster module using Terraform that will allow for consumers to spin up their own clusters/dbs etc. This is all fairly straight forward but it is the second lot of requirements that has me pulling my hair out. The DBAs want to know how to do the following:
Store and rotate the master password in secrets manager.
Create additional dbs, users etc via automation (nothing is to be clickops'd).
Utilise IAM authentication so that users do not have to be created/auth'd.
I have looked at a number of different ways of doing this and as i'm fairly new to this, nothing seems to stick out as "the best solution". Would anyone be able to give me a rundown of how they may have approached a similar task? Did you store and rotate password using a lambda function or did you assign the master user to an IAM role? Are you using the TF postgres provider to create roles or did you write your own code to automate?
I really appreciate any guidance.
Thanks heaps
The problem described is rather generic, but in my view you could keep almost everything under direct controll of terraform.
Store and rotate the master password in secrets manager.
Secret manager is the way to go. However, the password rotation will be an issue. When you enable rotation in AWS console, AWS magically provisions a lambda for you. If you don't use console, command line steps are a bit more involving as they require the use of aws serverless repo (SAR). Sadly, official support for SAR is not yet avaiable in terraform. Thus you would have to use local-exec provisioner to run aws cli to create rotation lambda as in the linked documentation using SAR.
Create additional dbs, users etc via automation (nothing is to be clickops'd).
As you already pointed out, the TF PostgreSQL Provider would the first thing to consider.
Utilize IAM authentication so that users do not have to be created/auth'd.
This can be enable using iam_database_authentication_enabled. But you should know that there are some limitations when using IAM auth. Most notably, only PostgreSQL versions 9.6.9 and 10.4 or higher are supported and your number of connections per second my suffer.
A follow up on point 1 for anyone in the future who wants to do a similar thing.
I ended up using a cloudformation_stack terraform resource to create the secret attachment and secret rotation - passing them parameter values from my terraform resources.
Works perfectly and easily switched out when/if terraform introduce these resources.
I have been able to successfully create a Google Container Cluster in the developers console and have deployed my app to it. This all starts up fine, however I find that I can't connect to Cloud SQL, I get;
"Error: Handshake inactivity timeout"
After a bit of digging, I hadn't had any trouble connecting to the Database from App Engine or my local machine so I thought this was a little strange. It was then I noticed the cluster permissions...
When I select my cluster I see the following;
Permissions
User info Disabled
Compute Read Write
Storage Read Only
Task queue Disabled
BigQuery Disabled
Cloud SQL Disabled
Cloud Datastore Disabled
Cloud Logging Write Only
Cloud Platform Disabled
I was really hoping to use both Cloud Storage and Cloud SQL in my Container Engine Nodes. I have allowed access to each of these API's in my project settings and my Cloud SQL instance is accepting connections from any IP (I've been running Node in a Managed VM on App Engine previously), so my thinking is that Google is Explicitly disabling these API's.
So my two part question is;
Is there any way that I can modify these permissions?
Is there any good reason why these API's are disabled? (I assume there must be)
Any help much appreciated!
With Node Pools, you can sort of add scopes to a running cluster by creating a new node pool with the scopes you want (and then deleting the old one):
gcloud container node-pools create np1 --cluster $CLUSTER --scopes $SCOPES
gcloud container node-pools delete default-pool --cluster $CLUSTER
The permissions are defined by the service accounts attached to your node VMs during cluster creation (service accounts can't be changed after a VM is instantiated, so this the only time you can pick the permissions).
If you use the cloud console, click the "More" link on the create cluster page and you will see a list of permissions that you can add to the nodes in your cluster (all defaulting to off). Toggle any on that you'd like and you should see the appropriate permissions after your cluster is created.
If you use the command line to create your cluster, pass the --scopes command to gcloud container clusters create to set the appropriate service account scopes on your node VMs.
Hmm, I've found a couple of things, that maybe would be interested:
Permissions belong to a service account (so-called Compute Engine default service account, looks like 12345566788-compute#developer.gserviceaccount.com)
Any VM by default works using this service account. And its permissions do not let us Cloud SQL, buckets and so on. But...
But you can change this behavior using another service account with the right perms. Just create it manually and set only needed perms. Switch it out using gcloud auth activate-service-account --key-file=/new-service-account-cred.json
That's it.
For the cloudsql there's the possibility to connect from containers specifying a proxy as explained here https://cloud.google.com/sql/docs/postgres/connect-container-engine
I'm trying to create a startup script or task that changes the configuration settings in the cscfg file, that executes on role start.
I'm able to access these settings, but haven't been able to successfully change them. I'm hoping for pointers on how to change settings on Role Start, or if it's even possible.
Thanks.
EDIT: What I'm trying to accomplish
I'm trying to make a service to more easily configure configuration values on Azure applications. Right now, if I want to change a setting that it the same over 7 different environments, I have to change it in 7 different .cscfg files.
My thought is I can create a webservice, that the application will query for its configuration values. The webservice will look in a storage place, like Azure Tables, and return the correct configuration values. This way, I can edit just one value in Tables, and it will be changed in the correct environments much more quickly.
I've been able to integrate this into a deployment script pretty easily (package the app, get the settings, change the cscfg file, deploy). The problem with that is every time you want to change a setting, you have to redeploy.
Black-o, given that your desire appears to be to manage the connection settings among multiple deployments (30+), I would suggestion that perhaps your need would be better met by using a separate configuration store. This could be Azure Storage (tables, or perhaps just a config file in a blob container), a relational database, or perhaps even an external configuration service.
These options require only a minimum amount of information to be placed into the cscfg file (just enough to point at and authorize against the configuration store), and allow you to maintain all the detail settings side by side.
A simple example might use a single storage account, put the configuration settings into Azure Tables, and use a "deployment" ID as the partition key. The config file for deployment then just needs the connection info for the storage location (unless you want to get by with a shared access signature), and its deployment ID. Then can then retrieve the configuration settings on role startup and cache them locally for performance improvements (either in a distributed memory cache or perhaps on the temp "local storage" drive for each instance).
The code to pull all this together shouldn't take more then a couple hours. Just make sure you also account for resiliency in case your chosen configuration provider isn't available.
The only way to change the settings during runtime is via Management API - craft the new settings and execute "Update Deployment" operation. This will be rather slow because it honors update domains. So depending on your actual problem there might be a much better way to solve it.