gitlabJul 6, 2026

Keep your GitLab seats in check with restricted access (opens in new tab)

GitLab’s restricted access feature helps organizations prevent unexpected seat overages by blocking new billable users once all purchased seats are occupied. Recent improvements make it work more reliably with SAML, SCIM, LDAP, OIDC, and SSO provisioning, while providing clearer warnings and audit information. The feature is forward-looking: it prevents future growth but does not automatically resolve existing overages. ## How restricted access controls seats - Available on GitLab.com and Self-Managed. - When all licensed seats are used, new billable users cannot be added. - Users who only need authentication can receive the non-billable Minimal Access role. - Existing billable members are not downgraded or removed when restricted access is enabled. - Organizations must resolve current overages by removing users or purchasing more seats. ## Identity provider integration - Users provisioned through SAML, SCIM, or LDAP are assigned Minimal Access when no paid seats are available. - Automated synchronization can continue without immediately creating billable overages. - OIDC-only users can be assigned Minimal Access at the top-level group and authenticate without consuming seats. ## Dormant user reactivation - GitLab can deactivate inactive users to free seats. - Previously, SSO or OIDC sign-ins could silently reactivate dormant users as billable members. - With restricted access enabled and no seats available, reactivated users enter a pending approval state. - Their existing group and project memberships are preserved until an administrator approves them. ## Improved operational visibility - Configuration warnings now appear for LDAP, SAML group links, and SCIM. - GitLab distinguishes between approaching and reaching the seat limit. - Group owners and instance administrators can receive email notifications when users fall back to Minimal Access. - Audit logs show Minimal Access fallback events. ## Self-Managed settings cache Self-Managed installations cache application settings for 60 seconds by default. Changes between restricted access and user cap may therefore take up to a minute to appear consistently. Administrators can adjust the cache interval if necessary. ## Restricted access versus user cap - **Restricted access:** Controls additions based on available licensed seats. - **User cap:** Sends new users into an administrator approval workflow regardless of seat availability. - The two features cannot be enabled simultaneously; enabling restricted access automatically disables user cap. ## Enabling the feature - **GitLab.com:** Settings > General > Permissions and group features > Seat control > Restricted access. - **Self-Managed:** Admin > Settings > General > New user account restrictions > Seat control > Restricted access. - GitLab.com does not support restricted access when the top-level group is shared with an external group. Restricted access is recommended for organizations seeking predictable licensing costs while retaining automated identity provisioning and controlled user reactivation.

openid-connectgitlabidentity-providersaml+4

awsJun 3, 2026

Improve your application resilience with Amazon Cognito multi-Region replication | Amazon Web Services (opens in new tab)

Amazon Cognito multi-Region replication improves authentication resilience by maintaining synchronized user data, credentials, configurations, and machine secrets in a secondary AWS Region. During a regional outage, applications can redirect traffic while users continue using existing credentials and sessions, though registration and profile updates are unavailable during failover. The feature also adds customer managed AWS KMS keys for consistent, customer-controlled encryption across Regions. ## Challenges with Regional Failover - Custom replication solutions previously required significant engineering effort. - Manual user-data transfers introduced security and consistency risks. - Users could be forced to reset passwords or authenticate again after a regional switch. - Machine-to-machine systems required new app clients, application reconfiguration, and updated OAuth resource trust settings. ## How Multi-Region Replication Works - Replication is one-way, from a primary Region to a secondary Region. - The replica includes: - User profiles and credentials - User pool configuration - Machine-to-machine secrets - The secondary pool is read-only and remains available for authentication. - Existing sessions continue uninterrupted. - Users can authenticate with existing credentials, and either Region recognizes access tokens issued by the other. - Supported authentication methods include: - Social identity providers - SAML and OIDC federation - API authorization flows - Machine-to-machine authentication - New registrations and profile changes are unavailable while operating from the replica. ## Customer Managed KMS Keys - A multi-Region customer managed key is required before replication can be configured. - The key must be replicated into both the primary and secondary Regions. - Its policy must grant Amazon Cognito permission to use the key. - Customer managed keys provide consistent encryption across Regions and greater control over encryption policies. ## Configuration Process - The console guides administrators through three main steps: - Select and configure the customer managed KMS key. - Configure multi-Region OIDC issuer endpoints. - Select and create the replica Region. - Client applications must be updated with the new OIDC endpoints. - Server-side applications require redeployment, while mobile applications require updated store submissions. - After the replica is prepared, an administrator must manually activate it. ## Additional Regional Resources - Lambda functions used for custom authentication, SMS, or email must be deployed and configured in the secondary Region. - Logging and AWS WAF settings must also be recreated there. - Teams should verify that all supporting authentication infrastructure is available before failover. ## Health Checks and Failover - Both regional endpoints remain active and ready to serve traffic. - Applications should define health checks based on error rates, latency, or service alerts. - DNS can redirect traffic to the secondary Region when failover criteria are met. - Teams should test failover during low-traffic periods, potentially routing only a small percentage of traffic initially. - Managed login and federation with custom domains can use Amazon Route 53 health checks for built-in traffic routing. ## Pricing and Availability - Replication is available as an add-on for Cognito Essentials and Plus tiers. - User authentication costs: - $0.0045 per monthly active user per replica Region for Essentials - $0.006 per monthly active user per replica Region for Plus - M2M replication adds 30% to standard successful-token pricing. - The feature is available across selected Regions in North America, Europe, Asia Pacific, Canada, Africa, and South America. Organizations needing resilient authentication should pair Cognito replication with multi-Region KMS keys, replicated supporting services, tested health checks, and an automated or well-practiced DNS failover process.

openid-connectaws-lambdaoauthsaml+4

githubApr 1, 2026

