Gitea: Test and confirm that prot-b deployment works in dev

[cboin1996]

Refer to epic here

[cboin1996]

Outstanding work:

• [ ] Configure networking to allow namespaced gitea deployments to communicate with the azure managed psql db's.
• Use this as a template:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
  labels:
  argocd.statcan.gc.ca/instance: network-policies
  name: allow-profile-controller-to-internet
  namespace: daaas-system
  spec:
  egress:
  - ports:
  - port: 5432
    protocol: TCP
  to:
  - ipBlock:
      cidr: 0.0.0.0/0
  podSelector:
  matchLabels:
    app.kubernetes.io/name: profiles-controller
  policyTypes:
  - Egress

[Collinbrown95]

Update

The issue appears to be twofold:

1. a network policy allowing egress to all IPs on port 5432 is required as @cboin1996 suggested above, and
2. there is a race condition where the configure-gitea init container is starting before the istio-proxy container starts up. Because of (2) the init containers don't have networking setup, so the configure-gitea job cannot connect to the managed postgres instance.

Manual Solution

I was able to get the configure-gitea init job to succeed by manually doing the following steps:

1. Set the securityContext of the configure-gitea init container to run as user 1337.
2. Set the following annotations on gitea pods: traffic.sidecar.istio.io/excludeOutboundIPRanges: 0.0.0.0/0 and traffic.sidecar.istio.io/excludeOutboundPorts: "5432".
3. Manually deploy the gitea statefulset and then immediately delete the metadatarestrictions ConstraintTemplate. The metadatarestrictions ConstraintTemplate has an enforce-protected-b-istio constraint that prevents the annotations mentioned in (2) from being added to the pod metadata. I was not able to turn off ArgoCD auto-sync, so manually deleting the constraint was the only way to prevent the gitea pod from getting blocked at admission control.

Note: steps (1) and (2) are documented by Istio in the following workaround for init containers.

When all 3 steps mentioned above were performed, the configure-gitea init container was able to complete successfully and the gitea pod started up successfully.

Next Steps

I propose the following next steps - we may wish to discuss as a group as there is a proposed change to a Gatekeeper constraint.

1. Create the namespaced network policy to allow egress to port 5432 - this needs to be done in the aaw-kubeflow-profiles- controller as we need to allow this egress to be performed by gitea pods in each namespace that opts into using Gitea. E.g. policy shown below

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  labels:
    argocd.statcan.gc.ca/instance: network-policies
  name: allow-gitea-to-postgres
  namespace: christian-boin
spec:
  egress:
  - ports:
    - port: 5432
      protocol: TCP
    to:
    - ipBlock:
        cidr: 0.0.0.0/0
  podSelector:
    matchLabels:
      app: gitea
      app.kubernetes.io/instance: gitea-protected-b
  policyTypes:
  - Egress

2. Edit the previously mentioned Gatekeeper policy to allow egress to the port and IP range required by the network policy.
3. Edit the Kubeflow manifests for the unclassified/protected-b Gitea deployment to include the required pod annotations as well as the required securityContext to have the configure-gitea container run in group 1337.

Pull Requests

1. https://github.com/StatCan/aaw-kubeflow-profiles-controller/pull/54
2. https://github.com/StatCan/aaw-gatekeeper-constraints/pull/14
3. https://github.com/StatCan/aaw-argocd-manifests/pull/150

[Collinbrown95]

Both protected-b and unclassified Gitea pods schedule and start up successfully with the abovementioned modifications.