Closed TristanHoladay closed 8 months ago
should we go ahead and implement these netpols since goal is to deploy soon on uds-prod with gitlab and runner?
# enabled: true
#networkPolicy:
# enabled: true
# additionalNetworkPolicys:
# ingress:
# - from:
# - namespaceSelector:
# matchLabels:
# kubernetes.io/metadata.name: gitlab-runner-sandbox
# podSelector: {}
# ports:
# - port: 9000
# protocol: TCP
# egress:
# - to:
# - namespaceSelector:
# matchLabels:
# kubernetes.io/metadata.name: gitlab
# podSelector:
# matchLabels:
# app: webservice
# - to:
# - namespaceSelector:
# matchLabels:
# kubernetes.io/metadata.name: gitlab-runner-sandbox
# podSelector: {}
# podSelector:
# matchLabels: {}
# policyTypes:
# - Egress
# - Ingress
@TristanHoladay might be worth a discussion on how we anticipate comms for pipelines working. One option is just to have all ingress go through the Istio VS, but that does mean egress on the other end is allowed to effectively anywhere. It feels "smarter" to handle traffic "directly" internal to the cluster, but we don't always know if/how runners and gitlab are deployed. It might make more sense to leave those stitching pieces to the environment specific bundle?
That makes sense. So each bundle would deploy a separate package, which is a chart with another CR or traditional netpols to handle making whatever pieces exist in that environment talk to each other?
@TristanHoladay that's my leaning yeah. We have something similar to handle auth pieces for AWS currently in our environment, and I think every environment will probably have a small zarf package that does similar things. Might be good to talk through that a bit and determine if we want to publish examples/a full example package or bundle for those missing bits....
update the sonarqube package to utilize the new operator pattern provided by uds-core