I am implementing vault for storing and accessing the secrets for my docker containers on other VM by installing vault in that docker container as well.
Is there any way that I could access secrets from my docker containers in another machine without installing hashicorp-vault on those containers.
In order to access secrets from Vault you will need to authenticate, retrieve vault token and access the relevant secrets.
There are multiple authentication methods (user/pass, LDAP, JWT...). Read about it here and decide which method fits your needs
Vault exposes rest api, which means that you don't need to install anything in order to access it. Just send the relevant http request.
For example - here is the kv http api (and an example - to list secrets)
$ curl \
--header "X-Vault-Token: ..." \
--request LIST \
https://127.0.0.1:8200/v1/secret/metadata/my-secret
You can add multiple listeners in the vault configs.
listener "tcp" {
address = "127.0.0.1:8200"
}
listener "tcp" {
address = "<your_server_ip>:8200"
tls_cert_file = path/to/certfile
tls_key_file = path/to/keyfile
}
References
https://www.vaultproject.io/docs/configuration/listener/tcp.html
Related
In Vault documentation, specifically the policies page, there is this phrase:
Everything in Vault is path based, and policies are no exception
I wonder about this phrase, does it mean that in the architecture of Vault and in its internals everything really is a path, similar to the "Everything is a file" in Linux architecture, which applies on processes, files, directories, sockets, pipes, etc?
What makes me relate to this phrase is that secret engines are defined by paths, and I assume Vault infers their types and which to be used from the given paths. Also policies are relatable as you have to define exact paths for each policy, but what about other components like auth methods, audits, tokens, etc?
I just want to get what is meant by "path based" in "Everything in Vault is path based" phrase.
In Vault, everything is path based. This means that every operation that is performed in Vault is done through a path. The path is used to determine the location of the operation, as well as the permissions that are required to execute the operation.
Whether you're using the vault binary or whether you're hitting the HTTP API endpoints, secrets/configs are written to a path.
i.e. via cli:
VAULT_ADDR=https://myvault.example.com VAULT_TOKEN=xxxxxxxx-xxxxxxx-xxxxxx vault kv get mysecrets/passwords/root
would correspond to HTTP endpoint:
curl \
-H "X-Vault-Token: xxxxxxx-xxxxxx-xxxxxxx" \
-X GET \
https://myvault.example.com/v1/mysecrets/passwords/root
Here's another example:
enabling the gcp secret engine with a custom path:
vault secrets enable -path=”my-project-123” gcp
If you wanted to enable secrets engines from the HTTP API, the endpoint (path) is /sys/mounts. Details here.
creating writing a config:
vault write my-project-123/config credentials=#/path/to/creds.json ttl=3600 max_ttl=21600
Notice how the config is written to a path, and if you were to use the HTTP API endpoint to do this, then it would look something like this:
curl \
--header "X-Vault-Token: ..." \
--request POST \
--data #payload.json \
https://myvault.example.com/v1/my-project-123/config
Where the payload.json would contain your credentials in text, ttl, max_ttl
Hence why they Vault says everything is path based.
EDIT: TL;DR - path based is so that there's parity between HTTP API and CLI (or any SDKs too). Compare this to a gcloud or aws command to its HTTP API endpoint counterpart where there isn't much parity there.
From a Kubernetes node, how can I access API server, how can I find out the API endpoint and handle authentication? It is a Windows node by the way.
I'm surprised that there is not much information I could find on the Internet about this, is accessing Kubernetes API from node directly a bad design?
"From the node" sound like a fringe use case, like addons, which are usually covered by using the "admin.conf" file that was deployed during node attachement and contains whatever you would need to connect to the api server.
A more usual approach would be to deploy your workload in a Pod which service account would have the proper role binding to access the API server.
How to access Kubernetes API from node directly?
There are multiple ways , one of the way is from master node
# Get API Server URL:
kubectl cluster-info
#access it using the curl
curl https://<api serverIP>:6443/api/v1/nodes --cacert /etc/srv/kubernetes/pki/ca-certificates.crt --cert /var/lib/kubelet/pki/kubelet-client.crt --key /var/lib/kubelet/pki/kubelet-client.key
how can I find out the API endpoint and handle authentication?
One technique i use is using --v=11 with kubectl commands , it will give endpoints of the kubernetes resources
#example :
kubectl get pods --v=11 2>&1 | grep GET
I1229 10:20:41.098241 42907 round_trippers.go:423] curl -k -v -XGET -H "Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json" -H "User-Agent: kubectl/v1.19.4 (linux/amd64) kubernetes/d360454" 'https://10.157.160.165:6443/api/v1/namespaces/default/pods?limit=500'
I1229 10:20:41.116964 42907 round_trippers.go:443] GET https://<apiserver>:6443/api/v1/namespaces/default/pods?limit=500 200 OK in 18 milliseconds
It is a Windows node by the way
Ideally above steps should work , May be you need to find out equivalent commands for grep & curl. change location of the certs to appropriate locations. you can find the location of certs from admin.conf file.
I have generated the access token and placed in below mentioned mount path and this token need to be included in the Authorization header when making a request against the retrieve secret endpoint.
How can we achieve it in yaml scripting
volumeMounts:
- mountPath: /run/test
name: conjur-access-token
readOnly: true
This question is referencing CyberArk's Conjur Secrets Manager's Kubernetes authenticator. It uses a sidecar authenticator client to keep an authenticated session token for Conjur's API refreshed in a shared volume mount with an application container running within a Kubernetes pod. This allows the application container to request secret values Just-in-Time (JiT) from the Conjur API with a single API call.
There is a file located at /run/test/conjur-access-token (according to the manifest snippet you provided) that contains the authenticated session token to use to connect to the Conjur API. Your application container needs to read /run/test/conjur-access-token and use it in the Authorization header as a Token-based authorization. To use curl, this would look like:
curl -H "Authorization: Token token='$(cat /run/test/conjur-access-token)'" https://conjur.example.com/secrets/myorg/variable/prod%2Fdb%2Fpassword
Where:
/run/test/conjur-access-token is the path to the shared volume mount of the application container and sidecar Kubernetes authenticator client.
conjur.example.com is the Base URL for your Conjur Follower in the Kubernetes cluster (or outside, if that's the deployment method).
myorg is the organzation account configured at the time of Conjur deployment and configuration.
prod%2Fdb%2Fpassword is the URLified secret variable path in Conjur. This would be referenced otherwise as prod/db/password but since forward-slashes are part of URL/URI, we need this URLified to %2F.
If the file containing your token in the mount path is called token, then you can simply do (assuming that you use curl):
curl -H "Authorization: Bearer $(cat /run/test/token)" ...
Is it possible to configure a custom password for the Kubernetes dashboard when using eks without customizing "kube-apiserver"?
This URL mentions changes in "kube-apiserver"
https://techexpert.tips/kubernetes/kubernetes-dashboard-user-authentication/
In K8s, requests come as Authentication and Authorization (so the API server can determine if this user can perform the requested action). K8s dont have users, in the simple meaning of that word (Kubernetes users are just strings associated with a request through credentials). The credential strategy is a choice you make while you install the cluster (you can choose from x509, password files, Bearer tokens, etc.).
Without API K8s server automatically falls back to an anonymous user and there is no way to check if provided credentials are valid.
You can do something like : not tested
Create a new credential using OpenSSL
export NEW_CREDENTIAL=USER:$(echo PASSWORD | openssl passwd -apr1
-noverify -stdin)
Append the previously created credentials to
/opt/bitnami/kubernetes/auth.
echo $NEW_CREDENTIAL | sudo tee -a /opt/kubernetes/auth
Replace the cluster basic-auth secret.
kubectl delete secret basic-auth -n kube-system
kubectl create secret generic basic-auth --from-file=/opt/kubernetes/auth -n kube-system
Small question regarding Hashicorp Vault please.
I have a secret in Vault, under cubbyhole/mytestkey
If I log in to the web UI, I can see the key mytestkey and its value under cubbyhole
If I use the Vault CLI, running vault read /cubbyhole/mytestkey, I do get the result.
vault read /cubbyhole/mytestkey
Key Value
--- -----
mytestkey mytestvalue
However, when I use via curl (The token should be correct, since I used it to connect to Vault web UI), I get:
curl -vik -H "X-Vault-Token: token" https://remote-vault/cubbyhole/mytestkey
HTTP 404
May I ask what is the issue with my curl command? A path issue? And the correct one would be?
Thank you
Your REST API endpoint is missing the port and the version of the API. You can update it to:
curl -vik -H "X-Vault-Token: token" https://remote-vault:8200/v1/cubbyhole/mytestkey
and modify the port if running on the non-default 8200.
You can find more information in the relevant documentation.