I have created an iam role with troposphere but getting a circular dependency error when provisioning the resource with Cloudformation. My iam role has a trust policy to assume its own arn and I think the circular dependency error is due to the role is not created and doesn't know the arn to update the trust policy. Any ideas are welcome to resolve this issue
troposphere.iam.Role(
'newiamrole',
template=template,
Path='/',
AssumeRolePolicyDocument=awacs.aws.Policy(
Statement=[
awacs.aws.Statement(
Effect=awacs.aws.Allow,
Action=[awacs.sts.AssumeRole],
Principal=awacs.aws.Principal(
'Service', ['ec2.amazonaws.com'])
),
awacs.aws.Statement(
Effect=awacs.aws.Allow,
Action=[awacs.sts.AssumeRole],
Principal=awacs.aws.Principal(
'AWS', [troposphere.GetAtt('newiamrole', 'Arn')])
)
]
)
)
Related
I am running an Opensearch cluster 2.3, and from the log I can see the following error:
[2023-02-13T03:37:44,711][ERROR][o.o.a.a.AlertIndices ] [opensearch-node1] info deleteOldIndices
What trigger this error? I've never set up the alert, and in the past on the same cluster I used to have some ISM policies for the indices, but I removed them all, can this be linked to the error I am seeing?
Thanks.
I am trying to assign contributor rights on a resource group to an Azure Active Directory Group using Terraform. The Terraform script I use looks like this:
# Deploy Resource Groups
resource "azurerm_resource_group" "rg" {
name = "rg-companyname-syn-env-100"
location = "westeurope"
}
# Retrieve data for AAD CloudAdmin groups
data "azuread_group" "cloud_admin" {
display_name = "AAD-GRP-companyname-CloudAdministrators-env"
security_enabled = true
}
# Add "Contributor" role to Cloudadmin AAD group
resource "azurerm_role_assignment" "cloud_admin" {
scope = azurerm_resource_group.rg.id
role_definition_name = "Contributor"
principal_id = data.azuread_group.cloud_admin.id
depends_on = [azurerm_resource_group.rg]
}
If I run this I receive the following error:
╷
│ Error: authorization.RoleAssignmentsClient#Create: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client '<application_object_id>' with object id '<application_object_id>' does not have authorization to perform action 'Microsoft.Authorization/roleAssignments/write' over scope '/subscriptions/<subscription_id>/resourceGroups/rg-companyname-syn-env-100/providers/Microsoft.Authorization/roleAssignments/<role_assignment_id>' or the scope is invalid. If access was recently granted, please refresh your credentials."
│
│ with azurerm_role_assignment.cloud_admin["syn"],
│ on rg.tf line 15, in resource "azurerm_role_assignment" "cloud_admin":
│ 15: resource "azurerm_role_assignment" "cloud_admin" {
│
╵
Note the AAD Group (AAD-GRP-companyname-CloudAdministrators-env) already has the Owner role on the subscription used.
Is there somebody that knows a fix for this problem?
I had this issue occur today after someone else in the team had changed the service principal my deployment ran under to a contributor rather than owner of the subscription. Assign the role the role "owner" of the subscription to the service account your deployments run under
Whichever principal (either you, a service principal or managed identity assigned to a build agent) likely has the built in Azure role Contributor which can manage resources, but not Role Based Access Control (RBAC). So that is the reason you are getting a 403 Unauthorized response.
Contributor role is allowed to read, but not write role assignments. Since you are using Terraform, I would suggest creating a custom role definition which will allow write as well as delete so you can use terraform destroy
You can create a custom role definition by clicky-clicking in the portal, azure cli or Terraform (snippet below); executed by someone with the Owner role.
Once you have a custom role assignment with the appropriate permissions then assign the principal that is executing the terraform apply with that custom role.
data "azurerm_client_config" "current" {
}
resource "azurerm_role_definition" "role_assignment_write_delete" {
name = "RBAC Owner"
scope = data.azurerm_client_config.current.subscription_id
description = "Management of role assignments"
permissions {
actions = [
"Microsoft.Authorization/roleAssignments/write",
"Microsoft.Authorization/roleAssignments/delete",
]
not_actions = []
}
assignable_scopes = [
data.azurerm_client_config.current.subscription_id //or management group
]
}
I am new to aws and kubectl, I need to deploy one of the app to aws. After deploying to eks cluster, I edited the ingress in the kubectl but unfortunately it returned 404 not found. (i am pretty sure the new service container works fine)
after checking from kubectl describe ingress, here are some events reports:
Warning FailedBuildModel 40m ingress Failed build model due to WebIdentityErr: failed to retrieve credentials
caused by: InvalidIdentityToken: Couldn't retrieve verification key from your identity provider, please reference AssumeRoleWithWebIdentity documentation for requirements
status code: 400, request id: xxxxxxxx-4a93-4e27-9d6b-xxxxxxxx
Warning FailedBuildModel 22m ingress Failed build model due to WebIdentityErr: failed to retrieve credentials
caused by: InvalidIdentityToken: Couldn't retrieve verification key from your identity provider, please reference AssumeRoleWithWebIdentity documentation for requirements
status code: 400, request id: xxxxxxxx-5368-41e1-8a4d-xxxxxxxx
Warning FailedBuildModel 5m8s ingress Failed build model due to WebIdentityErr: failed to retrieve credentials
caused by: InvalidIdentityToken: Couldn't retrieve verification key from your identity provider, please reference AssumeRoleWithWebIdentity documentation for requirements
status code: 400, request id: xxxxxxxx-20ea-4bd0-b1cb-xxxxxxxx
Anyone has ideas about this issue?
I try to create SQL Server with ARM on Azure DevOps.
Pipeline successfully create SQL Server resource to Azure Portal, but I'm getting strange errors in Azure DevOps. Why this occurs and how to fix?
ERROR:
There were errors in your deployment. Error code: DeploymentFailed.
##[error]RoleAssignmentUpdateNotPermitted: Tenant ID, application ID, principal ID, and scope are not
allowed to be updated.
##[error]Check out the troubleshooting guide to see if your issue is addressed:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-resource-group-deployment?
view=azure-devops#troubleshooting
##[error]Task failed while creating or updating the template deployment.
YML:
task: AzureResourceManagerTemplateDeployment#3
inputs:
deploymentScope: 'Resource Group'
azureResourceManagerConnection: 'TestRG-Conn'
subscriptionId: '1111753a-501e-4e46-9aff-6120ed561111'
action: 'Create Or Update Resource Group'
resourceGroupName: 'TestRG'
location: 'North Europe'
templateLocation: 'Linked artifact'
csmFile: '$(System.DefaultWorkingDirectory)/CreateSQLServer/azuredeploy.json'
csmParametersFile:
'$(System.DefaultWorkingDirectory)/CreateSQLServer/azuredeploy.parameters.json'
deploymentMode: 'Incremental'
VARIABLE IN TEMPLATE:
"variables": {
"StorageBlobContributor": "[subscriptionResourceId('Microsoft.Authorization/roleDefinitions', '111111111111111111111-')]"
},
RESOURCE IN TEMPLATE:
"resources": [
{
"condition": "[parameters('enableADS')]",
"type":
"Microsoft.Storage/storageAccounts/providers/roleAssignments",
"apiVersion": "2018-09-01-preview",
"name": "[concat(variables('storageName'),
'/Microsoft.Authorization/', variables('uniqueRoleGuid') )]",
"dependsOn": [
"[resourceId('Microsoft.Sql/servers',
parameters('serverName'))]",
"[resourceId('Microsoft.Storage/storageAccounts',
variables('storageName'))]"
],
"properties": {
"roleDefinitionId": "[variables('StorageBlobContributor')]",
"principalId": "[reference(resourceId('Microsoft.Sql/servers',
parameters('serverName')), '2018-06-01-preview',
'Full').identity.principalId]",
"scope": "[resourceId('Microsoft.Storage/storageAccounts',
variables('storageName'))]",
"principalType": "ServicePrincipal"
}
}
Chances are you have deployed and deleted the resources, however, the role assignment is still there and that is what it is clashing with (what 4c7... is saying). So, go check the permissions on the storage account - if you use managed identities, that identity will be deleted but the role assignment will persists and show the user as 'unknown' which will also cause the above error when trying to deploy again - had the same issue but with a managed identity I was using for an aks cluster. Frustrating.
When you deleted a managed identity it does not delete associated roles created for it, I wish it cleaned up properly.
In my case, it was the name of the RoleAssignment. It was unique on the Resource Group level but not on the subscription level. Not sure what is the scope for the uniqueness of the name.
Bouncing off #Richard answer, I didn't have the permission to delete the "ghost" managed identities so I deployed the same role assignment under a different guid by adding an additional string to the guid() function. String functions for ARM templates docs
To do this, I changed my roleNameGuid's value from
"[guid(resourceGroup().id)]" to
"[guid(resourceGroup().id, parameters('guid_seed'))]", where parameters('guid_seed') is an arbitrary string that is passed from DevOps.
When the deployment strategy is changed from "Rolling update" to "Recreate", I am facing the below error
Failure executing: PATCH at: https://3x.xxx.2x1.xxx/apis/extensions/v1beta1/namespaces/default/deployments/xxxxxx. Message: Deployment.apps "xxxxxx" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy type is 'Recreate'. Received status: Status(apiVersion=v1, code=422, details=StatusDetails(causes=[StatusCause(field=spec.strategy.rollingUpdate, message=Forbidden: may not be specified when strategy type is 'Recreate', reason=FieldValueForbidden, additionalProperties={})], group=apps, kind=Deployment, name=xxxxxx, retryAfterSeconds=null, uid=null, additionalProperties={}), kind=Status, message=Deployment.apps "xxxxxx" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy type is 'Recreate', metadata=ListMeta(resourceVersion=null, selfLink=null, additionalProperties={}), reason=Invalid, status=Failure, additionalProperties={}).
Any help on this? I am using Spinnaker 1.6.0
There are many tickets on GitHub related to that problem: Kubernetes, Cert-manager, Spinnaker. And in each one you can find the same answer - it is not possible to switch the update strategy of already created resources.
So, the only way is to create a new deployment with a new strategy due to the implementation of the updating process in Kubernetes.