I would just like to ask what are the correct format for the value in the vpc section in serverless.yml especially the securityGroupIds field and the subnetIds field. It is confusing me cause if I go to lambda service in aws console, when we add vpc settings in there the string format for securityGroupIds is something like:
xx-xxxxxxxx(xx_xx_xxx_xxxxxx_xxxxxx)|xx_xx_xxx_xxxxx_xxxxxx
while if I go to vpc service in aws console and click the security group, the security group id has a string format of:
xx-xxxxxxxx | xx_xx_xxx_xxxxxx_xxxxxx
And for subnet ids, the one in lambda page has a format like this:
subnet-xxxxxxxx(xx.xxx.xx.0/xx)|ap-southeast-1a subnet-public-1a
while in the vpc page the format is this:
subnet-xxxxxxxx
My question is which format should I enter in the serverless.yml. The on in the lambda page or the one in the vpc page?
vpcConfig.yml file format should be like
vpcId: vpc-xxxxxxxxxxxxxxxxx
securityGroupIds:
- sg-xxxxxxxxxxxxxxxxx
subnetId:
- subnet-xxxxxxxxxxxxxxxxx
- subnet-xxxxxxxxxxxxxxxxx
- subnet-xxxxxxxxxxxxxxxxx
your lambda should have the subnet-xxxxxxxx
Related
I have the following http path devices/{sn} in a Serverless-AWS APIgateway API. The wildcard sn is a 15 digits [A-Z0-9] pattern.
In the API today any string that is not recognized as a valid path is redirected to this end-point. Ex: devices/test goes to devices/{sn}, devices/bla goes to devices/{sn} and so on. All those strings will query the database and return null because there is no such sn in the table. I could create a validation process inside the lambda to avoid the unnecessary database query. But I want to save lambda resource and I would like to validate before call the lambda.
This is what I have today for this endpoint:
- http:
path: devices/{sn}
method: GET
private: false
cors: true
authorizer: ${file(env.yml):${self:provider.stage}.authorizer}
request:
parameters:
paths:
sn: true
How can I setup this validation or filter in Serverless.yml?
In fact it should be a very straight-forward functionality of AWS/Serverless.
Let's say we have the following scenario: myPath/{id}. In this case id is a integer (a pk in a table). If I type myPath/blabla it will trigg the lambda. The system will spend resource. It shoul have a kind of previous validation - trig the endpoint only if the {id} === integer.
Your issue is very similar to this issue
According to the post and from my experience, No, I don't think you can perform validation in api-gateway level.
I have a lot of free-style jobs in my Jenkins instance. I create them with Jenkins API (generate XML-file with configuration and post them by "http://my-jenkins-instance:8080/createItem?name=JobName").
There is one problem - I can not generate value in secret fields. For example, I want such a config:
Inject passwords to the build as environment variables -> Job passwords.
And I need to set 123 to Password field.
I can not do this through XML because it appears decoded in XML. Something like this: {AQAAABAAAANwHq0hsSF6...}
I want to set the value to this parameter
So my questions are:
Can I get the decoded value of a plain password through some API? So I could send 123 and get {AQAAABAAAANwHq0hsSF6...} back.
If not, can I set secret value some other way? I can only think of using Selenium but it is too slow (comparing to API).
I have found the solution.
I can set the value as a plain text: <value>123</value>, create or update a job. Then I need to disable and enable the job.
I want to allow roles within an account that have a shared prefix to be able to read from an S3 bucket. For example, we have a number of roles named RolePrefix1, RolePrefix2, etc, and may create more of these roles in the future. We want all roles in an account that begin with RolePrefix to be able to access the S3 bucket, without having to change the policy document in the future.
My terraform for bucket policy document is as below:
data "aws_iam_policy_document" "bucket_policy_document" {
statement {
effect = "Allow"
actions = ["s3:GetObject"]
principals = {
type = "AWS"
identifiers = ["arn:aws:iam::111122223333:role/RolePrefix*"]
}
resources = ["${aws_s3_bucket.bucket.arn}/*"]
}
}
This gives me the following error:
Error putting S3 policy: MalformedPolicy: Invalid principal in policy.
Is it possible to achieve this functionality in another way?
You cannot use wildcard along with the ARN in the IAM principal field. You're allowed to use just "*".
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html
When you specify users in a Principal element, you cannot use a wildcard (*) to mean "all users". Principals must always name a specific user or users.
Workaround:
Keep "Principal":{"AWS":"*"} and create a condition based on ARNLike etc as they accept user ARN with wildcard in condition.
Example:
https://aws.amazon.com/blogs/security/how-to-restrict-amazon-s3-bucket-access-to-a-specific-iam-role/
I have an application that uses Azure Storage Tables that I would like to run in an Azure Container Instance. The Container Instance environment variables (my only option for passing configuration to the application running in the container) only allow alphanumeric and underscores in the quoted string values, and a connection string has things like semicolons and equals. I thought a Key Vault would work, but then I can't pass an application ID either. I can't pass:
Connection String
URL
AppID - UUID
base64 data
The only thing I can even think of would be to encode these strings to bytes (UTF-8) and convert the bytes to a hex string, but that's a messy workaround. What is the recommended means of passingconfiguration to an Azure Container Instance?
Update 11/6: We've updated the Azure portal to be more lenient on env var input so strings with special characters like connection strings should work now. Thanks!
This is currently a constraint of the Azure portal. Please try this deployment via az cli, which should support special characters in env var values.
See http://cxf.apache.org/docs/jaxrs-services-description.html#JAXRSServicesDescription-ServicelistingsandWADLqueries,
If you input URL like http://localhost:8080/store/books/services, CFX will hijack the URL and return some service description.
But in my case, the URL http://localhost:8080/store/books/services should be one of my webservice URL. How can I disable CFX's hijack?
By carefully reading the CFX document http://cxf.apache.org/docs/jaxrs-services-description.html#JAXRSServicesDescription-ServicelistingsandWADLqueries again,
I know that CFX has the ability to configure service list URL:
Note that you can override the location at which listings are provided (in case you would like '/services' be available to your resources) using 'service-list path' CXFServlet parameter, example:
'service-list-path' = '/listings'
That is a org.apache.cxf.transport.servlet.CXFServlet parameter.