Introduction

Everyone, how do you manage secrets in your home cluster?
Since individual use doesn't warrant spending too much money, I was hesitant about using GCP or AWS Secret Manager. Then, I came across an interesting service in the External Secret Operator Provider and decided to give it a try.
The Akeyless service we'll discuss today has a large free tier, making it more accessible for individual development compared to something like HashiCorp Vault.
5 Clients
2,000 Static Secrets

External Secret Operator

The External Secret Operator is a handy tool that creates secrets from an external secret manager. This means you don't need to leave credential information in your manifests and can manage everything centrally. You can configure the secret manager information to be used on a cluster-wide or namespace basis, allowing for flexible separation, whether for multi-tenant or single-tenant use.

Akeyless

Akeyless is a secret manager SaaS provided by an Israeli company. It has a patented technology called DFC for managing private keys, offering high security by managing key fragments across different clouds and regions. It not only has basic features like key rotation but also robust integration with Kubernetes.

Setup

Image: Akeyless + External Secret Operator
https://docs.akeyless.io/docs/external-secret-operator

The Akeyless documentation includes instructions for installing the External Secret Operator, so you can follow it step by step. I used API keys for integration, issuing an API key from Users & Auth Methods in the dashboard and configuring it as follows:

accessId: "p-XXXX" # AccessID
accessType: api_key
accessTypeParam: "<api_key>"

Next, I attached a role to the issued authentication information in Akeyless to allow access to the secret information and performed role addition and linking.
As a side note, Akeyless has a Personal directory for storing personal credential information, so be careful to put information in the right place depending on the use case. In this case, since I wanted to access it regardless of the user, I created and managed a directory directly under Items.

Issues Encountered

While handling credential information, I restricted the IP for the API key, which led to access issues. Upon checking the audit logs, I noticed access from unfamiliar IP addresses, suggesting that requests might be proxied somewhere and the client's IP was not being conveyed correctly. To solve this, I accessed Akeyless via the Akeyless Gateway from the External Secret Operator.

Installing Akeyless Gateway

This is also installed using Helm. You can check the steps in the documentation or the Gateway section in the dashboard and proceed accordingly.

https://docs.akeyless.io/docs/gateway-k8s
Although the values.yaml file usually includes authentication information for building, this time I output it with helm template and rewrote the Secret to build it without including authentication information, as shown below:

apiVersion: v1
kind: Secret
metadata:
 name: akeyless-gw-conf-secret
type: Opaque
data:
 admin-access-id: ""
 admin-access-key: ""
 - -
…

Finally, by setting the URL of the SecretStore to the Gateway, you can connect. Keep the authentication information such as accessID and accessType as they are.

apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
 name: akeyless-cluster-secret-store
spec:
 provider:
 akeyless:
 # URL of your akeyless API
 akeylessGWApiURL: "http://akeyless-gw-akeyless-api-gateway.akeyless-gateway.svc.cluster.local:8080/v2"
 authSecretRef:
…

Conclusion

This time, I introduced a method to manage secret information externally while applying IP restrictions using the Akeyless Gateway. Originally, this Gateway seems to be intended for operation without keys, so I will look for a way to avoid using the API key, which is still left as a Secret.