Securing the open source supply chain across GitHub (opens in new tab)

Attackers increasingly target GitHub Actions workflows to steal secrets, publish malicious packages, and spread into additional projects. GitHub recommends reducing credential exposure, hardening workflows, and using automated tools such as CodeQL and Dependabot. It is also expanding trusted publishing, malware detection, and GitHub Actions security improvements in response to campaigns such as Shai-Hulud. ## How attacks begin - Many supply-chain attacks start by exploiting insecure GitHub Actions workflows. - Stolen API keys and other secrets can let attackers publish packages from their own machines. - Malicious packages can then compromise downstream projects and propagate the attack. ## Securing GitHub Actions today - Enable CodeQL’s GitHub Actions queries, which are free for public repositories, to identify workflow security weaknesses. - Avoid triggering workflows with `pull_request_target`. - Pin third-party Actions to full-length commit SHAs. - Updates should be made by maintainers or Dependabot. - Treat pull requests that change pinned Actions with suspicion. - Protect workflows against script injection when using pull-request or other user-submitted content. - Monitor GitHub’s Advisory Database and use Dependabot malware alerts to detect compromised or vulnerable dependencies. ## Replacing secrets with trusted publishing - GitHub recommends using short-lived OpenID Connect tokens containing a workflow’s workload identity instead of storing long-lived secrets. - Cloud providers, package registries, and hosted services can use these tokens to authorize workflow activity. - Through collaboration with OpenSSF, trusted publishing is supported by npm, PyPI, NuGet, RubyGems, Crates, and other registries. - Trusted publishing both removes credentials from build pipelines and provides a signal when a package unexpectedly switches away from it. ## Detecting malicious packages - npm publishes more than 30,000 packages daily and scans every package version for malware. - Hundreds of newly published packages contain malicious code each day. - Human review confirms detections before action is taken, helping avoid disrupting legitimate maintainers. - Even a 1% false-positive rate would affect hundreds of valid package releases daily at npm’s scale. ## GitHub’s upcoming security work - Attacks such as Shai-Hulud accelerated npm’s security roadmap. - GitHub is expanding trusted publishing, malware detection and removal, and collaboration with maintainers. - The company is also revisiting and accelerating its GitHub Actions security roadmap. - New protections may require workflow changes or create compatibility concerns, so GitHub aims to make the transition gradual and solicits community feedback. Projects should audit their Actions workflows immediately, eliminate long-lived publishing credentials where possible, pin dependencies, and enable CodeQL and Dependabot. Adopting trusted publishing provides both stronger protection and useful evidence for identifying suspicious package releases.

openid-connectgithub-actionsnpmsupply-chain-security+3

cloudflareMar 4, 2026

Defeating the deepfake: stopping laptop farms and insider threats (opens in new tab)

Trust is becoming a critical security weakness as attackers use stolen identities, AI-generated deepfakes, and laptop farms to impersonate remote workers. Traditional zero trust controls verify devices and credentials but often fail to verify the actual person behind them. Cloudflare’s partnership with Nametag adds identity verification during onboarding and risk-based controls afterward, aiming to prevent fraudulent workers from accessing corporate systems. ## The Rise of Remote Worker Fraud - Organized groups, including North Korean operations, use “laptop farms” to infiltrate companies. - Devices are shipped to domestic addresses, physically connected to KVM switches, and remotely operated by fraudulent workers. - Attackers use stolen identities, generative AI for interviews, and deepfake tools to create convincing government IDs and selfies. - Valid credentials and corporate-issued devices can make these users appear legitimate to standard zero trust systems. ## Why Traditional Insider Threat Defenses Fall Short - DLP and UEBA tools typically detect suspicious behavior only after an attacker has gained access. - Conventional onboarding often trusts: - The identity provided by a new hire - The shipping address receiving the laptop - Credentials sent to a personal email address - Zero trust policies commonly verify device posture, location, and account permissions—but not whether the person is genuinely the employee. ## Identity-Verified Zero Trust - Cloudflare Access is adding Nametag’s workforce identity verification to its existing policy checks. - Nametag verifies that the person receiving, configuring, and using a device is: - A real person - The legitimate person named in the identity documents - The authorized employee - Verification occurs before access to email, code repositories, or other internal resources is granted. ## How the Nametag Integration Works - Nametag integrates with Cloudflare Access through OpenID Connect (OIDC). - It can operate as the primary identity provider or as an additional evaluation factor alongside Okta or Microsoft Entra ID. - A typical onboarding flow includes: - The user attempts to access an onboarding portal. - Cloudflare redirects them to Nametag. - The user provides a work email, takes a selfie, and scans a government-issued ID. - Nametag’s Deepfake Defense technology uses cryptography, biometrics, and AI to detect fake identities, injection attacks, and presentation attacks such as printed photos. - A successful verification returns an ID token to Cloudflare, which applies its Access policies. - The process reportedly takes less than 30 seconds, and biometrics are not retained afterward. ## Layered Insider Threat Protection - Identity verification complements Cloudflare’s existing controls: - API-driven DLP for detecting data exfiltration - Remote Browser Isolation for reducing browsing risks - Shadow IT reporting and CASB capabilities for identifying unmanaged services and misconfigurations - Together, these controls distinguish between knowing which account is connecting and knowing who is actually behind the keyboard. ## Continuous Verification - Initial identity checks are not sufficient because legitimate credentials can later be sold or compromised. - Cloudflare Access uses user risk scores to support context-aware policies. - A sudden increase in risk can trigger access revocation for one or multiple applications. Organizations facing remote hiring and insider-threat risks should supplement device and credential verification with strong identity assurance at onboarding, followed by continuous, risk-based monitoring.

openid-connectaicloudflarezero-trust+4