Is there's a way to apply policies to specific groups of operations in Azure APIM?
AFAIK I can only apply policies to the following scopes:
global
API
operation
For my scenario I can't have some of the policies at the API (or global) scope, because some of them are not applicable to certain operations e.g. most API operations are protected by OAuth, but there's a couple of unprotected operations, so I can't put validate-jwt policy at the API scope. It would be nice if I didn't have to replicate the same policies for multiple individual operations.
FYI I tried adding tags to the Open API specification (which I used for the creation of the API), but I couldn't see a way to apply policies to these...
There is no way to do this yet, but a feature request exists which could help. You could up vote this for it gain more traction.
If applicable, one option would be to remove the <base /> tag for the operation, preventing it from inheriting policies from higher scopes (API, Product (if present), and Global).
Related
I am setting up aws CDK for a new stack on aws, and the docs say essentially "use the root account to start up, but then set up a policy for a new account":
However, using their recommended assume/* policy almost immediately leads to errors when trying to cdk deploy. So what is a mechanism for determining a policy useful and applicable to setting up a full cloudformation stack deployment?
For one example use case, when setting up continuous integration to deploy multiple stacks how can we avoid giving it the keys to the kingdom?
Since I am part of the aws community builders community, I asked there as well. Suffice it to say that this is a known problem, and not a trivial one to solve. I will try to distill what I learned into an answer here in broad strokes:
Set up permission boundaries. These can forbid an agent from creating new users and privilege escalation. https://aws.amazon.com/blogs/devops/secure-cdk-deployments-with-iam-permission-boundaries/
Walk your shots/walk your permissions. In other terms, give scant few permissions, then try to deploy, find where additional permissions are needed and add those, try to deploy again, rinse and repeat. This is most applicable if you expect the services of a stack to rarely change.
Draft a permission policy of Allow all... ...then deny in particular. In other words, set a policy on the deploying agent that allows * access to all services... ...and then deny permission to create users, change other users, etc etc. Contained within this approach is: bootstrap, then customize https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html#bootstrapping-customizing
Consider a multi-account strategy, where you would add a new aws account for a different project. Because AWS is usage based payment, they allow for multi-accounting in this way where other services might have policies against multiple accounts. Control tower can help with this.
How many 2-Legged tokens can a Forge App have active at once?
I think the answer is 'more than any reasonable person would ask for', but I haven't been able to explicitly confirm this yet.
That's an interesting question. I don't think there's any limit to how many access tokens you can have at a single point time but I would definitely not recommend generating new token for each request. Not only is it wasteful but you could also run into rate limiting quotas.
The recommended practice is to generate one or more tokens on the server side (for example, one with viewables:read scope for public use, and one with additional scopes for internal use) and only refresh them when they expire.
I wondered if anyone has found a way to audit network security groups in Azure, other than trawl through them all in the Azure UI. I have managed to extract info as json, but still its not terribly easy to decipher as its nested quite deeply. Im looking for NSG's with default any/any rules and other poorly applied rules.
We have several hundred Network Security Groups (to give context).
Anyone have any views how best to go about this?
Depending on what you would like to audit in your NSG security rules, the Azure Resource Graph may be more friendly than exporting the the JSON and parsing. It can be called via the REST API, for example from a Logic App, for regular audits.
A simple query for NSGs with security rules allowing traffic to port 22 is below:
az graph query -q "where type == 'microsoft.network/networksecuritygroups' | extend rules = properties.securityRules | mv-expand rules | where rules.properties.destinationPortRanges contains '22' | summarize count() by id"
Another approach to consider would be to use Azure Policy to audit security rules for specific exceptions.
Lastly, if you are more interested in monitoring changes made to your NSGs than specific exceptions, the Resource Change History feature may be what you are looking for. You can target specific resources and review changes over a time window. Doing so would require some automation on your part, calling the Rest API, etc. See: https://learn.microsoft.com/en-us/azure/governance/resource-graph/how-to/get-resource-changes
I've read RFC7644, and RFC7643, and have a few questions.
First: how do I provision entitlements? I see there's a default methodology for provisioning groups and users. That includes a pretty straightforward mechanism for provisioning users' membership in groups, entitlements they have, and roles they have.
I also see that there's a mechanism for creating a group with members in it during provisioning.
What I don't see is a built-in mechanism for creating a group, and linking entitlements to it (or creating entitlements that are then linked to groups).
Do I need to build a custom schema extension for groups? Do I need to build a custom schema for entitlements?
My second question is: how exactly DO I create custom extensions and schemas? The RFCs are pretty vague about how you might do that while being compliant with their standard.
After re-reading the SCIM standard, I have an answer to at least the first part of my question.
"Group" resources are meant to enable expression of common
group-based or role-based access control models, although no explicit
authorization model is defined. It is intended that the semantics of
group membership, and any behavior or authorization granted as a
result of membership, are defined by the service provider; these are
considered out of scope for this specification.
What this means is that entitlements granted via membership in a group are out of scope for SCIM. If you want to provision entitlements (or non-Group roles), you need to implement it yourself, or build a custom schema extension/custom schema.
Unfortunately, the RFC has yet to yield how you would actually do that last bit.
Given an application that shows objects (e.g. films) according to certain user permissions.
The general permission to show or create objects is implemented as RBAC with roles and permissions.
The specific permission to access an object with certain attributes (e.g. a film with the attribute “drama”) should be implemented with memberships. That means the object doesn’t have the property “drama”, it is a member of the group “drama”. If the user and the object are members in the same group, the user has the specific permission to access this object. There can be different groups for showing, creating or deleting an object, like a simple viewer group or some kind of editor group. Furthermore there is a table that specifies which group types are relevant for certain actions on certain objects. For example relevant groups for the action “show” on the object "film" could be “genre” and “age” (film's suitability for certain audiences).
The reason to implement it in the described way is to have great flexibility without touching the code. Changes to groups can be processed in the database.
General database design:
Example: The film "The Revenant" is a member of the groups "genre:drama" and "age:18". The user can access it, if he is a member of these groups too.
Does this sound like a good approach? Are there any existing solutions that are similar to this approach? Does it have major drawbacks (e.g. too many database queries - there may be several hundred users every day)?
Please share your thoughts on this issue with me - the choice of "drama" as category for the example is not a coincidence ;) I just dont know if this is a dead end or if I am heading to the right direction. I stuck at this point for quite a while.
At least you have a good sense of humor :-)
Your approach sounds fine. So long as you keep the number of parameters low, then you can get away with role-based access control (RBAC) and a few additional parameters e.g. group membership.
But in the long run, if you want to implement business-driven authorization (access control), you need a way to do this independently of your code: you do not want to rewrite your app code every time there is a requirements change.
To do so, there is an access control model called Attribute-Based Access Control (ABAC) that will let you define your authorization policies independently of your code.
In ABAC, you have the following concepts:
an architecture which defines a policy enforcement point (PEP) and a policy decision point (PDP). The PEP sits in front of (or within) your app. It intercepts the business requests (e.g. a request to view a film) and sends an authorization request to the PDP. The PDP is configured with policies. Based on the request the PDP will reach a decision: either yes, Permit or no, Deny.
a policy language: the policy language is attribute-based (hence the name ABAC). This means that you can use any number of attributes (e.g. user role, user id, user group memberships, but also user age, user location, user subscription as well as resource attributes such as movie rating, movie category, movie price...)
a request / response scheme: this is how you ask for authorization. It is essentially a yes/no flow. "Can a user do X?", "Yes they can."
There are several implementations of ABAC out there - some of which are framework-specific e.g. CanCanCan. XACML and ALFA are two approaches that are not tied to any particular framework. You can choose from open-source and commercial implementations of either language e.g.:
Open Source: SunXACML, ATT XACML
Commercial: Axiomatics Policy Server