The Kubernetes Dashboard allows users to see all secrets, including their raw values with just a couple clicks. These secrets will likely contain very sensitive data, such as production database passwords and private keys.
How do you limit users of the Dashboard, so that they can't see the sensitive data?
This is a known issue and it is simply not officially supported at the moment - the Dashboard is a super-user level administration tool. This should not be the case forever, but more help is needed to get it there.
There are some workarounds discussed in that issue thread that work currently. Here are some notable quirks around them to be aware of beforehand:
Should the dashboard be under a dashboard user, and limited by that? If so, like Anirudh suggested you can neuter parts of the Dashboard and it will work fine and get 403s if they access the Secrets panel.
Should the dashboard be under a logged in user, and be limited to what that user can see? This means that kubectl proxy will be necessary without some browser plugin or MITM proxy to attach the needed auth to dashboard server calls but it is possible.
Related
May u know any possibility to secure access to dashboard of jobrunr? As inside dashboard there are many critical operation can be done, it need be protected with user name and password. At the moment it seems it open for anyone who can access the dashboard's url.
thanks in advance
I don't recommend a setup where the dashboard can be accessed via the internet, I would only allow access via internal IP's.
If you also want to protect for internal IP's, there is a way to do so. Search the issues and the discussions for it (I'm not writing the answer here as I don't like to promote that solution).
Update regarding JobRunr 6
JobRunr Pro 6 will support OpenID Authentication.
All of the following options leak all your accounts CloudWatch data.
1. Sharing dashboards via AWS console
Warning
All people who you share the dashboard with are granted the permissions listed in Permissions that are granted to people who you share the dashboard with for the account. If you share the dashboard publicly, then everyone who has the link to the dashboard has these permissions.
The cloudwatch:GetMetricData and ec2:DescribeTags permissions cannot be scoped down to specific metrics or EC2 instances, so the people with access to the dashboard can query all CloudWatch metrics and the names and tags of all EC2 instances in the account.
Reference: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html
2. Adding CloudWatch datasource to Grafana and permit user access to the dashboards in scope only
For example: In a Grafana instance with one data source, one dashboard, and one panel that has one query defined, you might assume that a Viewer can only see the result of the query defined in that panel. Actually, the Viewer has access to send any query to the data source. With a command-line tool like curl (there are lots of tools for this), the Viewer can make their own query to the data source and potentially access sensitive data.
Reference: https://grafana.com/docs/grafana/latest/administration/security/
3. Cross account sharing
Same problem arises that all accounts CloudWatch data is being shared.
Reference: https://docs.aws.amazon.com/ram/latest/userguide/getting-started-sharing.html
Cumbersome approach:
Build a backend service that fetches the dashboard relevant data and exposes it in a format that can be read by Grafana. Afterwards one still has to build a dashboard based on that data. Is there an easier way?
I have a secret which contains very sensitive information.
I want to make sure that this secret can only be accessed by a certain service account and nobody else.
Using RBAC, I can tell which user can access which resources. But is there some way where I can tell that this secret can only be accessed by this user?
as far as i know , There is no straight forward way to get that info (might require write a script to that iterates through rolebindings & clusterrolebindings).
Recently found a plugin called kubectl who-can on kubectl-who-can that fetches those kind details with one command.
It is possible to get it done with Validating webhook where the API request fields are parsed and checked for matching users.
OPA can be used to do some heavy lifting.
I am facing the challenge to request the Bing Ads API to get a couple of metrics from it.
I am using Apache Airflow DAGs hosted on a remote Kubernetes cluster to do so. It is a nice way to automate and schedule tasks.
Now, the documentation is rather light on the point of gaining access to the API.
I have followed this https://learn.microsoft.com/en-us/advertising/guides/authentication-oauth-identity-platform?view=bingads-13#registerapplication
and the official SDK docs https://github.com/BingAds/BingAds-Python-SDK/.
I am failing at authenticating when querying, since I am lacking a couple of pieces of information.
When authenticating using the "refresh token" and "redirect URI", I do not have either. (Class OAuthWebAuthCodeGrant here: https://github.com/BingAds/BingAds-Python-SDK/blob/294d01eea57d80ba381a42cde8d006fc318af056/bingads/authorization.py#L566)
When using a different method (Class OAuthDesktopMobileAuthCodeGrant here: https://github.com/BingAds/BingAds-Python-SDK/blob/294d01eea57d80ba381a42cde8d006fc318af056/bingads/authorization.py#L532), I fail w/
AADSTS700016: Application with identifier '<someidentifier>' was not found in the directory '<somethingelse>'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.
Thank you very much in advance! If you need more details, let me know!
Also great documentation in general, if I can make it more "newb"-friendly, let me know!
Edit1:
Sadly, while there has been some traffic to this question, nobody seems to be able to answer.
I will specify the set up a bit further.
We use Airflow DAGs to request daily updates from the API. For this, we need to authenticate. The authentication comes from a "new device" every time, since the code runs on a k8s cluster which allocates the jobs dynamically to it's pods.
For authentication, we ventured into different solutions, but all require some form of human interaction to get the refresh token into the DAG.
Is there any solution which allows for a hands-free deamon like many-server-to-server communication?
This link sheds some light on what we are looking for: https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-app-registration#api-permissions---app-permissions-and-admin-consent
Sadly, the Bing Ads API does not show up there.
What key piece of information are we missing?
Bing Ads, like Google Ads, uses OAuth for its API.
If you reference the Getting Started page, it mentions that you need a developer token, complete with links.
You can follow these steps to get a developer token for production.
Sign in with Super Admin credentials at the Microsoft Advertising Developer Portal account tab.
Choose the user that you want associated with the developer token. Typically an application only needs one universal token regardless how many users will be supported.
Click on the Request Token button.
Regarding your specific scenario--an application running in the cloud without an interface--you should know that OAuth requires you to interact with it to set things up. So run your app locally ONCE, or at least the getting_started code from your language's walkthrough: https://learn.microsoft.com/en-us/advertising/guides/walkthrough-desktop-application-python?view=bingads-13
Running it locally will go through the authentication process with your browser and generate a refresh token (in the file refresh.txt by default). Store this file with your code. It will have to be on the server that's making the request, and since it's in Kubernetes, you'll have to keep it with your container file.
I'm studying Kubernetes now, and have a question about Kubernetes Users. I learned how to create Users and how to limit access by Role, but when should I use it? For example, if a malicious user (not a k8s user, but an operating user) penetrates the k8s server, they can switch the administrator easily (if they can see .kube/config). In addition to that, if a user switches his or her user account and forgets to switch back, then another person who enters next can also use the first user's account. I doubt if I misunderstand the usage of k8s Users, but there seems to be no documents about why k8s prepared it. I assume that Users are only used for doing something from within pods, but if so, what's the difference between Users and Service Accounts?
Kubernetes has a very loose idea of a user. It knows that authentication is a thing, and that the output of that is a name and maybe some groups and tags. But really all it does it hand that info off to the authorization plugins to decide if a given request is allowed or not. ServiceAccounts are a specific object type because they generate you a JWT signed by the cluster, but there isn't a specific User type, that only exists within the context of your authentication plugin(s).