Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a Policy CRD #925

Open
bennesp opened this issue Mar 20, 2024 · 0 comments
Open

Create a Policy CRD #925

bennesp opened this issue Mar 20, 2024 · 0 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. NeedsProposal

Comments

@bennesp
Copy link

bennesp commented Mar 20, 2024

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.

@kenjenkins kenjenkins added NeedsProposal NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. NeedsProposal
Projects
None yet
Development

No branches or pull requests

2 participants