Security

A secret holds a credential your integrations send to their backends, such as a token or a password. Choose Security → Secrets in the Pods sidebar, then New Secret. Only Owners and Admins can open Secrets; others see "Access unavailable".

1. Type a Name: up to 128 letters, digits, dots, dashes and underscores.
2. Pick a Kind. Bearer token is selected to start with.
3. Optional: add a Description.
4. Fill in the value fields for that kind. Fields marked * are required.
5. Choose Create Secret.

Pods encrypts the value when you save it. Values are write-only: no one can view them again, in Pods or in logs. An integration uses a secret through its Backend auth, as the Integrations guide describes.

A secret's Kind decides which values it holds. Pick the kind that matches how the backend expects the credential.

• Generic: a single Value.
• Header: a Header name and a Header value.
• Basic auth: a Username and a Password.
• Bearer token: a Token.
• AWS credentials: an Access key ID and a Secret access key, with an optional session token and region.
• Client certificate: a Certificate PEM and a Private key PEM, with an optional passphrase.
• Private key: a Private key PEM, with an optional passphrase.
• OAuth client: a Token URL, a Client ID and a Client secret, with an optional scope and audience.

A secret's kind can't change. To store a different kind, create a new secret.

The Secrets screen counts your Secrets, how many are In use by integrations or authorizers, how many are Unused, and how many were Never rotated.

Filter by Kind, or search by name, description or fingerprint. Each row shows the secret's Kind, its Fingerprint (a short trace of the value, such as "ending 4f2a", so you can tell values apart without seeing them), its current Version, when it was Last rotated and how many settings it's Used by. The list shows 25 a page.

Click a secret to open its page. Each row's ⋯ menu has Rotate, Versions and Delete.

Rotating stores a new value as the secret's next version. Choose Rotate in the secret's ⋯ menu, or at the top of its page, fill in the value fields and choose Save New Version. Integrations use the new version from then on. The previous version stays valid until you disable it.

A secret's page shows its Kind, Fingerprint, Current version, when it was Last rotated, when it Expires and what it's Used by. Under Versions, each version is Current, Enabled or Disabled.

To stop an older version working, choose Disable in its ⋯ menu and confirm. Anything still using that version stops working, and it can't be undone. The current version can't be disabled: rotate first.

Deleting a secret destroys every version of it. Choose Delete in its ⋯ menu, or under Danger zone on its page, and confirm. It can't be undone.

Pods won't delete a secret that integrations or authorizers still use. The message says how many settings refer to it: change them to another secret first.

The web application firewall filters requests to REST API stages. Its rules live in a web ACL, which you attach to one or more stages. Choose Security → Web Application Firewall in the sidebar. The screen has three tabs: Web ACLs, IP Sets and Regex Sets. Only Owners and Admins can make changes.

1. On the Web ACLs tab, choose New Web ACL.
2. Type a Name and choose Create Web ACL.

The new web ACL opens with no rules and a default action of Allow, which applies when no rule decides. Its sections are Rules, Managed Rule Sets, Associations and Sampled Requests. The list shows each web ACL's default action, number of rules and last update, and can be filtered by Default action.

A web ACL's Rules section lists its rules in a table and holds them as JSON in Rules JSON. Edit the JSON, then choose Save Changes at the top; "Unsaved changes" shows until you do. Each rule has:

• name: 1 to 128 characters.
• priority: a whole number, unique within the web ACL. Lower numbers run first.
• action: ALLOW, BLOCK or COUNT.
• statement: what the rule matches, by type, such as IPSetReferenceStatement, RegexPatternSetReferenceStatement, GeoMatchStatement, ByteMatchStatement, SizeConstraintStatement, SqliMatchStatement, XssMatchStatement, RateBasedStatement, or AndStatement, OrStatement and NotStatement to combine others.

For example, {"name": "block-bad-ips", "priority": 10, "action": "BLOCK", "statement": {"type": "IPSetReferenceStatement", "ipSetId": "…"}} blocks the addresses in an IP set.

Pods checks rules in priority order: the first rule that allows or blocks a request decides it, and COUNT only records a match. When no rule decides, the default action applies. A blocked caller gets 403 Forbidden.

Managed rule sets are groups of rules Pods maintains. Open a web ACL and choose Managed Rule Sets, then Add beside a set:

• PodsCommonRuleSet: size limits, path traversal, file inclusion, bad user agents and metadata-SSRF strings.
• PodsSQLiRuleSet: SQL injection in the path, query string and body.
• PodsKnownBadInputsRuleSet: Log4j JNDI, Java deserialization, localhost host headers and XSS.
• PodsAdminProtectionRuleSet: blocks outside access to /admin paths.

Adding a set appends a BLOCK rule after your last priority, and the set shows as Added. Choose Save Changes to apply it.

IP sets and regex sets are lists that rules match against, so one list can serve many rules. On the Web Application Firewall screen, open the IP Sets or Regex Sets tab and choose New IP Set or New Regex Set.

• IP set: a Name and IPv4 CIDRs such as 203.0.113.0/24, one per line or comma separated, up to 10,000.
• Regex set: a Name and Patterns such as ^/admin, one per line or comma separated. Patterns must be safe to run in linear time.

Choose Create IP Set or Create Regex Set. To use a set in a rule, choose Copy ID in its ⋯ menu and put the ID in the rule's statement, as ipSetId or regexSetId.

A web ACL filters traffic only on the stages it's associated with. Open the web ACL and choose Associations. Under Associate a stage, type the API ID and the Stage name, then choose Associate. A stage can have only one web ACL. Associated stages lists each one with when it was added.

Sampled Requests shows requests the web ACL blocked or counted in the last 3 hours, up to 100 per rule per stage: the time, the action, the method and path, the source IP, the rule and the stage. Filter them by Stage and Rule.

A signing credential is an access key pair that callers use to sign requests with AWS Signature Version 4 (SigV4). Methods and routes whose authorization is Signed requests (SigV4) accept only requests signed this way. Choose Security → Signing Credentials in the sidebar, then New Credential. Only Owners and Admins can manage credentials.

1. Type a Name.
2. Optional: pick an Expires at date.
3. Choose Create Credential.

Pods shows the Access key ID (it starts with PKIA) and the Secret access key. The secret is shown once, so copy it before you choose Done. The dialog also has example signing code for @smithy/signature-v4 and Python botocore. Sign with the service execute-api and the region auto.

A new signing credential can't call anything until a policy allows it. Open the credential and choose Policies.

1. Under Attach policy, type a Name.
2. In Policy document (JSON), write an identity policy with Version and Statement, such as one that allows execute-api:Invoke on your API's methods.
3. Choose Attach Policy.

A credential holds up to 10 policies. An explicit Deny beats any Allow, and anything not allowed is denied. To remove a policy, choose Detach in its ⋯ menu and confirm.

The credential's Overview shows its Principal, the ARN a REST API's resource policy uses to allow it.

The Signing Credentials list shows each credential's status, Active or Inactive, when it was Last used and when it Expires. Filter by Status, or search by name or access key ID.

Each row's ⋯ menu has Open, Copy access key ID, Deactivate or Activate, and Delete. An inactive credential stays in the list, and you can activate it again; the switch at the top of a credential's page does the same.

Deleting asks you to confirm. Requests signed with the credential are rejected straight away, and it can't be undone.