Following pipelines readme to set up a deployment pipeline, I ran
$ env CDK_NEW_BOOTSTRAP=1 npx cdk bootstrap \
--cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess \
aws://[ACCOUNT_ID]/us-west-2
to create the necessary roles. I would assume the roles would automatically add sts assume role permissions from my account principle. However, when I run cdk deploy I get the following warning
current credentials could not be used to assume
'arn:aws:iam::[ACCOUNT_ID]:role/cdk-hnb659fds-file-publishing-role-[ACCOUNT_ID]-us-west-2',
but are for the right account. Proceeding anyway.
I have root credentials in ~/.aws/credentials.
Looking at the deploy role policy, I don't see any sts permissions. What am I missing?
You will need to add permission to assume the role to the credentials from which you are trying to execute cdk deploy
{
"Sid": "assumerole",
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"iam:PassRole"
],
"Resource": [
"arn:aws-cn:iam::*:role/cdk-readOnlyRole",
"arn:aws-cn:iam::*:role/cdk-hnb659fds-deploy-role-*",
"arn:aws-cn:iam::*:role/cdk-hnb659fds-file-publishing-*"
]
}
First thing you need to do is enabling the verbose mode to see what is actually happenning.
cdk deploy --verbose
If you see similar message below. Continue with step 2. Otherwise, you need to address the problem by understanding the error message.
Could not assume role in target account using current credentials User: arn:aws:iam::XXX068599XXX:user/cdk-access is not authorized to perform: sts
:AssumeRole on resource: arn:aws:iam::XXX068599XXX:role/cdk-hnb659fds-deploy-role-XXX068599XXX-us-east-2 . Please make sure that this role exists i
n the account. If it doesn't exist, (re)-bootstrap the environment with the right '--trust', using the latest version of the CDK CLI.
Check S3 buckets related to CDK and CloudFormation stacks from AWS Console. Delete them manually.
Enable the new style bootstrapping by one of the method mentioned here
Bootstrap the stack using below command. Then it should create all required roles automatically.
cdk bootstrap --trust=ACCOUNT_ID --cloudformation-execution-policies=arn:aws:iam::aws:policy/AdministratorAccess --verbose
NOTE: If you are working with docker image assets, make sure you have setup your repository before you deploy. New style bootstrapping does not create the repos automatically for you as mentioned in this comment.
This may be of use to somebody... The issue could be a mismatch of regions. I spotted it in verbose mode - the roles were created for us-east-1 but I had specified eu-west-2 in the bootstrap. For some reason it had not worked. The solution was to set the region (by adding AWS_REGION=eu-west-2 before the cdk deploy command).
I ran into a similar error. The critical part of my error was
failed: Error: SSM parameter /cdk-bootstrap/<>/version not found.
I had to re-run using the new bootstrap method that creates the SSM parameter. To run the new bootstrap method first set CDK_NEW_BOOTSTRAP via export CDK_NEW_BOOTSTRAP=1
Don't forget to run cdk bootstrap with those credentials against your account [ACCOUNT_ID].
For me, the problem was that I was using expired credentials. I was trying to use temporary credentials from AWS SSO, which were expired. The problem was that the error message is misleading: it says
current credentials could not be used to assume 'arn:aws:iam::123456789012:role/cdk-xxx999xxx-deploy-role-123456789012-us-east-1', but are for the right account. Proceeding anyway.
(To get rid of this warning, please upgrade to bootstrap version >= 8)
However, applying the --verbose flag as suggested above showed the real problem:
Assuming role 'arn:aws:iam::123456789012:role/cdk-xxx999xxx-deploy-role-123456789012-us-east-1'.
Assuming role failed: The security token included in the request is expired
Could not assume role in target account using current credentials The security token included in the request is expired . Please make sure that this role exists in the account. If it doesn't exist, (re)-bootstrap the environment with the right '--trust', using the latest version of the CDK CLI.
Getting the latest SSO credentials fixed the problem.
After deploying with --verbose I could see it was a clock issue in my case:
Assuming role failed: Signature expired: 20220428T191847Z is now earlier than 20220428T192528Z (20220428T194028Z - 15 min.)
I resolve the clock issue on ubuntu using:
sudo ntpdate ntp.ubuntu.com
which then resolves the cdk issue.
I'm using Bitrise as a CI solution for my iOS app. I would like not to commit my API token to the repository, hence I've stored it as a Secret in the workflow in Bitrise with key = "API_TOKEN"
I need to pass that value to my app as an environment variable and use it as follows:
ProcessInfo.processInfo.environment["API_TOKEN"]
However, this is always nil.
My bitrise.yml contains the following:
....
app:
envs:
- API_TOKEN: "${API_TOKEN}"
...
How can I correctly set the Secret from Bitrise as an environment variable for my iOS app?
I'm running Jenkins 2.204.5
With plugins:
- job-dsl v1.77
- credentials 1.7
I'm trying to create a secret of type 'Secret Text' or 'StringCredentialsImpl' bound to a folder, using the JobDSL plugin code.
https://github.com/jenkinsci/plain-credentials-plugin/blob/master/src/main/java/org/jenkinsci/plugins/plaincredentials/impl/StringCredentialsImpl.java
But despite the fact that it is mentioned as supported in
https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-core/src/main/groovy/javaposse/jobdsl/dsl/helpers/parameter/CredentialsParameterContext.groovy#L23
I cant see it in my dynamic viewer JENKINS_URL/plugin/job-dsl/api-viewer/index.html
All I see is:
credentials {
basicSSHUserPrivateKey {}
certificateCredentialsImpl {}
fileSystemServiceAccountCredential {}
// OpenShift do use a dedicated authorization layer on top of Kubernetes and does not allow to access Kubernetes API using plain username/password credentials.
openShiftBearerTokenCredentialImpl {}
usernamePasswordCredentialsImpl {}
}
Apparently the plain-credentials-plugin is after all not compatible with the job-dsl-plugin.
Jenkins bug:
https://issues.jenkins-ci.org/browse/JENKINS-59971
I am running a Docker Vault container in dev mode, and I can't read a secret located at /secret/mobsters/ called password.
Here are Spring logs.
Running vault kv get secret/mobsters returns the password key value pair. I can also access the vault server locally.
Here is how I am referencing the secret:
#Value("${password}")
String password;
#PostConstruct
private void postConstruct() {
System.out.println("My password is: " + password);
}
The Spring Cloud Vault configuration is setup using a bootstrap.yml file:
spring.application.name: mobsters
spring.cloud.vault:
host: localhost
port: 8200
scheme: http
authentication: TOKEN
token: ...
I am getting an exception with the message (full exception here):
Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'password' in value "${password}"`
From Vault UI:
Using Spring Vault/Spring Cloud Vault with HashiCorp Vault 0.10.0 does not work as the key/value backend is mounted with versioning enabled by default. This has some significance as the versioned API has changed entirely and breaks existing client implementations. Context paths and response structure are different.
You have two options:
Use an older Vault version (such as 0.9.5)
Try to cope with API changes until Spring Cloud Vault finds an approach to use the new API. You need to:
Set spring.cloud.vault.generic.backend=secret/data in your bootstrap configuration.
Prefix property names with data. so #Value("${hello.world}") becomes #Value("${data.hello.world}").
It looks like there is a way to fix this.
In your bootstrap.yml, make sure that generic.enabled is false and kv.enabled is true.
spring:
...
cloud.vault:
...
kv.enabled: true
generic.enabled: false
According to this answer on GitHub:
The main difference between those two is that kv injects the data
segment in the context path and unwraps nested data responses.
If you're running a [springboot] version before 2.0, then you need to implement an
org.springframework.cloud.vault.config.VaultConfigurer bean that is
exposed to the bootstrap context. SecretBackendConfigurer accepts a
path and a PropertyTransformer that transforms properties before
exposing these as PropertySource.
I have installed a readthedocs local server but I am unable to build private github repositories from my organization through django-allauth.
I have admin privileges in all repositories, and I have configured django-allauth in the admin panel:
Adding the Client ID and Secret key to "admin/socialaccounts/socialapplications".
Adding an access Token into "admin/socialaccounts/socialtoken".
Adding the following configuration to the "admin/oauth/remoterepository"
Every time I try to build the repository I get the following error:
Failed to import project: Failed to get code from 'https://github.com/my-organization/my-project.git' (git clone): 128 git
clone error output: fatal: could not read Username for 'https://github.com': No such device or address
Does somebody know why is this happening? has somebody been able to configure a local readthedocs server in a similar scenario, using private repositories within an organization?
I have fixed the issue adding the flag:
ALLOW_PRIVATE_REPOS = True
Into my settings file my-project/readthedocs/settings/local_settings.py. This will activate x-oauth-basic urls for the Github repositories, allowing me to use my Github personal access token to clone the repository. I have just updated the Repository clone url field on admin/oauth/remoterepository using the following format:
https://<your token>:x-oauth-basic#github.com/my-organization/my-project.git