I tried to create new AWS key pairs and the option to create disappeared
Does anyone know why?
It would be worth checking the IAM permissions associated with the User who is trying to create the key pair. Contact the Administrator (presumably you?) and investigate. I would suggest creating a Group with Permissions and adding them to that.
I performed an experiment and added aDeny policy to my IAM User that prevented me from being able to create a keypair.
I then tried to launch an instance and the option to create a keypair (in the dialog box you show above) was still available. So, the display does not vary according to permissions.
Therefore, something else is causing your situation. I would recommend trying it in a different browser. Also, check the underlying HTML to see whether the option is coded on the web page. Something is causing it to disappear.
Related
As of now i am getting ELB logs from S3. I want to add one more field inside the logs(elb access log). Is it possible to add new field when generating new access log?
Sadly its not possible. Access logs have fixed format. If you require anything else that that, you have to produce custom logs from your application.
Access log format is fixed and you can't modify it.
The only thing that you can do is to put additional code in your application and when it loaded it can store additional details with custom log.
Is there any way to enforce the addition of labels while creating resources? If not, is there a way to automatically label resources when creating said resources in GCP?
My use case: I need this to investigate the price in Data Studio.
Thanks.
No, you can't enforce any one to put labels on resources on GCP (same for projects). BUT you can enforce TAG automatically by inheritance. (You can't oblige a user to use them, but, by default there is a tag).
The TAG are still in preview and were named "label next gen" during the Alpha period. So, you can use them like labels, but you can enforce authorization on them (who can up view/update/delete them). This feature is very interesting because today, anyone with admin/owner roles can update/change/delete labels and you lost the control and the monitoring of your resources.
You can also put IAM condition on them and enforce organization policies accordingly.
You can't enforce users to do so. However you can:
Create a log sink if a resource is created
Use that log sink to call a cloud function that will create an alert or give a default label
If you use infrastructure as code for example Terraform, you can put a CI/CD job that will check if a label is placed, and if not reject the PR.
I'm trying to follow this tutorial https://www.cdata.com/kb/tech/awsmanagement-jdbc-squirrel-sql.rst in order to connect to Redshift via SQuirrel SQL. In particular I'm trying to connect via Access Key ID and Secret Access Key.
When it comes to the Driver properties tab and need to insert the 2 keys, I struggle to set the 2 Values:
I try to click in the Value field but it simply doesn't allow me to insert any value.
Anyone had similar problem and resolved?
I found a workaround by using a Driver with SDK (for other versions: https://docs.aws.amazon.com/redshift/latest/mgmt/configure-jdbc-connection.html#jdbc-previous-versions-with-sdk) and specifying the IAM credentials in the connection URL, so structured:
jdbc:redshift:iam://{cluster-name}:{aws-region}/{db-name}?DbUser={username}&AccessKeyID={access-key-ID}&SecretAccessKey={secret-access-key}&AutoCreate=true
and replacing the fields in brackets (the final part &AutoCreate=true is optional and necessary only if it's the first time accessing with the {username} user and is desired to create it as a new user in the DB (for other fields refer to https://docs.aws.amazon.com/redshift/latest/mgmt/jdbc-and-odbc-options-for-database-credentials.html).
I figured it out with the help of https://docs.aws.amazon.com/redshift/latest/mgmt/generating-iam-credentials-configure-jdbc-odbc.html at step 3, based on their example: jdbc:redshift:iam://examplecluster:us-west-2/dev?AccessKeyID=AKIAIOSFODNN7EXAMPLE&SecretAccessKey=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
I am facing access credentials error when i ran copy Command in S3.
my copy command is :
copy part from 's3://lntanbusamplebucket/load/part-csv.tbl'
credentials 'aws_access_key_id=D93vB$;yYq'
csv;
error message is:
error: Invalid credentials. Must be of the format: credentials 'aws_iam_role=...' or 'aws_access_key_id=...;aws_secret_access_key=...[;token=...]'
'aws_access_key_id=?;
aws_secret_access_key=?''
Could you please can any one explain what is aws_access_key_id and aws_secret_access_key ?
where we can see this?
Thanks in advance.
Mani
The access key you're using looks more like a secret key, they usually look something like "AKIAXXXXXXXXXXX".
Also, don't post them openly in StackOverflow questions. If someone gets a hold of a set of access keys, they can access your AWS environment.
Access Key & Secret Key are the most basic form of credentials / authentication used in AWS. One is useless without the other, so if you've lost one of the two, you'll need to regenerate a set of keys.
To do this, go into the AWS console, go to the IAM services (Identity and Access Management) and go into users. Here, select the user that you're currently using (probably yourself) and go to the Security Credentials tab.
Here, under Access keys, you can see which sets of keys are currently active for this user. You can only have 2 sets active at one time, so if there's already 2 sets present, delete one and create a new pair. You can download the new pair as a file called "credentials.csv" and this will contain your user, access key and secret key.
I am trying to create a role within Sitecore which can publish content, but only within a specific area(s) of the site. I've added the standard Sitecore\Client Publishing role to my role, but I can't see how to prevent the role from being able to publish all areas of the site. I've looked at the Security editor and the Access viewer, but setting the write access of the sections only seems to affect the ability to edit those sections and has no effect on the ability to publish on those sections.
Workflow is the typical way this is handled. Giving roles access to approve (this could be called 'publish') content of certain sections of the content tree will be the best way to achieve what you are describing. Combine this with an auto-publish action to make it more user friendly.
One thing to keep in mind though using this method is referenced items (images from media library the content may be using for example). Take a look at the 'Publishing Spider' module on the shared source library http://trac.sitecore.net/PublishingSpider
EDIT: Update
I recently discovered this setting in the web.config: "Publishing.CheckSecurity". If set to true, this setting will only publish items if the user has read + write on the item and will only remove items from the web DB if the user has delete permissions.
I had a similar situation once and I created roles per section which only had read and write to that section and no where else (let say 'editor section 1') and another role which only had publishing permission for that section (let say 'publisher section 1'). Then added 'editor section 1' role to 'publisher section 1' role which gives you the role for publishing only specific section.
You do not need multiple workflows, same workflow with multiple roles can also achieve this goal
Answer to this is to set Publishing.CheckSecurity to true
You need to find this code inside web
<!-- PUBLISHING SECURITY
Check security rights when publishing?
When CheckSecurity=true, Read rights are required for all source items. When it is
determined that an item should be updated or created in the target database,
Write right is required on the source item. If it is determined that the item
should be deleted from target database, Delete right is required on the target item.
In summary, only the Read, Write and Delete rights are used. All other rights are ignored.
Default value: false
-->
<setting name="Publishing.CheckSecurity" value="false" />
Set the value="true"
But again you have to govern the security tightly, and assign user role properly. Failed to
do so you will experience buggy publishing.
Hope that will help