Skip to main content
Version: 9.2605.x.x RR

GitCredentials file format

The GitCredentials custom resource allows you to specify all the required information that pods will need to pull configurations from a git repository. This includes the URL to the repository, a private SSH key paired with a public key registered on the git instance, and the public key from the git instance in the form of a known_hosts entry. In case of an HTTP(S) connection, the basic-auth section has to be defined. If the git server's HTTPS certificate is issued by a private/internal CA, the CA certificate can be provided via caCert.

This resource should be pushed to the namespace that will require it. In other words, the GitCredentials CR should be pushed to the namespace where the components will be deployed prior to the deployment of the components.

When nevisAdmin 4 is installed with the Helm chart, the chart generates this resource automatically. Do not create the resource manually in that case. Configure the Git repository and credentials with the chart's git.* values instead.

Sample GitCredentials CR​

apiVersion: operator.nevis-security.ch/v1
kind: GitCredentials
metadata:
  name: gitea-credentials
spec:
  url: ssh://git@gitea-ssh.gitea.svc.cluster.local/nevis-platform/nevis-images.git
  knownHosts: |
    gitea-ssh.gitea.svc.cluster.local ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBE1/DDlIafsEPikxj62YgKYwqNLxvN443IZJq63jKteXT9oefkcsIOueCwacJOx4iRRpTnElrZ3zMK3GZ0iedM=
  sshPrivateKey:
    key: |
      -----BEGIN RSA PRIVATE KEY-----
      Proc-Type: 4,ENCRYPTED
      DEK-Info: AES-128-CBC,464781EEE2FED73CD0D7177EE6289EF7

      Q6FWit4R9Cyj9WyvAvk9zpKo05kBHdr6bC6dvi5tTZ9Y76IAsnUurA01OI76Arvo
      LQWXq6xAyMmgEv6kcmZzxvAVIqkyj/fK7m2VcEAR1j4D8OWuJ04tRTk1U7BILVWQ
      94je0kQ6yoclJdqbdGNfhru1MQMp1gesVvrMEZ9am61+ybAPnPgZVBNogyeQdmKW
      2dS1+D6jOtAWyvfsl4Qf/Db8HsnSIB29/tTwAQuoKy4piQjKEMJxcAZurgRAa8yz
      qQk6Z5GHmXLldza2uJNV9ZGjYT4ibdkPzfOKCrySm95TRgbPX60LkSobuZ1ByOAT
      8jdZSGwMeb0dSERY4UOmaNukmNDylS5Exny5uZqSiywVdDuU1SPXi3eJN4btS4/9
      Jy+9fmmY8geQn6rFAF6/jIrMJG35af6IPyzKRfGN9s60+3RV+zjCU3vPaN9BqxLZ
      qrVnW/LZRGFFmbjWQIOIzMQh90ImzxZ60aZ83KFAOPNy4Wpda1ZH7WlLiBSsy/m9
      jyvES0Gw87qrTxGyfEDK6r+SgqrwGL/exh3iD98l0fYTl27xYkhz0Nqn8EHUJw6z
      kAVoJ2Ztzm0At3dq4uGOpya09uwXMJZzuccLMhAT/wHgq8i2F1+ISVfl6Xnccasg
      PD89HlecfKsg+TT5lbIW9zglVyer4FOiirsMgQo76berp0RTr5FPUHbwfuLU5N5g
      KhnJk+1tUz6zD2THUWQ9USoMD6+qrrN9k0FW+u6Q7uqMSG7Bus5qwwZUDuRsP6We
      SnFaBPSh3kf93AU8OBIzfNUDvOWCBiWwzPVtiSP5uDuWmsBX0E96daO6p65eAdaw
      c8YBGANbf84gq5MXG8IKg+sbbn9jWhxV9uEDg9dyY8qFakM03bAGq94Un15XYmNC
      eyFgLgTm80UtvPgH7a7I2ACZWmTWv4V0B+WH33S5F7iGYrXGL6+3q5q1xdhsxNFY
      9pT+kdqDPXB2f3D9IuEuuX5BmQF5hjbvd+N8PwaFx1QtikJKnG76hzSo+IimxYd+
      VOL8QVFPwaSKk3aOrC+qljDymyFYaKwCGn1RVKBZ1WuPEhYStwcLaKZjStCfDvK6
      yb9WLPurWt8QgJwwLVZKqSXm748S36A8GYJ7zWrXpM0o9pKwJ7B3RkO5467XOecb
      4AwUns4EbK1j01O2Nv8tLKnwfEjWW71w1c9d3qPJt3hbp859FvHngZqDnRNfEYoB
      aY+THBc7ZV4+NxjGGTR7I28a6A3sQl+LtBSifGpNqXK1dWBvwCgsRqwG/zymm0LK
      c1+fT9yvW1tVp0uRjVDm5INkTNDLfJFIOMuhH6/DN/6/N+jrXWNwATHvXAC26gZZ
      kz0CTifYNhq+CWhtW4cNdgUxRK1vAj1WDtpoKn6eVIqUTfbsejWbAh+b/iq0a3BY
      8A+/ELw4MEBeCLS8y6vq3K14qcbrI5R4inHI3Hmawp1QjNch457y68gpv75qygUA
      Vr/nOew8RuS8GLYiaUrOXnqrhBLc0yQcBCJi2qPR6C0IUYfalQx5RjJOsI3lvvO2
      C6cuXdNHGVhoFomdslnsyuiK3XqioNt7IEpWrgwqUGFnLk7LKiANcRr6hJJRtRVn
      -----END RSA PRIVATE KEY-----
    passphrase: BmPw65LG6AUz
    basic-auth:
      username: mygituser
      password: mygitpassword

