How to secure conjur "api key" in ansible awx - ansible

We have requirement to secure credential with cyberArk and use it in ansible awx credential. Note:not within ansible playbook.
In ansible(AWX) credential, How to secure/automate conjur "api key" without manual type

Currently, when using the CyberArk Conjur Secret Lookup in Ansible Automation Platform (formerly Tower) or AWX, there is no way to provide the API key to the platform Just-in-Time. It is required to be stored and encrypted within the API Key value of the Secret Lookup credential type, as is depicted in your screenshot.
There is research being done on how this can utilize Conjur's JWT authenticator instead of using a stored API key, however there are no details on the development at this time.
At the very minimum, the Secret Lookup approach currently implemented would allow you to introduce secret rotation to all secrets previously stored in Ansible which is a security improvement over the static nature of those secrets when they were stored there.

Related

Store OCI Terraform Provider Variables as Secrets in Azure Key Vault and Execute via Azure DevOps Pipeline

I'm using Azure Key Vault, Git and DevOps Pipelines and my intention is to execute Terraform code against Oracle Cloud Infrastructure (OCI). I've configured the necessary resource group, storage account, container, uploaded the OCI provider variables into Key Vault.
I've tried storing the API signing key as a secret, and as a key, but Terraform throws provider-related errors regarding the private key. I'm looking for the proper way to get the content of the private key from Azure Key Vault and pass it to the OCI provider. Or just the proper way to leverage Key Vault with the OCI provider.
This is the error I'm getting during Terraform Plan:
Error: Incorrect attribute value type. Inappropriate value for attribute "private_key": string required.
My code looks as follows:
provider "oci" {
### Tenancy Connectivity variables
tenancy_ocid = "${data.azurerm_key_vault_secret.tenancy-ocid.value}"
user_ocid = "${data.azurerm_key_vault_secret.dev-user-ocid.value}"
fingerprint = "${data.azurerm_key_vault_secret.key-fprint.value}"
private_key = "${data.azurerm_key_vault_key.oci-private-key}"
private_key_password = ""
region = var.home_region
}
The Terraform Plan operation only seems to complain about the private key, while the other secrets are read successuflly. Any help would be appreciated!
For the first three pairs, you retrieve the value, which is translated to a string. The provider is not complaining, as these are accepted values.
However, it looks like for the private key, you are not passing the key contents (value attribute might be missing). I am no expert in how to retrieve the contents of the private key from Azure, but you have to pass the "value" of the key...

What are permissions that my lambda function need to retrieve secrets from AWS Secrets Manager

What are permissions that my lambda function need to be able to retrieve secrets from AWS Secrets Manager and change it also ?
You need the secretsmanager:GetSecretValue policy to retrieve secrets and the secretsmanager:UpdateSecret policy to update secrets.
Note that if you are using a customer-managed AWS KMS key for encryption you will also need some KMS permissions:
kms:Decrypt for retrieving the secret.
kms:Decrypt and kms:GenerateDataKey for updating the secret.
https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html
https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/update-secret.html
If you are using the Lambda functions provided by AWS, then (as described in the docs) you will need: DescribeSecret, GetSecretValue, PutSecretValue, UpdateSecretVersionStage and GetRandomPassword. If you are using a Custom KMS Key (CMK) you will also need Decrypt and GenerateDataKey permissions for that CMK (both in the Lambda policy and in the KMS key policy).
If you are seeing Task timed out errors, it is likely your Lambda can not access either the secrets manager endpoint (try using a VPC endpoint), or the Lambda can not connect to the DB (check security group settings).

How to refer AWS access key(secret key) in cloud-init without hard coding

I want to write cloud-init script which initializes REX-Ray docker plugin(A service which uses AWS credentials on its configuration).
I have considered the following methods. However, these methods have some disadvantages.
Hard code access key/secret key in cloud-init script.
Problem: This is not secure.
Create IAM role, then refer access key, secret key from instance meta data.
Problem: Access key will expires in a certain period.
So I need to restart REX-Ray daemon process, which causes service temporary unavailable.
Please tell me which is better way to refer access key/secret key, or another way if it exists.
Thanks in advance.
The docker plugin should get the credentials automatically. You don't have to do anything. Do not set any environment variables for AWS credentials.
AWS CLI / AWS SDK will get the credentials automatically from the meta data server.
You can use the following method of authentication
Environment variables
Export both access and secret keys in environment environment as follow:
$ export AWS_ACCESS_KEY_ID="anaccesskey"
$ export AWS_SECRET_ACCESS_KEY="asecretkey"
Shared Credential file
You can use an AWS credentials file to specify your credentials. The default location is $HOME/.aws/credentials on Linux and OS X, or "%USERPROFILE%.aws\credentials" for Windows users. If terraform fail to detect credentials inline, or in the environment, Terraform will check this location
You can optionally specify a different location in the configuration by providing the shared_credentials_file attribute as follow
provider "aws" {
region = "us-west-2"
shared_credentials_file = "/Users/tf_user/.aws/creds"
profile = "customprofile"
}
https://www.terraform.io/docs/providers/aws/

