Add MTLS support

[obeyler]

Checklist

• I've searched the issue queue to verify this is not a duplicate feature request.
• I've pasted the output of kargo version, if applicable.
• I've pasted logs, if applicable.

Proposed Feature

On Create Credentials, we should have the opportunity to specify a client certificate ( CRT,KEY, CA) to be able to connect on repository protected by MTLS.

Motivation

In our case both our self hosted Gitlab and Harbor registry (docker image and helm) are protected by MTLS and login/password

Suggested Implementation

[krancour]

@obeyler even though this doesn't seem like a lot of work, before going too far down this rabbit hole, I am wondering if this problem isn't best addressed with a service mesh.

[jessesuen]

I think in their use case, mTLS is being used a second layer of client authentication to that specific server. So even if the kargo pods were meshed with gitlab/harbor servers, the user still may only give the client certificates to select, trusted clients, and not everything on the mesh.

Does anyone know if it's possible for the client certificates used in mTLS to be dropped into well-known operating system paths (e.g. /etc/ssl/certs) to be picked up by applications like curl, wget, golang's HTTP SDK? Similar to how you can drop in root certificates at the OS level? If this is possible, I wonder if kargo itself could be volumeMounted with the client certs and automatically pick them up without an explicit feature needed to be developed.

[krancour]

I think in their use case, mTLS is being used a second layer of client authentication to that specific server.

Right. But it's the fact of it being a second factor rather than the only factor, that raised for me the possibility that the requirement possibly could be met with a mesh. It's what prompted the request for more details.

I can equally see the possibility that a mesh solves the problem here or that it doesn't.

the user still may only give the client certificates to select, trusted clients, and not everything on the mesh.

It's been a while since I've gone deep on any meshes, but I think routing rules can constrain a service to permitting ingress only from specific services or namespaces rather than simply permitting ingress from any service in the mesh.

Does anyone know if it's possible for the client certificates used in mTLS to be dropped into well-known operating system paths (e.g. /etc/ssl/certs) to be picked up by applications like curl, wget, golang's HTTP SDK? Similar to how you can drop in root certificates at the OS level? If this is possible, I wonder if kargo itself could be volumeMounted with the client certs and automatically pick them up without an explicit feature needed to be developed.

If a mesh doesn't meet the need, this may not either (if it's even possible, that is) because this would be roughly equivalent to using a mesh insofar as all the outbound traffic would use a single client cert as opposed to selecting a specific client cert from a credential/Secret.

[obeyler]

I think mesh service is a little bit oversized for this and implies a lot of other constraint. I hope that as argocd did it for git or helm repository for might be easy to be inspire

[obeyler]

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: kargo-demo-repo
  namespace: kargo-demo
  labels:
    kargo.akuity.io/cred-type: git
stringData:
  repoURL: ${GITOPS_REPO_URL}
  username: ${GITHUB_USERNAME}
  password: ${GITHUB_PAT}
  tlsClientCertData: ##optional value
  tlsClientCertKey ## optional value

can be possible yaml to allow git or an docker registry protected behind a MTLS, ( same as argocd does)

[krancour]

@obeyler thanks. I don't see this as being a problem. I just wanted to be sure that the notion of a service mesh wasn't being completely overlooked in the event that it was a viable option.

[raphaelappsolute]

+1 to increase priority

[ManuHeel]

+1 same issue here

[juleshry]

+1

[m3astwood]

Another +1 interested

[timbtimbtimb]

+1

[krancour]

It is clear to us that this is a popular feature request and we are factoring that into our planning. To spare the team from some noise, further +1s aren't going to move the needle any more than it's already been moved.