Discuss: Policies support various parameter values for different containers

[fseldow]

Context

It is about one requirement that wants to set policy parameter value on container level. Original issue link is https://github.com/Azure/azure-policy/issues/890

Currently, I can provide a workaround for this issue that suggest cx to assign additional constraints on the except container (use label selector to target container). Then it might be one constraint one container.

Will be suitable to add one new map-structure (container-value) parameter just as the issue suggested? Or do you have any other idea about this?

Below is Duplication of issue description:

Details of the scenario you tried and the problem that is occurring

We have an application container that needs SYS_PTRACE capability to be able to send SIGHUP signal to another container process. One way to allow this is by defining allowedCapabilities = ["SYS_PTRACE"] parameter. But if we do this, it basically means any other application container will also be able to use SYS_PTRACE capability, which is not intended. Other way is to exclude the app container that needs the capability by defining excludedContainers = ["app1"] as an example and not add anything to allowedCapabilities. This way no other app container can make use of SYS_PTRACE here. But that would allow app1 container to use any other capability (as its excluded from policy evaluation)!

(Comment: we have name based container exclusion in azure policy for now whereas gk-lib is using image based. I am introducing image base exception for now, but it takes no differences in this issue)

Verbose logs showing the problem

Suggested solution to the issue

So I would like to suggest to have a parameter like allowedCapabilities as a map(/object) of array instead of plain array, where key will be container_name and value would be an array of capabilities allowed for that specific container. So we can specify it something like below, where app1 and app2 are container names allowedCapabilities = { "app1" : ["SYS_PTRACE"] , "app2" : ["SYS_RAWIO"] }

This way we can make sure that specific containers have the required capabilities they need.

Though I took ContainerAllowedCapabilities as an example, similar logic shall apply for few other policies like AllowedHostPaths.

If policy is Guest Configuration - details about target node

[fseldow]

My personal opinion is not to add such map-structure parameter. Because it is sort of like the policy is one duplicated configuration of cluster and it will improve the usage complexity and confusion. In my understanding, policy should be one general standard but not such restricted that each container has each standard?

[maxsmythe]

Allowing special parameters for specific containers via map is interesting. It does have a "priority" problem... if a container could be matched by more than one key in the map, which one takes precedence? Apply all possible allow lists (this would default to the most restrictive set of allowed capabilities)?

OTOH, the idea of constraints is that each new constraint further attenuates the set of allowed states, so expressing this with multiple constraints is valid... the exceptionless constraint effectively defines the maximum set of allowed permissions, which gets further constrained.

The map approach does have an advantage in that it allows for multiple different exceptions (one might require PTRACE, another RAWIO, as you point out.

Instead of a map, I would use a list of objects (which is more K8s-like):

specialAllowedCapabilities:
- container: "system-containers.my.company/*"
  allowedCapabilities: ["SYS_PTRACE"]
- container: "loggers.my.company/*"
  allowedCapabilities: ["SYS_RAWIO"]

[AshutoshNirkhe]

Allowing special parameters for specific containers via map is interesting. It does have a "priority" problem... if a container could be matched by more than one key in the map, which one takes precedence? Apply all possible allow lists (this would default to the most restrictive set of allowed capabilities)?

OTOH, the idea of constraints is that each new constraint further attenuates the set of allowed states, so expressing this with multiple constraints is valid... the exceptionless constraint effectively defines the maximum set of allowed permissions, which gets further constrained.

The map approach does have an advantage in that it allows for multiple different exceptions (one might require PTRACE, another RAWIO, as you point out.

Instead of a map, I would use a list of objects (which is more K8s-like):

specialAllowedCapabilities:
- container: "system-containers.my.company/*"
  allowedCapabilities: ["SYS_PTRACE"]
- container: "loggers.my.company/*"
  allowedCapabilities: ["SYS_RAWIO"]

@maxsmythe what do you mean by "system-containers.my.company/*" as a container name ? Is it like FQDN of service to identify 2 containers with same name ?

[maxsmythe]

@maxsmythe what do you mean by "system-containers.my.company/*" as a container name ? Is it like FQDN of service to identify 2 containers with same name ?

It means "match all containers that have a prefix of system-containers.my.company/"

[stale[bot]]

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.