I am trying to set Deny policy effect for Policy:
"Kubernetes clusters should disable automounting API credentials"
when assigning Azure Security Benchmark (ASB) initiative.
ASB:https://portal.azure.com/#view/Microsoft_Azure_Policy/InitiativeDetailBlade/id/%2Fproviders%2FMicrosoft.Authorization%2FpolicySetDefinitions%2F1f3afdf9-d0c9-4c3d-847f-89da613e70a8/scopes~/%5B%22%2Fsubscriptions%2F6568e31a-1543-434f-9e1d-190387fecd0a%22%5D
Policy: https://portal.azure.com/#view/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F423dd1ba-798e-40e4-9c4d-b6902674b423
While this policy has 5 parameters in the definition:
enter image description here
When I assign it using portal, I can only assign one parameter in the UI.
enter image description here
How can I assign the ASB intiative using the portal and supply the other parameters such as the labelselectors I want to Deny?
If this is portal limitation, how can I apply Deny effect through code while assigning ASB? The only solution I have to achieve this is single policy assignment, which I want to avoid.
Microsoft Product Group (PG) answer:
the initiative uses only 3 out of 5 parameters of the policy definition. The reason why you only see 3 of them in the initiative is because the initiative is set up in a way that the "namespaces" and "labelSelector" parameters use the default value stated in the policy definition. Because of this, you can only assign 3 parameters on when setting up the initiative.
The information that was provided by PG is that this is done by design because the initiative reaches the parameter capability limit.
I'm currently asking if there are any work item focused on fixing this issue to enable the 5 parameters. However, for now, the information that I have is that it's by design.
Related
Is it possible to have a single API in APIM that either accepts AAD token or subscription, based on what product it belongs to?
Default, this does not work, since unchecking "require subscription" on API-level will override setting product to require subscription.
So, I see two solutions.. create two APIs in APIM and place them in separate products (same backend), or write a custom policy. Is there a way to check context.Subscription.Key and match with the product subscriptions?
Should be possible by adding your API to two products:
One with subscription requirement enabled
Another without subscription requirement enabled, but with validate-jwt policy added at product level to require AAD token
I have a product published that does not requires a subscription. The 4 APIs that compose it also does not. How can I define policies on a product level?
Such policies seem to work only when both the APIs AND the product require subscription AND the request is made using the product subscription key.
Prerequisites:
API subscription switched off:
Product subscription switched off:
Product added to API:
Product has policies defined, example:
If above points are true, just call your API without Ocp-Apim-Subscription-Key header and APIM will automatically execute API and attached product policies. If you provide Ocp-Apim-Subscription-Key with correct value, like for example administrator subscription key, APIM will only execute API policies.
To reduce the frustration it is important to understand policy order execution. Read the whole article here but in short the order is:
Global scope
Product scope
API scope
Operation scope
One last thing, if non subscription product is attached to non subscription API and its policies are executed automatically, you may wonder what happens if we add second open product to the API? Policies from which product will be executed? Turns out, this is not possible (what makes sense). Attempting to add second open product will result in following error:
I have a task to create a notification system where I can configure which email goes when based on conditions.
Since I would like it to be multi-tenant and customizable I thought that the conditions could be stored/configured in the same manner as Azure Policy json.
For my system I need:
conditions
parameter replacing
In "then" statement I would point to the notification id.
Is there any out-of-the-box library that I could use for evaluation of this kind of jsons?
Or my only option is to look at the source code of AZ Policy and create such a thing myself.
Thanks,
Rafal
To the best of my knowledge, this would not be possible with policy since policy does not support notification systems.
I would like to ask if someone knows the difference between a "resource" and a "principal", when creating an aws_iam_policy_document in terraform.
The terraform documentation has the following information:
resource: A list of resource ARNs that this statement applies to. This is required by AWS if used for an IAM policy.
principals: A nested configuration block (described below) specifying a resource (or resource pattern) to which this statement applies.
From reading the above two sentences, it looks like they have the same effect, even thought they might do different things.
On further research, I came accross this article, which explains the differences between identity-based and resource-based policies.
It seams to me that this might be the answer to my question. If so, from what I understand, resource is a "resource-based" policy, while principal is a "identity-based" policy. Is that correct?
If this is the case, my follow-up question is: can I can use both type of policies together to further restrict the access?
For example, if i have a resource policy on an S3 bucket granting complete public access, but than I add a identity-based policy for a single user, does this user become the only one who can access the bucket?
I appreciate your help, and will try to clarify anything that might be unclear.
The Terraform documentation on this is a bit confusing. Prefer the AWS docs in this case. However, when TF refers to Principal, they do mean the same thing, i.e. who gets permissions. Who can be users, groups, roles and services.
However, a Principal isn't needed when you have a policy attached to an IAM user, group or role, because the user, group or role is the implied principal.
So why or when would you need a principal section? When the policy is attached to something that isn't inherently a user, group or role. For example, an S3 bucket policy.
HTH!
This is in context of Azure API Management (APIM) Azure service. New UI changes in azure has changed behaviour of policy executions I believe.
I have one policy for jwt-validate set at global level for all APIs.
Recently I had to add new API which doesn't need JWT validation but certificate authentication.
So in APIM I created new API, product and added certificate authentication policy at product level.
When I run my API then JWT policy is also firing. How can I stop it from executing in this case. I removed but it stopped global + product level policy.
I want stop execution of global policy but I want product level policy to execute.
Please advise.
I had the same situation where I needed a specific API to skip a global policy that I had setup for JWT validation. The way that I made it work was by removing the <base /> tag from my API policies.
Of course, this removed all of my global policies not only the JWT-validator. But this was fine for my particular case.
This is not controlled by UI at all and wouldn't have been subject of recent updates. Policy chain is controlled with tag in policies. At operation level tag invokes API policy, at API it invokes Product, at product - global. If you remove from policy document chain will be broken and base policy invocation will not happen. So if for certain product you do not want global policy be invoked for every call - just remove from product policy.