Vigil, the identity-aware proxy (IaP) implementing the Service and intercepting the requests coming from the Users to the protected upstream resource is capable of operating at several widely used application-layer protocols. This application-layer awareness is capable of providing "secret-less" access for your Users to the protected upstream where such application-layer credentials required to authenticate to the upstream are injected on-the-fly by the Service and sent to the protected upstream without having to share them with your Users. Such application-layer credentials could be API keys and access tokens for HTTP-based resources, SSH passwords and private keys, PostgreSQL and MYSQL passwords, or mTLS for many other application-layer protocols.

Providing secret-less access solves a whole class of vulnerabilities and security-related issues that come with having to manage, distribute, share and securely store such application-layer credentials especially at scale:

• Such credentials usually have too much privileges or simply no limits whatsoever permission-wise. For example, a SaaS API access token with a full access or full write access to the API because the SaaS provider does not provide a fine-grained way to control the permissions of the access token (e.g. access to certain certain paths, API versions, type of access such as read/write or read-only, etc...).
• Such credentials can be too long-lived. For example an API key that does not have an expiry date, an SSH password or private key naturally does not have an expiry date or a TLS certificate used for mTL authentication that expires within months or years from its creation date.
• Such credentials need to be managed and stored securely by the users who have to use them. This by itself increase the attack surface of the entire system and one of the leading causes to countless serious breaches worldwide every year. This problem can be mitigated by delegating the problem to secret managers and vaults to manage and share the credentials. However, the problem, even if mitigated to an extent depending on the capabilities of the secret manager, is still there and is merely delegated to another layer that suffers from the same fundamental problem.

Octelium solution is to simply eliminate distributing such credentials to Users, and instead manage them from within the Cluster via Secrets (read more here), and transparently inject them on-the-fly for authorized Users' requests. Octelium supports secret-less access for the following modes:

• HTTP, GRPC and WEB modes where you can provide secret-less access without having to share and manage API keys and tokens, OAuth2 client credentials, etc... (Read more here).
• SSH mode where you can provide secret-less access without having to share and manage passwords, private keys or manage a PKI (Read more here).
• POSTGRES mode where you can provide secret-less access without having to share and manage passwords (Read more here).
• MYSQL mode where you can provide secret-less access without having to share and manage passwords (Read more here).
• KUBERNETES mode where you can provide secret-less to Kubernetes cluster APIs without having to share or manage Kubeconfigs, bearer access tokens or TLS client certificate private keys (Read more here).

Mutual TLS

In addition to the L-7 specific credentials (e.g. HTTP API keys or PostgreSQL passwords), many application protocols are protected by mTLS. Octelium also provides secret-less access to mTLS protected resources by using a client certificate to authenticate to the mTLS protected upstream server.

Here is an example. First you need to create a Secret that contains your certificate information (i.e. the PEM representations of both the certificate chain and private key) as follows:

octeliumctl create secret client-crt-nats --cert /PATH/TO/CERTIFICATE_CHAIN.PEM --cert-key /PATH/TO/CERTIFICATE_PRIVATE_KEY.PEM

After creating the Secret, you can now reference the Secret by its name to be used in mTLS authentication to the upstream as follows:

1
kind: Service
2
metadata:
3
  name: nats
4
spec:
5
  mode: TCP
6
  port: 6443
7
  config:
8
    upstream:
9
      url: tcp://tls-app:6443
10
    clientCertificate:
11
      fromSecret: client-crt-nats

In many cases, you might also want to explicitly set one or more trust root certificate authorities (CAs). You can add a list of root CAs as follows:

1
kind: Service
2
metadata:
3
  name: nats
4
spec:
5
  mode: TCP
6
  port: 6443
7
  config:
8
    upstream:
9
      url: tcp://tls-app:6443
10
  config:
11
    clientCertificate:
12
      fromSecret: private-key-pem
13
      trustedCAs:
14
      - |
15
        -----BEGIN CERTIFICATE-----
16
        .......
17
        -----END CERTIFICATE-----