We are using vault to get rid of all secrets from our codebase and config servers. Vault aws auth with its secure introduction seems like the perfect fit for this. However our dev environment is not on aws and vault cannot work with config server to fetch different configurations per environment.
Do you guys see a way out where I could still use the aws auth for staging and prod and a different auth for dev?
Thanks,
Chris.
Authentication methods can be configured via bootstrap.properties so ideally have multiple profiles, one of them to use AWS authentication and the other one for dev.
Related
1/ Everyday at 3am, we are runnning a script alfa.sh on server A in order to send some backups to AWS (s3 bucket).
As a requirement we had to configure AWS (aws configure) on the server which means the Secret Key and Access Key are stored on this server. We now would like to use short TTL credential valid only from 3am to 3:15am . Vault Hashicorp does that very well
2/ On server B we have a Vault Hashicorp installed and we managed to generate short ttl dynamic secrets for our s3 bucket (access key / secret key).
3/We now would like to pass the the daily generated dynamic secrets to our alpha.sh. Any idea how to achieve this?
4/Since we are generating a new Secret Key and Access Key, I understand that a new AWS configuration "aws configure" will have to be performed on server A in order to be able to perform the backup. Any experience with this?
DISCLAIMER: I have no experience with aws configure so someone else may have to answer this part of the question. But I believe it's not super relevant to the problem here, so I'll give my partial answer.
First things first - solve your "secret zero" problem. If you are using the AWS secrets engine, it seems unlikely that your server is running on AWS, as you could skip the middle man and just give your server an IAM policy that allowed direct access to the S3 resource. So find the best Vault auth method for your use case. If your server is in a cloud like AWS, Azure, GCP, etc or container like K8S, CF provider, or has a JWT token delivered along with a JWKS endpoint Vault can trust, target one of those, and if all else fails, use AppRole authentication delivering a wrapped token via a trusted CI solution.
Then, log into Vault in your shell script using those credentials. The login will look different depending on the auth method chosen. You can also leverage Vault Agent to automatically handle the login for you, and cache secrets locally.
#!/usr/bin/env bash
## Dynamic Login
vault login -method="${DYNAMIC_AUTH_METHOD}" role=my-role
## OR AppRole Login
resp=$(vault write -format=json auth/approle/login role-id="${ROLE_ID}" secret-id="${SECRET_ID}")
VAULT_TOKEN=$(echo "${resp}" | jq -r .auth.client_token)
export VAULT_TOKEN
Then, pull down the AWS dynamic secret. Each time you read a creds endpoint you will get a new credential pair, so it is important not to make multiple API calls here, and instead cache the entire API response, then parse the response for each necessary field.
#!/usr/bin/env bash
resp=$(vault read -format=json aws/creds/my-role)
AWS_ACCESS_KEY_ID=$(echo "${resp}" | jq -r .data.access_key)
export AWS_ACCESS_KEY_ID
AWS_SECRET_KEY_ID=$(echo "${resp}" | jq -r .data.secret_key)
export AWS_SECRET_KEY_ID
This is a very general answer establishing a pattern. Your environment particulars will determine manner of execution. You can improve this pattern by leveraging features like CIDR binds, number of uses of auth credentials, token wrapping, and delivery via CI solution.
We use thycotic to manage the secrets.
I want to access thycotic secrets in the gitlab ci yaml file.
While referring the docs, gitlab supports the Hashicorp vault to store the secrets and access them in gitlab CI job.
Same way: I need it for Thycotic
Is it possible?
This is currently not supported, but actively requested in gitlab-org/gitlab issues 291072
Only alternative, not yet released:
We will soon release an upgraded CI_JOB_JWT token that should support various hyperclouds, including their secrets managers.
If one can use a JWT token to authenticate with Tycothic, I'd recommend to go in this direction.
Could you check for me of OpenID Connect is an option for Tycothic?
But:
Thycotic does have OIDC support (among others) for their dsv product, but not the on-premises one
So this is the case:
What we have:
We have a Service (webApp) in kubernetes API + Vue.js frontend hosted in AWS.
And we also have some Services (webApp) in Kubernetes API + React.js frontend hosted in GCP.
We are able to use same domain subdomains for each (like: a.domain.com and b.domain.com).
What we need:
We need to let the user think this 2 servers are only one.
The idea is that the user uses the same Username/password for both servers, but
the most immportant part is that he only needs to log in to one of this to be logged in the other automaticaly.
We have the parent domain in Google, and we prefer a solution that is implemented in GCP and the AWS server should just consume this auth method/config/etc.
Love to hear some ideas
If you have multiple replicas of the webApp frontend distributed in multi-cloud environments, you can use dynamic DNS and load balancing services like Cloudflare provides to distribute the access to your app frontend as explained here.
Then you need connect the multi-cloud VPCs and make accessible your backend to your multiple frontends.
You can use managed VPN services from both cloud providers to have an encrypted channel between VPCs in both cloud environments and to transfer data by using private IP addresses.
Google offers Cloud VPN as a managed VPN service for encrypted IPsec tunnels, which can be used on the Google end. AWS offers AWS Site-to-Site VPN and Azure offers Azure VPN gateway. You can connect your VPCs between the environments by using one or multiple VPN tunnels.
With that you can operate your webApp on multi cloud.
I would like to add authentication to Spring Cloud Data Flow Server application. I see articles regarding Cloud Foundry UAA with LDAP support. I tried the basic authentication snippet as well which is not working.
I see lot of references to the link https://github.com/spring-cloud/spring-cloud-dataflow-samples/tree/master/security-ldap-uaa-example In that, the ldap server code is using Apache DSContainer which is deprecated and not working in my local. Is there any other approach? It's greatly appreciated if someone can provide a sample code for the same.
That's an old sample and apache DS is there for just having easy way to get a demo running without a read ldap server. With UAA ldap is fully behind it to store users.
UAA is not a most easiest system to setup but what comes for a config that would work as a starting point to configure it with any ldap server.
I have created a Github OAuth app and I am trying to add the app as an OIDC application to AWS Cognito.
However, I cannot find a proper overview about the endpoints and data to fill in anywhere in the Github Docs.
The following fields are required:
Issuer -> ?
Authorization endpoint => https://github.com/login/oauth/authorize (?)
Token endpoint => https://github.com/login/oauth/access_token (?)
Userinfo endpoint => https://api.github.com/user (?)
Jwks uri => ?
I couldn't find the Jwks uri anywhere. Any help would be highly appreciated.
Seems like there is no way to get this working out of the box.
https://github.com/TimothyJones/github-cognito-openid-wrapper seems to be a way to get this working.
If any Cognito dev sees this, please add Github/Gitlab/Bitbucket support.
GitLab 14.7 (January 2022) might help:
OpenID Connect support for GitLab CI/CD
Connecting GitLab CI/CD to cloud providers using environment variables works fine for many use cases.
However, it doesn’t scale well if you need advanced permissions management or would prefer a signed, short-lived, contextualized connection to your cloud provider.
GitLab 12.10 shipped initial support for JWT token-based connection (CI_JOB_JWT) to enable HashiCorp Vault users to safely retrieve secrets. That implementation was restricted to Vault, while the logic we built JWT upon opened up the possibility to connect to other providers as well.
In GitLab 14.7, we are introducing a CI_JOB_JWT_V2 environment variable that can be used to connect to AWS, GCP, Vault, and likely many other cloud services.
Please note that this is an alpha feature and not ready for production use. Your feedback is welcomed in this epic.
For AWS specifically, with the new CI_JOB_JWT_V2 variable, you can connect to AWS to retrieve secrets, or to deploy within your account. You can also manage access rights to your cluster using AWS IAM roles.
You can read more on setting up OIDC connection with AWS.
The new variable is automatically injected into your pipeline but is not backward compatible with the current CI_JOB_JWT.
Until GitLab 15.0, the CI_JOB_JWT will continue to work normally but this will change in a future release. We will notify you about the change in time.
The secrets stanza today uses the CI_JOB_JWT_V1 variable. If you use the secrets stanza, you don’t have to make any changes yet.
See Documentation and Issue.