What's the difference between Amazon EC2 private key (.pem) and secret access key?

While signing up for Amazon EC2 and enabling ssh, I have to create and download a private key (.pem) and a secret access key.
How are they different? What different functions do they have?
You need to read a good tutorial on SSH, but here is a summary:
The Access Key ID and Secret Access Key are like a username and password. They allow you to "do stuff" on the AWS API using the commandline tools or code you write.
The private key (.pem) is like a password for talking (SSH) to an individual box that you have launched. (i.e. not "AWS itself", but "your box within AWS".) You can have different passwords to different boxes if you want, but most of the time you only need one.
If you know how SSH works, they are just putting down ~/.ssh/known_hosts with the public part of your key, allowing you to log in for the first time. You can change that file later to add more users or rotate your SSH keys.

How to grant EC2 access to SQS

The docs are very confusing to me. I have read through the SQS access docs. But what really throws me is this page: http://docs.aws.amazon.com/aws-sdk-php/v2/guide/service-sqs.html
You can provide your credential profile like in the preceding example,
specify your access keys directly (via key and secret), or you can
choose to omit any credential information if you are using AWS
Identity and Access Management (IAM) roles for EC2 instances or
credentials sourced from the AWS_ACCESS_KEY_ID and
AWS_SECRET_ACCESS_KEY environment variables.
1) Regarding what I have bolded, how is that possible? I cannot find steps whereas you are able to grant EC2 instances access to SQS using IAM roles. This is very confusing.
2) Where would the aforementioned environment variables be placed? And where would you get the key and secret from?
Can someone help clarify?
There are several ways that applications can discover AWS credentials. Any software using the AWS SDK automatically looks in these locations. This includes the AWS Command-Line Interface (CLI), which is a python app that uses the AWS SDK.
Your bold words refer to #3, below:
1. Environment Variables
The SDK will look for the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables. This is a great way to provide credentials because there is no danger of accidentally including a credentials file in github or other repositories. In Windows, use the System control panel to set the variables. In Mac/Linux, just EXPORT the variables from the shell.
The credentials are provided when IAM users are created. It would be your responsibility to put those credentials into the environment variables.
2. Local Credentials File
The SDK will look in local configuration files, such as:
~/.aws/credentials
C:\users\awsuser\.aws\credentials
These files are great for storing user-specific credentials and can actually store multiple profiles, each with their own credentials. This is useful for switching between different environments such as Dev and Test.
The credentials are provided when IAM users are created. It would be your responsibility to put those credentials into the configuration file.
3. IAM Roles on an Amazon EC2 instance
An IAM role can be associated with an Amazon EC2 instance at launch time. Temporary credentials will then automatically be provided via the instance metadata service via the URL:
http://instance-data/latest/meta-data/iam/security-credentials/<role-name>/
This will return meta-data that contains AWS credentials, for example:
{
"Code" : "Success",
"LastUpdated" : "2015-08-27T05:09:23Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIAI5OXLTT3D5NCV5MS",
"SecretAccessKey" : "sGoHyFaVLIsjm4WszUXJfyS1TVN6bAIWIrcFrRlt",
"Token" : "AQoDYXdzED4a4AP79/SbIPdV5N8k....lZwERog07b6rgU=",
"Expiration" : "2015-08-27T11:11:50Z"
}
These credentials have inherit the permissions of the IAM role that was assigned when the instance was launched. They automatically rotate every 6 hours (note the Expiration in this example, approximately 6 hours after the LastUpdated time.
Applications that use the AWS SDK will automatically look at this URL to retrieve security credentials. Of course, they will only be available when running on an Amazon EC2 instance.
Credentials Provider Chain
Each particular AWS SDK (eg Java, .Net, PHP) may look for credentials in different locations. For further details, refer to the appropriate documentation, eg:
Providing AWS Credentials in the AWS SDK for Java
Providing AWS Credentials in the AWS SDK for .Net
Providing AWS Credentials in the AWS SDK for PHP

Resources