I was running the cmdlet Get-AzStorageAccount on a storage account to test whether public access is enabled.
Azure portal
Azure PowerShell
Similar results via CLI
az storage account show -g MyResourceGroup -n MyStorageAccount
Question
For a while I was under the impression that the cmdlet works only on StorageV2 accounts. But, I can confirm that this is not the case. The cmdlet is inconsistent with both StorageV2 and General purpose V1 accounts.
I am unable to understand the reason for the inconsistent behaviour of the cmdlet Get-AzStorageAccount w.r.t property AllowPublicBlobAccess ?
thank you,
Sau
As the document shows in the Note:
The AllowBlobPublicAccess property is not set by default and does not
return a value until you explicitly set it. The storage account
permits public access when the property value is null or when it is
true.
You need to disable it and save, then enable it. The property will be true that you want.
Related
To connect to DB I have to make an API call to generate a token. Lets say I store this in environment variable $TOKEN.
Now while setting up my data source in DataGrip, how can I tell DataGrip to read $TOKEN environment variable as its value will keep on changing? Because before opening DataGrip I will make the API call to generate the token and set in a environment variable via script.
Is it possible to read environment variable as a password in DataGrip?
There is no such feature out of the box.
You can create your custom plugin to provide this kind of authorisation. That is the matter of implementing of on class - com.intellij.database.dataSource.DatabaseAuthProvider
See this plugin as an example.
Currently deploying PostgREST in AWS. When I use Fargate and just hardcoded type in the environment variables for the connection string, the machine works like a charm.
However I recently replaced these values with secrets. In the secret I copy-pasted the entire string in the value and in the environment variable I set the source from "Value" to "ValueFrom".
So the value now is:
postgres://<myuser>:<mypass>#<amazon-rds-instance>:5432/<db>
When I use this connectionstring directly in the environment variable I can easily connect, so I know the information is correct.
The logs come back with the following error:
{"details":"missing \"=\" after \"{\"postgrest_db_connection\":\"postgres://myuser:mypass#amazon-rds-instance:5432/db\"}\" in connection info string\n","code":"","message":"Database connection error"}
I also checked I have no characters in the string that need to be escaped. What can I be missing here?
So I figured it out. Unfortunately this line was it:
It is only supported to inject the full contents of a secret as an environment variable. Specifying a specific JSON key or version is not supported at this time.
This means that whenever you use the secrets as ValueFrom setting in the environment variables (when working with Fargate), the entire secret's value gets copy-pasted.
I tested this using a secret for the PostgREST schema variable. I got back the value:
{'PGRST_SCHEMA_URL': 'public'}
Whilst I was expecting it to be just:
public
This is why the configuration went bad as well. Thanks everyone for searching.
The documentation on protected variables is pretty obscure. When I make a variable as protected I have to idea how to access it. No matter what I do it is always empty. I have tried base64 encoding it and then base64 encoding it again in the pipeline so I can see what it is and I get an empty string: Cg==. Can someone please explain how to use protected variables?
As #secustor wrote, it is not possible to access protected variables from a branch or tag that is not protected. The variable would be empty if accessed.
From here, two options:
Push to a protected branch or tag (set the branch/tag protected in Settings > Repository)
Mark the variable as not protected (in Settings > CI/CD, under "Variables")
Again, as mentioned by #secustor, there is a good reason behind this logic. You might not want all the developers in your team to be able to access these variables.
Protected variables are only available if there is a job on a protected branch or tag.
The reasoning behind this is to allow setups which prevent right escalations.
E.g. Credentials for the testing environment for Developers on all branches and deployable credentials only on master/release branches. To add code to the second you need Maintainer rights.
In this example, without protected variables, anyone with Developer rights could print the deploy credentials in their branch.
We want to have each of our terraform environments in a separate AWS account in a way that will make it hard for accidental deployments to production to occur. How is this best accomplished?
We are assuming that an account is dedicated to Production, another to PreProduction and potentially other sandbox environments also have unique accounts, perhaps on a per-admin basis. One other assumption is that you have an S3 bucket in each AWS account that is specific to your environment. Also, we expect your AWS account credentials to be managed in ~/.aws/credentials (or with an IAM role perhaps).
Terraform Backend Configuration
There are two states. For the primary state we’re using the concept of Partial Configuration. We can’t pass variables into the backend config through modules or other means because it is read before those are determined.
Terraform Config Setup
This means that we declare the backend with some details missing and then provide them as arguments to terraform init. Once initialized, it is setup until the .terraform directory is removed.
terraform {
backend "s3" {
encrypt = true
key = "name/function/terraform.tfstate"
}
}
Workflow Considerations
We only need to make a change to how we initialize. We use the -backend-config arguments on terraform init. This provides the missing parts of the configuration. I’m providing all of the missing parts through bash aliases in my ~/.bash_profile like this.
alias terrainit='terraform init \
-backend-config "bucket=s3-state-bucket-name" \
-backend-config "dynamodb_table=table-name" \
-backend-config "region=region-name"'
Accidental Misconfiguration Results
If the appropriate required -backend-config arguments are left off, initialization will prompt you for them. If one is provided incorrectly, it will likely cause failure for permissions reasons. Also, the remote state must be configured to match or it will also fail. Multiple mistakes in identifying the appropriate account environment must occur in order to deploy to Production.
Terraform Remote State
The next problem is that the remote states also need to change and can’t be configured through pulling configuration from the backend config; however, the remote states can be set through variables.
Module Setup
To ease switching accounts, we’ve setup a really simple module which takes in a single variable aws-account and returns a bunch of outputs that the remote state can use with appropriate values. We also can include other things that are environment/account specific. The module is a simple main.tf with map variables that have a key of aws-account and a value that is specific to that account. Then we have a bunch of outputs that do a simple lookup of the map variable like this.
variable "aws-region" {
description = "aws region for the environment"
type = "map"
default = {
Production = "us-west-2"
PP = "us-east-2"
}
}
output "aws-region" {
description = “The aws region for the account
value = "${lookup(var.aws-region, var.aws-account, "invalid AWS account specified")}"
}
Terraform Config Setup
First, we must pass the aws-account to the module. This will probably be near the top of main.tf.
module "environment" {
source = "./aws-account"
aws-account = "${var.aws-account}"
}
Then add a variable declaration to your variables.tf.
variable "aws-account" {
description = "The environment name used to identify appropriate AWS account resources used to configure remote states. Pre-Production should be identified by the string PP. Production should be identified by the string Production. Other values may be added for other accounts later."
}
Now that we have account specific variables output from the module, they can be used in the remote state declarations like this.
data "terraform_remote_state" "vpc" {
backend = "s3"
config {
key = "name/vpc/terraform.tfstate"
region = "${module.environment.aws-region}"
bucket = "${module.environment.s3-state-bucket-name}"
}
}
Workflow Consideration
If the workflow changes in no way after setting up like this, the user will be prompted to provide the value for aws-account variable through a prompt like this whenever a plan/apply or the like is performed. The contents of the prompt are the description of the variable in variables.tf.
$ terraform plan
var.aws-account
The environment name used to identify appropriate AWS account
resources used to configure remote states. Pre-Production should be
identified by the string PP. Production should be identified by the
string Production. Other values may be added for other accounts later.
Enter a value:
You can skip the prompt by providing the variable on the command line like this
terraform plan -var="aws-account=PP"
Accidental Misconfiguration Results
If the aws-account variable isn’t specified, it will be requested. If an invalid value is provided that the aws-account module isn’t aware of, it will return errors including the string “invalid AWS account specified” several times because that is the default values of the lookup. If the aws-account is passed correctly, but it doesn’t match up with the values identified in terraform init, it will fail because the aws credentials being used won’t have access to the S3 bucket being identified.
We faced a similar problema and we solved (partially) creating pipelines in Jenkins or any other CI tool.
We had 3 different envs (dev, staging and prod).Same code, different tfvars, different aws accounts.
When terraform code is merged to master can be applied to staging and only when staging is Green, production can be executed.
Nobody runs terraform manually in prod, aws credentials are stored in the CI tool.
This setup can solve an accident like you decribed but also prevents different users applying different local code.
If you edit a service in Windows 7 and go to the Log On Tab, there is an option to "Allow service to interact with desktop". I'm trying to ensure that it is set for a certain service using VB.NET. Does anyone know of a way to do this?
Note: Doing this during the install of a program is not an option. It has to be done at run time.
Call ChangeServiceConfig with SERVICE_INTERACTIVE_PROCESS. The benefit of using Windows API is that it should takes care of the notification and consurrency part and invalidate the cache in other programs that uses service controller, and when something goes wrong, you get an error code back. Generally speaking you should not access the registry if you can use API to get/set a setting.
Service configuration is stored in the registry, under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\
With a key for each service.
It appears that the third to last flag within the Type value corresponds to the 'interact with desktop' value.
For example, a service set to NOT interact with the desktop has a value of:
Type REG_DWORD 0x0000010 (16)
whereas that same service, when set to be allowed to interact with the desktop has a value of:
Type REG_DWORD 0x0000110 (272)
I can't say that this is guaranteed as I've not done any testing, but it may be a good place to start. You'd need to restart the service before the changes to this value take effect.