Non-root containers cannot read Kerberos ccache on ECS Fargate - need configurable file permissions or CF_KRB5CC_MODE exposed
- Dominant language
- Go
- Stars
- 133
- Forks
- 34
- PR merge metrics
- No merged PRs in 30d
Description
This is a Fargate-specific follow-up to #68. We opened an AWS Support case for this problem and received the following response on 2026-09-10:
> "On ECS Fargate there is currently no supported way to make the Kerberos ticket readable by a non-root container when using domainless gMSA. This is a platform limitation, not a misconfiguration on your side."
**Environment:**
- ECS Fargate, platform LATEST, us-east-2
- Domainless gMSA with S3 credspec
- Application UID: `1654` (standard dotnet / .NET container APP_UID)
**Symptom:**
When the application runs as a non-root user (UID 1654), `Microsoft.Data.SqlClient` fails with error `Cannot generate SSPI context` on every connection attempt. The ccache file exists and contains a valid TGT, but GSSAPI returns EACCES opening it — the file is root:root 600 and the app process has no read access. SQL Server never receives a connection; sys.dm_exec_connections shows zero entries from the ECS task.
**Confirmed with:**
As root (ECS exec default) → succeeds:
``` bash
$ ls -l /var/credentials-fetcher/krbdir/krb5cc && klist -c /var/credentials-fetcher/krbdir/krb5cc
-rw-------. 1 root root 1439 Sep 10 16:10 /var/credentials-fetcher/krbdir/krb5cc
klist: valid TGT my-gmsa-user$@MY.DOMAIN.COM (expires Sep 11 02:10 UTC)
```
As UID 1654 (setpriv --reuid=1654 --regid=1654 --clear-groups) → fails:
``` bash
$ klist -c /var/credentials-fetcher/krbdir/krb5cc
klist: Credentials cache permissions incorrect (filename: /var/credentials-fetcher/krbdir/krb5cc)
```
**What we verified:**
- `/var/credentials-fetcher/krbdir/` is mounted read-only inside the container — chmod/chown fail with Read-only file system, including from a sidecar container sharing the mount
- `CF_KRB5CC_MODE` is not reachable from the task side — the daemon runs in AWS-managed infrastructure; the ECS agent gRPC interface passes only the credspec ARN and credential fields
- AWS Support confirmed there is no task definition field, environment variable, or other customer-accessible mechanism to change the ccache mode on Fargate
**Current Workaround:**
Remove `USER ` from Dockerfile so the container runs as root. However, running containers as root is not acceptable for production workloads.
**Feature Request:**
Implement one of these solutions to resolve this issue for Fargate users:
1. Surface `CF_KRB5CC_MODE` (or equivalent) through the ECS task definition or credspec JSON so the ccache is written at a mode readable by the configured container UID
2. Allow specifying a container UID in the task definition or credspec so credentials-fetcher writes an **_additional_** ccache copy (e.g. `krb5cc_`) owned by that UID. Non-root apps can then set `KRB5CCNAME` to that path.
Contributor guide
Research direction
Start with the credentials-fetcher daemon and the ECS agent gRPC interface described in the issue, then determine whether either can carry a configurable ccache mode or container UID on Fargate. Done means establishing a supported implementation path for non-root access, or documenting the platform limitation and the required scope for a feasible change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, go
- Domain
- authentication, cloud, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100