I have a general question for the rds feature within aws credentials manager. When I get the secret, it looks like this:
Does this mean that these credentials directly will work or is the password encrypted? Like if I wanted to sign into my database with a connection what credentials do I use and do these credentials auto rotate with the cycling feature?
I assume you mean the RDSDataClient to access a database such as a Serverless Amazon Aurora instance.
To successfully connect to the database using the RdsDataClient object, you must setup an AWS Secrets Manager secret that is used for authentication. For information, see Rotate Amazon RDS database credentials automatically with AWS Secrets Manager.
To see an AWS tutorial that shows this concept and the corresponding code, see this example that uses the AWS SDK for Kotlin. You will need these values to make a successful connection:
private val secretArnVal = "<Enter the secret manager ARN>"
private val resourceArnVal = "<Enter the database ARN>" ;
See the full example here:
Creating the Serverless Amazon Aurora item tracker application using the Kotlin RdsDataClient API
I just tested this again (been a while since it was developed), and it works perfectly.
We will port this example to use other supported programming languages too - like AWS SDK for Java.
UPDATE
You only need to use Secret Manager when using the RDSDataClient. As mentioned in that tutorial, the RdsDataClient object is only supported for an Aurora Serverless DB cluster or an Aurora PostgreSQL. If you are using MySQL RDS, you cannot use the the RdsDataClient object. You would use a supported JDBC API.
Related
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
According to the above document in order to use encryption configuration, we need to edit the kube-apiserver.yaml file. But in GCP, Azure or AWS we cannot view this the api-server as it is managed by the cloud provider. How can we use encryption configuration in this case? Has anyone managed to use encryption configuration to encrypt secrets in GCP,Azure and AWS?
Google Secret Manager(GSM)is GCP’s flagship service for storing, rotation and retrieving secrets. A secret in GSM could be stored in encrypted form. It supports IAM for authentication and fine grained access controls
Azure Key Vault FlexVolume and for aws Amazon Elastic Container Service for Kubernetes (EKS) are the other tools that can be used
Fluxcd ImageRepository authentication with AWS Elastic Container Registry Not working on ARM64 graviton node.
After debugging I found that the image used in the init container to get cred credentials is not supporting Arm64 instances.
image name:-bitnami/kubectl
doc link:-https://fluxcd.io/docs/guides/image-update/
There are some workarounds, provided on the fluxcd documentation portal:
AWS Elastic Container Registry
Using a JSON key
Using Static Credentials
AWS Elastic Container Registry
The solution proposed is to create a cronjob that runs every 6 hours which would re-create the docker-registry secret using a new token.
JSON key
A Json key doesn’t expire, so we don’t need a cronjob, we just need to create the secret and reference it in the ImagePolicy.
First, create a json key file by following this documentation. Grant the service account the role of Container Registry Service Agent so that it can access GCR and download the json file.
Static Credentials
Instead of creating the Secret directly into your Kubernetes cluster, encrypt it using Mozilla SOPS or Sealed Secrets, then commit and push the encypted file to git.
This Secret should be in the same Namespace as your flux ImageRepository object. Update the ImageRepository.spec.secretRef to point to it.
Does anyone know in which case choose Kubernetes secrets instead of google secret manager and the reverse ? Differences between the two ?
With Kubernetes secret (K8S Secret), you use a built in feature of K8S. You load your secrets in config maps, and you mount them on the pods that require them.
PRO
If a day you want to deploy on AWS, Azure or on prem, still on K8S, the behavior will be the same, no update to perform in your code.
CONS
The secrets are only accessible by K8S cluster, impossible to reuse them with another GCP services
Note: With GKE, no problem the ETCD component is automatically encrypted with a key form KMS service to keep the secret encrypted at rest. But, it's not always the same for every K8S installation, especially on premise, where the secrets are kept in plain text. Be aware about this part of the security.
Secret Manager is a vault managed by Google. You have API to read and write them and the IAM service checks the authorization.
PRO
It's a Google Cloud service and you can access it from any GCP services (Compute Engine, Cloud Run, App Engine, Cloud Functions, GKE,....) as long as you are authorized for
CONS
It's Google Cloud specific product, you are locked in.
You can use them together via this sync service: https://external-secrets.io/
We have a WAR file deployed on Tomcat and the database credentials are fetched through JNDI. This WAR now has to be moved to AWS cloud, and the requirement is db credentials has to be stored in AWS Secret Manager. My question is can I continue using JNDI/Tomcat along with Secret Manager ? I understand AWS SM has API and SDKs to access it, can that be integrated with JNDI/Tomcat somehow ? All posts I have seen mentions using the API/SDK directly from code, none i have found say anything about server integration. Is accessing AWS SM from code really the best way to do it ? Thanks.
A side note - for some reason unknown to me, we cannot use BeanStalk, it is just Tomcat on an EC2 instance.
Maybe you could use the JDBC driver wrapper: https://github.com/aws/aws-secretsmanager-jdbc. If you are using a connection pool manager you can follow the example in the README and replace the JDBC library with the wrapper library, specifying the secret in the configuration. The wrapper will then retrieve the secret and pass it to the real JDBC library.
If you are not using a connection pool manager, you could still replace the existing JDBC driver with the wrapper, but this would take some code modifications.
By using the wrapper, you can also turn on auto-rotation on the DB password since the wrapper knows to re-fetch the secret after it changes.
I was successfully able to connect to RDS like any other database connection.
I use spring jpa data ( repository ) to do CRUD operation on postgres db.
currently I provide the db url and the credential in the properties file
spring:
datasource:
url: jdbc:postgresql://<rds-endpoint>:5432/<dbschema>
username: <dbuser>
password: <dbpassword>
However this is not an option while connecting to production or preproduction.
what is the best practise here.
Does AWS provide any inbuild mechanism to read these details from an endpoint like in the case of accessing S3 ?
My intention is not expose the password.
Several options are available to you:
Use the recently announced IAM access to Postgres RDS
Use Systems Manager Parameter Store to store the password
Use Secrets Manager to store the password and automatically rotate credentials
For 2 and 3, look up the password on application start in Spring using a PropertyPlaceholderConfiguration and the AWSSimpleSystemsManagement client (GetParameter request). SystemsManager can proxy requests to SecretsManager to keep a single interface in your code to access parameters.
IAM credentials is more secure in that:
If using EC2 instance profiles, access to the database uses short lived temporary credentials.
If not on EC2 you can generate short lived authentication tokens.
The password is not stored in your configuration.
If you have a separate database team they can manage access independent of the application user.
Removing access can be done via IAM
another generic option I found was to use AWS Secret Manager
(doc link)
RDS specific solution is to connect to DB Instance Using the AWS SDK using IAMDBAuth