# Secretless Access > Octelium documentation. Canonical page: . ## Overview [*Vigil*](https://octelium.com/docs/octelium/latest/reference/components.md#vigil), the identity-aware proxy (IaP) implementing the *Service* and intercepting the requests from the *Users* to the protected upstream resource, is capable of operating at several widely used application-layer (L7) protocols. This application-layer awareness provides "secretless" access for your *Users* to the protected upstream, by injecting application-layer credentials on-the-fly at the *Service* and authenticating to the protected upstream without sharing 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. *Diagram: OcteliumSecretless.* [View the diagram on the canonical HTML page](https://octelium.com/docs/octelium/latest/management/core/service/secretless). Providing secretless 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 many privileges, or, sometimes, no limitations whatsoever in terms of permissions. For example, a SaaS API access token that grants full access or full write access to the entire API. - 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 that naturally lacks an expiry date; or a TLS certificate used for mTLS authentication that expires within months or years from its creation date. - Such credentials need to be managed, distributed and stored securely by the users who use them. This by itself increases the attack surface of the entire system and is one of the leading causes of countless serious breaches worldwide every year. This problem can be mitigated by delegating the management and sharing of credentials to secret managers and vaults. However, even if mitigated to an extent depending on the capabilities of the secret manager, the problem still persists and is merely delegated to another layer that suffers from the same fundamental issues. Octelium's solution is to simply eliminate distributing such credentials to *Users*, and instead manage them from within the *Cluster* via *Secrets* (read more [here](https://octelium.com/docs/octelium/latest/management/core/secret.md)), and transparently inject them on-the-fly for authorized *Users'* requests. Octelium supports secretless access for the following modes: - `HTTP`, `GRPC` and `WEB` modes where you can provide secretless access without having to share and manage API keys and tokens, OAuth2 client credentials, AWS sigv4 auth, etc... (Read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#secretless-access)). - `SSH` mode where you can provide secretless access without having to share and manage passwords, private keys or manage a PKI (Read more [here](https://octelium.com/docs/octelium/latest/management/core/service/ssh.md#secretless-access)). - `POSTGRES` mode where you can provide secretless access without having to share and manage passwords (Read more [here](https://octelium.com/docs/octelium/latest/management/core/service/postgres.md#secretless-access)). - `MYSQL` mode where you can provide secretless access without having to share and manage passwords (Read more [here](https://octelium.com/docs/octelium/latest/management/core/service/mysql.md#secretless-access)). - `KUBERNETES` mode where you can provide secretless to Kubernetes cluster APIs without having to share or manage Kubeconfigs, bearer access tokens, or TLS client certificate private keys (Read more [here](https://octelium.com/docs/octelium/latest/management/core/service/kubernetes.md#secretless-access)). - `RDP_WEB` mode where you can provide clientless secretless access to RDP servers via browsers without having to share and manage passwords (Read more [here](https://octelium.com/docs/octelium/latest/management/core/service/rdp.md#secretless-access)). - `SOCKS5` mode where you can provide secretless access to SOCKS5 servers without having to share and manage passwords (Read more [here](https://octelium.com/docs/octelium/latest/management/core/service/socks5.md#secretless-access)). ## Mutual TLS In addition to the L7 specific credentials (e.g. HTTP API keys or PostgreSQL passwords), many application protocols are protected by mTLS. Octelium also provides secretless 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: ```bash 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 for mTLS authentication to the upstream as follows: ```yaml kind: Service metadata: name: nats spec: mode: TCP config: upstream: url: tls://my-nats.default.svc:9090 tls: # !mark(1:2) clientCertificate: fromSecret: client-crt-nats ``` In many cases, you might also want to explicitly set one or more trusted root certificate authorities (CAs). You can add a list of root CAs as follows: ```yaml kind: Service metadata: name: nats spec: mode: TCP config: upstream: url: tls://my-nats.default.svc:9090 tls: # !mark(1:9) trustedCAs: - | -----BEGIN CERTIFICATE----- CA_1 -----END CERTIFICATE----- - | -----BEGIN CERTIFICATE----- CA_2 -----END CERTIFICATE----- clientCertificate: fromSecret: client-crt-nats ``` By default, the list of trusted CAs override the default list of public trusted CAs used by the *Service* underlying container filesystem. You can, however, override that default behavior and append your trusted CAs to the system's via the `appendToSystemPool` field as follows: ```yaml kind: Service metadata: name: nats spec: mode: TCP config: upstream: url: tls://my-nats.default.svc:9090 tls: trustedCAs: - | -----BEGIN CERTIFICATE----- CA_1 -----END CERTIFICATE----- - | -----BEGIN CERTIFICATE----- CA_2 -----END CERTIFICATE----- # !mark appendToSystemPool: true clientCertificate: fromSecret: client-crt-nats ``` You can also disable verifying the certificate provided by the upstream's server altogether via the `insecureSkipVerify` field as follows: ```yaml kind: Service metadata: name: nats spec: mode: TCP config: upstream: url: tls://my-nats.default.svc:9090 tls: # !mark insecureSkipVerify: true clientCertificate: fromSecret: client-crt-nats ```