It is also possible to use a prepared secret for the credentials. Note that if the secret is updated then nevisOperator has to be restarted. For this reason it is recommended to create a new secret for the new credentials. The prepared secret has to have the username and password or the passphrase and key, depending on which authentication mode (basic-auth or SSH) the url requires; keys that are not relevant to the chosen mode do not need to be present. This differs from the Helm chart's git.credentialSecret convention, which always expects a fixed set of six keys regardless of the auth mode in use.

apiVersion: operator.nevis-security.ch/v1
kind: GitCredentials
metadata:
  name: gitea-credentials
spec:
  url: ssh://git@gitea-ssh.gitea.svc.cluster.local/nevis-platform/nevis-images.git
  knownHosts: |
    gitea-ssh.gitea.svc.cluster.local ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBE1/DDlIafsEPikxj62YgKYwqNLxvN443IZJq63jKteXT9oefkcsIOueCwacJOx4iRRpTnElrZ3zMK3GZ0iedM=
  credentialsSecret:
    name: gitcreds

As seen in the CR declaration above, the specification of the GitCredentials defines the three entities listed before:

  • The URL obtained from the git repository.
  • For SSH
    • The known hosts entry built from the hostname, encryption algorithm, and public key of the git instance.
    • The SSH private key that is linked to a public key registered on the git instance. It is comprised of:
      • The actual key.
      • The passphrase, if the key is encrypted. This can be omitted if no passphrase was used.
  • For HTTP
    • The username of the git user.
    • The password of the git user.

The HTTP and SSH options can be defined at the same time, the URL decides which one is used.

Using a private/internal CA certificate for HTTPS connections​

If the git server is accessed over HTTPS (https://... URL) and its certificate is issued by a private or internal CA (rather than a publicly trusted one), the CA certificate has to be provided so that the connection can be verified. This is done via the caCert field, which, like knownHosts, is public trust material, not a secret.

apiVersion: operator.nevis-security.ch/v1
kind: GitCredentials
metadata:
  name: gitea-credentials
spec:
  url: https://gitea.example.com/nevis-platform/nevis-images.git
  caCert: |
    -----BEGIN CERTIFICATE-----
    MIIBvTCCAWICCQDo0O5oJVh4RTAKBggqhkjOPQQDAjBjMQswCQYDVQQGEwJDSDEP
    ...
    -----END CERTIFICATE-----
  basic-auth:
    username: mygituser
    password: mygitpassword

Just like knownHosts, caCert can alternatively be supplied via the credentialsSecret, using the key ca.crt, instead of being set inline on the CR:

apiVersion: operator.nevis-security.ch/v1
kind: GitCredentials
metadata:
  name: gitea-credentials
spec:
  url: https://gitea.example.com/nevis-platform/nevis-images.git
  credentialsSecret:
    name: gitcreds # must contain the "username" and "password" keys, and optionally a "ca.crt" key

For a Helm deployment, configure the CA certificate with git.caCert64, which contains the base64-encoded PEM certificate, or add a ca.crt key to the Secret referenced by git.credentialSecret:

git:
  credentialSecret: my-git-credentials
  caCert64: <base64-encoded-PEM-certificate>

The chart writes git.caCert64 to the generated GitCredentials.spec.caCert. If both git.caCert64 and the Secret's ca.crt are configured, git.caCert64 takes precedence. The same git.credentialSecret can contain the Git authentication keys and the ca.crt key.

If caCert is not set (neither inline nor via credentialsSecret), the git-init container falls back to the system's default truststore, which is the existing behavior for deployments that do not require a private CA. This CA configuration applies to git-init; nevisAdmin itself requires the CA in its separately configured Java truststore. See Git Setup and Best Practices for the nevisAdmin 4 Helm chart configuration.