I have a request to restrict the access (access control) to a small user community in GCP.
Let me explain the question.
This is the current set up:
A valid GCP Organization: MyOrganization.com (under which the GCP project is deployed / provisioned)
Cloud DNS (To configure domain names, A & TXT records, zones and subdomains to build the URL for the application).
Oauth client set up (tokens, authorized redirects URIs, etc.).
HTTPS load balancer (GKE -managed k8s service- with ingress service), SSL certificate and keys issued by a trusted CA.
The application was built using python + Django framework.
I have already deployed the application (GCP resources) and it is working smooth.
The thing is that, since we are working in GCP, all IAM users who has a valid userID#MyOrgnization.com can access the application (https://URL-for-my-Appl.com).
Now, I have a new request, which consists in restricting access (access control) to the application only for a small user community within that GCP organization.
For example, I need to ensure that only specific IAM users can access the application (https://URL-for-my-Appl.com), such as:
user1#MyOrganization.com
user2#MyOrganization.com
user3#MyOrganization.com
user4#MyOrganization.com
How could I do that, taking into account the info I sent earlier ?
thanks!
You can use Cloud IAP (Identity Aware Proxy) in order to do that.
Identity-Aware Proxy (IAP) lets you manage access to applications
running in App Engine standard environment, App Engine flexible
environment, Compute Engine, and GKE. IAP establishes a central
authorization layer for applications accessed by HTTPS, so you can
adopt an application-level access control model instead of using
network-level firewalls. When you turn on IAP, you must also use
signed headers or the App Engine standard environment Users API to
secure your app.
Note: you can configure it on your load balancer.
It's not clear in your question if your application uses google auth (but considering that you talk about org-restricted login I think so) - if that's the case you should be able to enable it without virtually touching anything in your application if you are using the Users API.
The best and easiest solution is to deploy IAP (Identity Aware Proxy) on your HTTPS Loadbalancer
Then, grant only the user that you want (or create a gsuite user group and grant it, it's often easier to manage)
Related
I'm trying to find out how I can know if my application that wants to use a restricted Google API scope is exempt from the security assesment.
The documentation for the Google API Services User Data Policy states that:
Local client applications that only allow user- configured transmissions of Restricted Scope data from the device may be exempt from this requirement.
How can I find out if my app qualifies for this exemption?
If you check the OAuth API verification article here:
These applications [local client applications] may be exempt from the secure handling policy because the security assessment (and successful securement of a Letter of Assessment) primarily addresses risks associated with developers obtaining and storing data on servers.
Developers should specify in the verification application whether they believe the application is a local client application, and we will work with the developer to verify that is the case.
Therefore, when sending the verification application you should mention that the application you have is a local client one and if this is indeed the situation, you will be notified about it.
Also, please bear mind, that the local client applications can be defined as, according to Google:
Local client applications are generally applications that only run, store, and process data on the user's device (like a computer, mobile phone, or tablet). While user actions may cause data to leave a device (such as sending an email), local client applications do not transmit restricted scope data to the developer's servers (or servers specified by the developer), unless the user explicitly configured the application to do so. This would include local email clients, file managers, and calendar and contact management applications that don't utilize cloud services or only transmit restricted scope data to user-configured destinations.
Applications that send restricted scope data to a developer's or third-party's servers without explicit user-initiated action, such as setting up a backup capability, will not be considered a local client.
Reference
OAuth API Verification FAQs.
We have an application which is hosted on the on-premises Windows server (IIS) server
now I created a windows server on azure and building a web app for it.where the application needs to authenticate the user by windows server (DC) using kerbrose protocol but I couldn't find any documentation regarding this from Microsoft's side
Is the above query possible to be implemented in the azure web app?
No, it's not possible. Windows Authentication is something for on-premise deployments. For Azure Web Sites Azure Active Directory is clearly the best option. Sync from AD to Azure Active Directory is also quite easy to setup.
If you still want to absolutely use Windows Auth and host your website on Azure, you can create Windows VM and host your website there. You then need to join the VM to your AD. To this, both VMs must be in the same network. So if your VM is on-premise you will need to create an site-to-site VPN.
For more information, follow this SO which also discussed about this.
If your intention is to join the VM hosting the website to a domain then as others have mentioned, this isn't possible.
However, doing Kerberos authentication itself within an Azure website isn't particularly difficult, but it does require manual implementation. Windows natively handles all of this for you on domain joined machines and and IIS exposes that functionality. Since you can't domain join you have to manually do all that heavy lifting and request and validate the tickets yourself.
This involves creating a service account in Active Directory and keeping the account password in sync. Once you have that you need to indicate to the browser that it needs to negotiate auth, which is done with the WWW-Authenticate: negotiate header on a 401 response. The client, if configured to send tickets, will send a ticket in the Authorization: Negotiate YII... request header on a subsequent response. At this point you need to shove that negotiate header and that original service account password into something that can validate Kerberos tickets. Windows SSPI will do this for you, but it's a pain. I built a library that'll do this for you: Kerberos.NET. YMMV with what works best for you.
All of that said, it may be more beneficial to switch over to a more modern authentication mechanism like OAuth/OpenIDConnect/SAML.
There are several ways depending on if you have to allow access to users who are associated with a on-premise Active Directory or not.
You should have a look at this service: https://learn.microsoft.com/en-us/azure/active-directory-domain-services/
It will offer an Active Directory within Azure where you can domain join your VM to and then using Kerberos as authentication protocol (should work the same way like on prem).
The other option would be to create a new Active Directory within your Virtual Network (via 1 or 2 small Windows Server VMs where you create the AD).
The good thing if you are using Active Directory Domain Services would be that you could extend it to your on-prem Active Directory by synchronizing or federating your on-prem AD.
There are more informations regarding these scenarios here:
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-hybrid-identity
For a Azure App Service - Web App you would connect it to your Azure Active Directory (AAD) and use the hybrid identity model to allow users who originate from an on-prem AD access to it:
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
Hope this helps a bit, it is a rather complicated topic you are digging into.
We are trying to put an app on the marketplace which needs multiple client_ids
(The app is running on appengine standard with python 2.7)
a client_id for the service_account with domain wide authority
a client_id for the web application
a client_id from an apps-script library
All client_ids use different scopes. I have combined all scopes and entered them on the marketplace SDK configuration.
When i deploy the app on a test domain, only the serviceaccount seems to be authorized.
When the user then access the webapplication he is presented a grant screen which we want to avoid.
The documentation https://developers.google.com/apps-marketplace/preparing?hl=fr seems to imply that multiple client_id's are possible.
How should i configure the marketplace app so that multiple client_ids are authorized?
Is there something special i should do on the credentials configuration page of the api-manager?
Check how you implement the authorization using OAuth 2.0, Service accounts allow a Google Apps domain administrators to grant service accounts domain-wide authority to access user data on behalf of users in the domain. You can also read Server to Server Applications documentation.
Note: You can only use AppAssertionCredentials credential objects in applications that are running on Google App Engine or Google Compute Engine. If you need to run your application in other environments—for example, to test your application locally—you must detect this situation and use a different credential mechanism (see Other). You can use the application default credentials to simplify this process.
Hope this helps.
It turned out all three client_id's were being authorized after all.
the days that i was testing this, it took very long for the authorization to take effect.
At this time all scopes and clientid are authorized within a few minutes.
I am running a Kubernetes cluster hosted on GKE and would like to write an application (written in Go) that speaks to the Kubernetes API. My understanding is that I can either provide a client certificate, bearer token, or HTTP Basic Authentication in order to authenticate with the apiserver. I have already found the right spot to inject any of these into the Golang client library.
Unfortunately, the examples I ran across tend to reference to existing credentials stored in my personal kubeconfig file. This seems non-advisable from a security perspective and makes me believe that I should create a new client certificate / token / username-password pair in order to support easy revocation/removal of compromised accounts. However, I could not find a spot in the documentation actually describing how to go about this when running on managed Kubernetes in GKE. (There's this guide on creating new certificates explaining that the apiserver needs to get restarted with updated parameters eventually, something that to my understanding cannot be done in GKE.)
Are my security concerns for reusing my personal Kubernetes credentials in one (or potentially multiple) applications unjustified? If not, what's the right approach to generate a new set of credentials?
Thanks.
If your application is running inside the cluster, you can use Kubernetes Service Accounts to authenticate to the API server.
If this is outside of the cluster, things aren't as easy, and I suppose your concerns are justified. Right now, GKE does not allow additional custom identities beyond the one generated for your personal kubeconfig file.
Instead of using your credentials, you could grab a service account's token (inside a pod, read from /var/run/secrets/kubernetes.io/serviceaccount/token), and use that instead. It's a gross hack, and not a great general solution, but it might be slightly preferable to using your own personal credentials.
We have a Windows app hosting a WebBrowser control that hits our REST APIs. We like to restrict access to the APIs to be only coming from withing the Windows app itself (for example, the APIs cannot be accessed in a browser, etc).
How can we accomplish that? what is the most secure way without having to expose any kind of credential (for example, if we use HTTP Basic auth, the username and password can be seen by reverse engineering the app itself)?
Thanks a bunch!
EDIT: We plan to distribute the application freely so we have no control over where the connection will be made from.
Restrict the REST interface to only accept connections from 127.0.0.1 (home) and then connect from your rest-consuming application only with http://localhost or http://127.0.0.1 in the URLs (if you use the external IP or DNS name of your machine it'll be treated as a remote connection and denied access).
You can do this with web server settings, or within the code of your REST APIs
I had a similar situation during a project where we distributed an iPhone app that also connected to a REST api that my team developed.
For security we used somewhat of a three-legged scenario. The app was required to authenticate using the user's credentials against a standalone service responsible only for authenticating and generating access tokens. Once the app received a valid access token, subsequent requests to the api required sending this token in the Authorization header.
You could do something similar. If you come up with a credential scheme to authenticate your app as valid API consumers you could use basic auth over HTTPS to obtain tokens, and then only by using those tokens could a consumer gain access to the rest of the API.