Istio injection required on the Gitlab migrations job when using Istio hardened
Bug
Description
The AuthorizationPolicy
allow-intranamespace uses the workload identity mTLS certificate to determine the namespace a request is coming from. Since the Gitlab migration job has the sidecar.istio.io/inject=false annotation, the migration job does not have a sidecar (or mTLS workload identity). This prevents the gitlab migrations job from communicating with Gitlab redis. It then fails the wait-for-deps
script check and logs errors where it cannot communicate with redis.
The ideal solution would be to re-enable the Istio sidecar injection for the gitlab migrations job, thus giving it a mTLS certificate for the AuthorizationPolicy
to check against. Another (workaround) solution would be to create a new AuthorizationPolicy
which fully opens the redis port at the TCP level without checking the mTLS workload identity of the Gitlab migrations job (since there isn't any). This would push the enforcement down to the NetworkPolicy
level.
Example policy:
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: allow-any-redis-ingress
namespace: gitlab
spec:
action: ALLOW
rules:
- to:
- operation:
ports:
- "6379"
selector:
matchLabels:
app.kubernetes.io/name: redis
BigBang Version
2.27.0 with gitlab.values.istio.hardened.enabled=true