I have 2 terraformed/k8s-yaml services that have IAP enabled.
In order to maintain the member access list between infra refreshes (when the load balancers get destroyed and so the access list gets wiped) I have assigned the IAM role 'IAP-secured Web App User' to the relevant users.
e.g.
resource "google_project_iam_member" "bob_iap_web_app_user" {
role = "roles/iap.httpsResourceAccessor"
member = "user:bob.cat#meow.com"
}
However this allows access to all IAP protected APIs within the project. Is there a filter you can add to only allow access to a particular load balancer?
I can think of two ways to do this:
Wait for https://github.com/terraform-providers/terraform-provider-google/issues/2613 to be implemented.
You can use conditional grants at the project level to set up something like "bob.cat has access if request host is meow.com, alice.dog has access if request host is woof.com".
--Matthew, Google Cloud IAP engineering
Related
How do I create a system user? The goal is using this user as an administrator.
I can only create normal (client) and server (something like client) users, but I'm unable to create a system user.
I tried the Atlas App Services Admin Rest API but there I can do just the same I can here.
I see that a possible solution is adding custom user data but there isn't a way in the console.
Any solution?
A server user is for backend access to your database. This may be useful if you are looking to perform backend database administration.
When you use Atlas App Services, you are creating users for frontend access to user-appropriate data. If you want to create users on the frontend with a role/privilege of 'Administrator', then you need to implement that logic.
You can create custom data for users, which is a separate document linked to the user with additional fields. A simple implementation would be a custom field 'isAdmin'.
A rule would need to be implemented to only give your frontend users access to restricted data once 'isAdmin' === true. For example:
{
"%%true": {"%%user.custom_data.isAdmin"}
}
For more rule examples: https://www.mongodb.com/docs/atlas/app-services/rules/examples/
When I create a service principal it also creates an App in Active Directory.
az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/123456a1-a1b2-1234-12ab-12a3b4cdef67"
If I go to the Azure Portal - Active Directory - App registrations it shows all the applications registered.
I have managed to find the service principal I use for terraform by matching the terraform client_id with the Azure "Application (client) ID". It also had a human readable display name (although not the best since I still had to look via client id!)
However, there are several others where the display name is just "project_subscription".
They look like they must have been generated automatically when setting up a pipeline registering a web app in the portal or something.
I can't tell if they are actually used or if they were just created for experimenting and are then left over.
How do I know what they are for and if they are still used or not?
Is it possible to search Azure for the id or anything?
Is it possible to add a description to these to identify what they are used for beyond just the display name?
e.g. I only identified the terraform one by matching up the id with my code
App registration can be used for many scenarios, the app registrations in your AAD tenant should be created by different users. There is no such thing as a description of them.
To see if they are used, it needs to combine the context, as in AAD, there are different usages for them. For example, there are no sign-in logs of the AD App's corresponding service principal, but you cannot make sure if it was used as a client app. For the details, you may need to check the Audit logs.
For more details about AD App(App Registration) and service principal, you could check this doc - https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
I have two microservices registrations, which is responsible for registering new users, and users, which hold information about users. Each of them has it's own database.
When a user tries to register, a call to users is made via the API, e.g.
GET users/verify?email=foo%40bar.com
to chech if the email has been already assigned to a profile. Although I could hide the access point users/verify in the public docs, it can still be accessible.
What is the best way to allow only private IPs make requests to the API?
You may use a Gateway, some alternatives are
Tyk
Kong
Netflix/Zuul
There is a nice article at https://thenewstack.io/api-gateways-age-microservices/
Keep it simple. Do it at the firewall level
Whitelist the IP(s) that you want to be able to make requests, reject the rest
I want to automate virtual server deployment on SoftLayer using API (REST API preferred). The idea is to create a new user in the portal with API access but I want to restrict its access to only some calls: Order Virtual Server or Get virtual servers detail.
But do not allow the user to access other services like: Bare metal ordering, determine next billing and all operations related to billing/invoice.
Is it possible to limit API access for a user for that use case ?
Thank you.
what you can do using the API is the same that you can do using the Softlayer's control portal, You can see all the permission that you can grant to the users by going to:
Account->Users on menu
Click over an created user and click on permissions
There is a permission to allow to your users see the billing items, this permission is called "View Account Summary" so you can disable the permission and your usaer will not be able to see the invoices. For servers there is a permission called "Add server", but this permission is for Bare metal servers, Virtual guests and for the rest of oders if you disable this permission your user will not able to order neither Bare metal servers nor Virtual guest.
Now using the API you just need to use the method:
http://sldn.softlayer.com/reference/services/SoftLayer_User_Customer/addPortalPermission
e.g. using REST:
POST https://$USER:$apikey#api.softlayer.com/rest/v3/SoftLayer_User_Customer/$USERIDOFUSERTOEDITPERMISSION/addPortalPermission
payload:
{ "parameters": [
{
'keyName': 'TICKET_ADD'
}
]}
You can use this method to get the list of all permissions in softlayer:
https://sldn.softlayer.com/reference/services/SoftLayer_User_Customer_CustomerPermission_Permission/getAllObjects
Regards
I'm using Node.js with Loopback (based on Express) for the REST API. It has an ACL implementation that allows you to give/prevent access from/to parts of the API to a Role.
The front-end of the application is written with React and Redux.
The app will have a public and a private part, and I want people to be able to log in to /admin.
Next to the ACL for the REST resources, should there be a separate Authorization mechanism for the front-end?
Say I want to be able to access the #/admin page and my user is part of a role that allows you to look up information about users; How do I decide that my user can access the admin dashboard and how do I decide that my user may add a widget that makes use of the users API, to which his Role has been granted access?
Use flashboard for loopback admin dashboard.
Its automatically generate your admin panel based on your models configs.
vah7id.github.io/flashboard