Create a `Policy` CRD

[bennesp]

Is your feature request related to a problem? Please describe.

Currently, when using Pomerium as an ingress controller, configuring policies for access control requires embedding the policy rules directly within the annotations of each Ingress resource. This can lead to duplication of policy definitions across multiple Ingress resources and becomes cumbersome to manage as the number of Ingress resources grows.

Describe the solution you'd like

I propose the addition of a custom resource definition (CRD) for "Policy" that can be referenced in the annotations of Ingress resources. This would allow users to define access control policies in a centralized location and reference them in the annotations of multiple Ingress resources, eliminating the need for redundant policy definitions. This approach would also alleviate the frustration of embedding multi-line YAML configurations within the annotations, which can be cumbersome and error-prone to manage.

Example:

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: ns-1
  annotations:
    ingress.pomerium.io/policyRef: "policy-example"
spec:
#  ...

# policy.yaml
apiVersion: ingress.pomerium.io/v1alpha1
kind: Policy
metadata:
  name: policy-example
  namespace: ns-1
spec:
  allow:
    and:
    - domain:
        is: example.com
    - claim/groups: admin

Describe alternatives you've considered

An alternative approach would be to continue embedding policy rules within the annotations of Ingress resources. However, this approach does not scale well and can lead to maintenance challenges as the complexity of access control policies increases.

Explain any additional use-cases

Utilizing a Custom Resource (CR) for defining access control policies offers a more cloud-native approach to managing security configurations within Kubernetes environments. By leveraging CRDs, users can adhere to Kubernetes best practices and seamlessly integrate access control policies into their declarative infrastructure-as-code workflows. This enables easier versioning, auditability, and scalability of access control configurations across dynamic cloud-native architectures. Additionally, employing CRs enhances interoperability with other Kubernetes-native tools and platforms, fostering a more cohesive and efficient Kubernetes ecosystem.